This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[11:46:54] <purplefox> hi stephane_bastian

[11:47:13] <stephane_bastian> hey

[11:47:22] <purplefox> stephane_bastian: if you want to chat about auth issues i am here most of today

[11:47:35] <purplefox> stephane_bastian: let me just get a coffee though ;)

[11:47:36] <stephane_bastian> perfect. thx

[11:47:46] <stephane_bastian> will do the same ;)

[11:49:23] <temporalfox> purplefox for the worker client/server bugs I did a BZ here : https://bugs.eclipse.org/bugs/show_bug.cgi?id=467775 and I created a reproducer for the specific case of the webocket client worker bug https://github.com/eclipse/vert.x/tree/client-worker-websocket-handshake-race-condition

[11:51:43] <stephane_bastian> purplefox: did you get the following msg I sent yesterday?

[11:51:53] <stephane_bastian> Tim, I think we've got a problem with Vertx-Auth. Could you please confirm? Let say that a User is successfully authenticated (via JDBC for instance). The user is stored in Session. Then the admin of the webapp, deletes or suspends the account of the user. It should be immediate, right? But since the user is stored in Session he will be able to use the web app until the session expires. Is…

[11:51:55] <stephane_bastian> …this correct?

[11:52:22] <stephane_bastian> purplefox: What do you think ?

[12:01:12] <purplefox> stephane_bastian: right, only just saw that message

[12:01:29] <purplefox> i think this is not really an auth issue, but is something inherent in sessions

[12:01:57] <purplefox> if you want to ban a user immediately you would need to invalidate the session

[12:02:35] <purplefox> most webapps don't authenticate on each request

[12:02:43] <purplefox> they do it once then store that in the session

[12:05:12] <stephane_bastian> well… how do you invalidate the session of a particular user?

[12:05:17] <maschmid> IMHO it is not an authentication issue though… the user is still who he claims to be… authorization is what has changed…

[12:06:36] <purplefox> stephane_bastian: you could either: delete the session from the sessionstore, or lookup the session from the sessionstore and remove the user entry

[12:08:01] <stephane_bastian> sure, the problem though is that I that the SessionStore allows me to delete a Session using the sessionId and if I am the admin and delete the user, I do not know what is his sessionId, I only know its userId

[12:11:32] <purplefox> stephane_bastian: i guess you could write some kind of handler which grabs the session id during login and stores that in a map somewhere and then you write a little admin map which displays that map and allows you to delete the session for a user

[12:13:11] <stephane_bastian> yeah sure I could do this. But I would prefer that Vertx-Auth does the right thing so I don have to deal with that level of detail ;)

[12:13:30] <purplefox> or. say before a user does something important like a place an order you make sure you check their authorisation again and clear the user cache before that, that way you will know they have the rights to place the order at that time

[12:13:46] <purplefox> i think many sites will do this - they will double check auth before placiong an order

[12:14:02] <stephane_bastian> sure but this is a different problem.

[12:14:27] <purplefox> what is “doing the right thing”?

[12:14:28] <stephane_bastian> the current issue is that if as user is banned or deleted it should be done immediately

[12:15:14] <purplefox> and it would happen immediately if you implemented it as above :)

[12:16:01] <purplefox> you are saying “if a user is banned or deleted” but you're not saying how you actually do that, so you're not really proposing anything ;)

[12:16:23] <purplefox> so what is your alternative proposal?

[12:16:30] <stephane_bastian> well if it is implemented as above, it means that I would go to the User table on each request (which is fine for me) and not use session at all

[12:17:23] <purplefox> what is a user yable>

[12:17:25] <purplefox> table?

[12:18:04] <stephane_bastian> yep sorry table ;)

[12:18:17] <stephane_bastian> I've got big, fat finders ;)

[12:18:20] <purplefox> i don't follow. can you explain how you would ban a user immediately?

[12:18:29] <purplefox> what api are you using?

[12:21:02] <stephane_bastian> What do you mean what API I am using? Vertx API

[12:21:18] <purplefox> but there is nothing in the vert.x api that lets you ban a user

[12:22:45] <purplefox> so my question is: you don't like the proposal i gave, so do you have an alternative proposal which solves the problem in a better way?

[12:24:45] <stephane_bastian> I know that Vertx does not have an API to ban users. In the app I am building users can be deleted or banned. I was hoping that Vertx Auth would not let a User use my app when its has been deleted.

[12:26:10] <purplefox> how would vert.x know that a user has been deleted?

[12:26:24] <stephane_bastian> IMO, the solution is not to use session but rather get the user fresh from a UserStore on each request.

[12:26:28] <purplefox> i think this is something specific to your app right?

[12:26:41] <stephane_bastian> not specific to my app at all.

[12:27:55] <stephane_bastian> Do you remember that we talked about a UserStore at some point and time? We finally decided to reuse the SessionStore because we though it would provide the same functionality.

[12:29:07] <stephane_bastian> but unfortunately the SessionStore introduced a security hole. Don't you think?

[12:29:36] <purplefox> i don't think there is a security hole, no

[12:30:04] <stephane_bastian> we've got different view on the subject but that's ok ;)

[12:30:48] <stephane_bastian> Now concerning the refactoring of the Auth API. The AuthService used to have the method AuthService.logout(String loginId). But now that the AuthService is gone, how can we logout? I couldn't find the logout functionality anywhere

[12:31:12] <purplefox> you set the user to null on the session

[12:31:46] <purplefox> sorry…

[12:31:51] <purplefox> you set the user to null on the routingcontext

[12:32:24] <purplefox> there are tests for this, and its in the docs

[12:35:08] <stephane_bastian> sorry I read most docs but probably not this part. My bad. Thx

[12:36:32] <purplefox> stephane_bastian: if you can suggest a better way, i am totally open to suggestions. i'm not sure how a userstore would help things though

[12:37:11] <purplefox> as soon as you introduce another store complexity increases, now we have two lifecycles to manage, and more complexity for the developer

[12:37:28] <maschmid> purplefox, can the authorizations caching be optional ? (or at least have a way to purge all the caches?)

[12:37:41] <purplefox> there is a way to purge the cache already

[12:37:47] <purplefox> user.clearCache()

[12:39:32] <stephane_bastian> yeah I know. but as you know the app I am building must Authenticate users via Facebook, Google, Twitter, etc.. and an elasticSearch backend. I am using the latest Auth API and try to implement multiple providers but the API has some shortcomings and I can make it work. Hence my questions ;)

[12:39:56] <purplefox> could you explain what the shortcomings are?

[12:43:17] <stephane_bastian> for 1) we do not want to use server side sessions at all. My app is distributed on multiple nodes, so Session means either Sticky Sessions or ClusteredSession.

[12:43:46] <purplefox> vert.x auth has no dependency on sessions

[12:44:54] <purplefox> we removed the dependency in the last refactoring

[12:45:50] <stephane_bastian> right, but the AuthHAndler which is what I use for the Auth functionality in Vetrx-web has a dependency on Session

[12:47:02] <purplefox> that's different

[12:47:16] <purplefox> we're talking about shortcomings in the auth api aren't we?

[12:47:43] <maschmid> purplefox, but you don't have the user instance when you do an operation like “as an admin, I want to block this set of users, so I modify LDAP and now I want to flush all user session's permissions so that they are immediately blocked… (and cannot workaround my ban by keeping themselves logged in forever…)

[12:48:03] <purplefox> and in any case authhandler does not rely on sessions anyway ;)

[12:48:36] <purplefox> this conversation all seems a bit muddled to me. are we talking about vertx-auth, vertx-web, something else?

[12:49:57] <stephane_bastian> look at RedirectAuthHandlerImpl. first line Session session = context.session();

[12:49:58] <stephane_bastian> if (session != null) {

[12:50:00] <stephane_bastian> …

[12:50:01] <stephane_bastian> }

[12:50:03] <stephane_bastian> else {

[12:50:04] <purplefox> you're talking about handlers now…

[12:50:04] <stephane_bastian> context.fail(new NullPointerException(“No session - did you forget to include a SessionHandler?”));

[12:50:06] <stephane_bastian> }

[12:50:17] <purplefox> we're all over the place here

[12:50:26] <purplefox> let's take a step back.

[12:50:49] <purplefox> previously we were talking about shortcomings in the new auth api

[12:51:05] <purplefox> but i think we are talking about handlers now, not the auth api

[12:51:11] <purplefox> now of course…

[12:51:14] <stephane_bastian> We are not all over the place at all. How do you use the Auth API in a web App ? By using Auth handlers provided by Vertx-Web

[12:51:28] <purplefox> no, i think you are missing the point

[12:51:35] <purplefox> of course we will write more handlers

[12:51:37] <stephane_bastian> the Auth API and handlers goes hand by hand

[12:51:56] <purplefox> the point of the refactoring is not to fullfull every use case out of the box right now

[12:52:07] <purplefox> there are many, many use cases left to do

[12:52:16] <purplefox> but the point is to make the auth api flexible enough

[12:52:31] <purplefox> that we can write handlers later that use the auth api

[12:52:37] <purplefox> but don't require changes in the auth api

[12:52:40] <purplefox> for example

[12:52:48] <purplefox> paulo is writing a new handler to deal with JWT

[12:53:15] <purplefox> now currently our session handlers assume server side sessions and session cookies

[12:53:31] <purplefox> but in the future we can write other handlers that handle sessions in a diffeernt way

[12:53:32] <purplefox> that's all fine

[12:53:55] <purplefox> but the point is we don't need to change the auth api, and none of this appears to be a problem in the auth api as far as i can tell

[12:54:39] <purplefox> does that make more sense?

[12:56:05] <purplefox> at this point the important thing is to get the _interface_ right, not have handlers for every use case. because after 3.0 is out it won't be so easy to change the interfaces because of backwards compatibility

[12:57:14] <purplefox> now if you want to talk about handlers and your particular use case that's fine, we can do that :)

[12:57:21] <stephane_bastian> I agree with the fact that we've got to have the Auth interface right

[12:57:25] <purplefox> btw, only redirect auth handler relies on sessions

[12:57:32] <purplefox> basic auth handler does not

[12:58:00] <purplefox> maybe you could explain what doesn't work for you with the current handlers?

[12:58:57] <stephane_bastian> Basic Auth handler does as well, all auth handler use Session (they use UserHolder.get) which in turn use the Session. but lets put that aside, I can rewirte the handler if I need to not to use Session

[12:59:07] <purplefox> that's is not true

[12:59:24] <purplefox> basic auth handler will work with sessions if you have them, but also works fine without sessions

[12:59:48] <purplefox> it does not require sessions

[13:01:38] <stephane_bastian> great if it works without sessions

[13:02:15] <purplefox> and the JWT stuff does not require sessions either

[13:02:56] <stephane_bastian> I know, JWT is mostly use to do sessionless auth bit it would better not use session ;)

[13:04:37] <purplefox> indeed :)

[13:06:20] <stephane_bastian> So to focus on the Auth interfaces, almost everything is ok for our use cases, excepted that I would need to get the list of roles and permissions of a User, instead of hasRoles() and hasPermissions

[13:07:46] <purplefox> stephane_bastian: i'm not sure that is possible in the general case, as some auth providers may not provide the functionality to get the list of all roles/permissions but only allow you to query them…

[13:09:54] <stephane_bastian> I am surprised that some Auth providers may not return the list of roles / permissions. Maybe youǘe got an example?

[13:10:21] <stephane_bastian> for JDBC / LDAP it's farily easy to get roles / permissions

[13:10:37] <stephane_bastian> maybe for thing like ActiveDirectory ?

[13:11:59] <maschmid> Maybe someone may model their permissions to be a potentially infinite set… (e.g. containing some resource Ids in permissions…)

[13:14:12] <stephane_bastian> maschmid: this is excatly what we do. we model our permissions to contain the ids they are related to. for instance if a user has the right to create, delete users a specific group, it would have a permission such as 'users:create:group:groupId123'

[13:14:33] <stephane_bastian> but in any case, it doesn't prevent the AuthProvider to return the list of roles / permissions

[13:18:09] <purplefox> stephane_bastian: we can add this to the user interface, but i don't think we can guarantee it will be implemented by all providers. also if we provide this information then it's easy for it to become stale, e.g. if a role/permission is subsequently added/revoked

[13:18:18] <purplefox> what's the use case for wanting this information?

[13:18:33] <purplefox> why not just call hasRole/hasPermission

[13:19:20] <purplefox> i can see users getting into bad habits and retrieving all roles and then complaining when they get stale

[13:20:33] <stephane_bastian> purplefox: the use case is the following, a user is looking at a page that list some resources that he subscribed to (lets say books).

[13:22:37] <purplefox> not sure why you would use permissions for that..

[13:22:40] <stephane_bastian> he is searching all books about 'New York'. the result of his search should be restricted to the book he bought. One way of doing this is to get all permissions he's got, and filter on the book he book as part of the query we submit (in our case elasticsearch)

[13:23:13] <stephane_bastian> sorry: ⇒ and filter on the book he bought as part of the query we submit (in our case elasticsearch)

[13:23:47] <purplefox> and don't see how that is related to permissions, it seems more like a join on his order history and the current catalogue

[13:24:32] <stephane_bastian> if you don't know the list of permissions it is impossible to scope the search to the book he bought

[13:25:08] <maschmid> just because permissions are based on some application-specific data doesn't mean you should use the permissions API to query for the application specific data…

[13:25:37] <stephane_bastian> in our system , when someone buys a book, he gets the permission to read the book. for instance 'books:read:myfirstbook'

[13:26:32] <purplefox> yes but once he has bought it you don't need to use the permissions api again to do the join - surely much better to join between the order history and the catalogue?

[13:26:44] <purplefox> maschmid: +1

[13:28:01] <stephane_bastian> We are not using a SQL db so there is no join.

[13:28:17] <purplefox> you're basically using permissions as a way to determine what a user “owns” that seems like a misuse of permissions to me

[13:28:55] <purplefox> joins are not specific to sql database, any time you correlate two datasets you are doing a join

[13:30:11] <stephane_bastian> it is absolutely not a misuse at all. it is just one way to use the information that is stored inside permissions. I am not saying thatś the way people should do. Just thatś this is how we do it and that's working great for us

[13:31:26] <purplefox> i don't know, seems like using permissions to store what is effectively a users order history seems strange to me

[13:32:09] <purplefox> but i don't like the idea of fine grained permissions, i.e. a diffeernt permission for each item, that seems like a bad design smell to me too

[13:33:01] <purplefox> it seems to me the permissions model and the customer order history and catalogue are separate things

[13:33:58] <stephane_bastian> what the right permission for you then ? it is not enough to say that the user is allowed to read a book. what we need to do is allow the user to read the book number xyz. hence it is in the permission

[13:34:58] <purplefox> I wouldn't use permissions for that, I would check in the users order history to see if they have bought book 123

[13:35:00] <stephane_bastian> well that's you take. I've been dealing with permission stuff for quite some time now and this has been workign really great.

[13:35:47] <purplefox> the trouble with using permmissions for that is it ties your auth provider very tightly to your application specific details such as your product catalaogue and order history

[13:36:00] <purplefox> so you probably need to write your own auth provider to deal with that

[13:36:00] <stephane_bastian> plus more and more people advocate that fine grained permission is the way to do. but that's a different story and in any case itś a misuse or a bad design smell ;)

[13:38:23] <stephane_bastian> yeah that what I think. As a matter of fact we've got to fork the Auth project and start from there. What we really need is User.roles(), User.permissions(). It's not enough to wrie our own AuthProvider

[13:39:03] <maschmid> so what is stopping you from extending the User interface with your custom one?

[13:40:26] <purplefox> well.. i'd say that the out of the box auth providers should be usable without changes for 99% of people. I think the reason you need to write your own one is you're kind of using permisions for something they're not really intended for

[13:41:52] <purplefox> yeah we could add User.roles(), User.permissions(). but I'm just mentioning the above as i don't think that would be necessary if you didn't couple your order model/catalogue model so tightly with your permisions model

[13:42:16] <purplefox> anyway.. i'm not going to force you to write your application in a different way ;)

[13:42:34] <maschmid> a custom AuthProvider can provide a custom User -extending interface as well… you don't need to fork Auth for that…

[13:42:48] <purplefox> that's true, you could subclasss it

[13:43:00] <purplefox> then you'd just have to cast to your subtype when retrieving it…

[13:43:53] <purplefox> or you could just provide your own custom interface which allows you to get all roles/properties. if you're writing your own auth provider anyway i doubt it would make much difference

[13:45:00] <stephane_bastian> that's true

[13:46:34] <purplefox> but i think yours is an edge case… i think most people who use auth will use an out of the box auth provider, e.g. jdbc or ldap and point it at the corporate installation and that won't know anything about your particular product catalogue or customer order histroy

[13:48:41] <stephane_bastian> yeah you are right, this is probably an edge case

[13:52:37] <stephane_bastian> I've got to more forward on the Auth portion ofn our App. So Auth API are mostly fine (excepted the I will see if we build

[13:54:22] <stephane_bastian> sorry: I've got to more forward on the Auth portion of our App. I'll see what we do with the Auth API. In any case I will probably submit PRs for Auth handlers in case you are interested

[13:55:11] <stephane_bastian> Thx all.

[13:56:20] <purplefox> stephane_bastian: thanks stephane :)

[13:59:00] <stephane_bastian> FYI, we've built an MVC for Vertx 3. We'll probably open source it and share it with everyone on GitHub sometime later. right now, we've got too much on our plate ;(

[14:04:20] <purplefox> stephane_bastian: sounds interesting. good luck with your project :)

[14:05:18] <stephane_bastian> Thx a lot, same for you

[14:06:11] <purplefox> stephane_bastian: btw, i do appreciate your feedback, it is very valuable

[14:12:39] <aesteve> hello everyone :)

[14:12:45] <purplefox> hi

[14:12:54] <purplefox> aesteve: how are you?

[14:13:09] <aesteve> fine, the weather is quite nice here actually, and you ?

[14:13:30] <purplefox> oh, not bad. it is also quite sunny here too which makes a change ;)

[14:15:23] <aesteve> nice :)

[14:16:09] <aesteve> I've discovered WAMP ( http://wamp.ws/ ) recently. Maybe a vertx-wamp-router could be an interesting idea (and also an eventbus-wamp-bridge)

[14:16:25] <aesteve> not sure, but it sounds interesting

[14:19:12] <purplefox> aesteve: sounds very much like the event bus bridge :)

[14:19:29] <aesteve> it does !

[14:19:30] <purplefox> which we've had for 3+ years

[14:19:45] <aesteve> with RPC calls (not even sure who uses that)

[14:20:14] <purplefox> you can do “RPC” with the event bus bridge - it's just request/response messaging

[14:20:32] <aesteve> but the only use case I see is for people who already have a WAMP-compliant application, to have it “chat” with Vert.x

[14:21:30] <purplefox> yeah, there's no harm in having another implementation I guess

[14:21:48] <aesteve> so maybe a kind of WAMP listener/publisher which forwards messages from Vert.x event bus and reads WAMP messages and forwwards them to the event-bus

[14:22:02] <aesteve> imo it would be trivial, I'll probably give it a try

[14:22:11] <purplefox> it's just when i see things like this i don't go “hey that's a cool new idea”, I go “Ah, they've finally caught up” ;)

[14:22:23] <aesteve> indeed :)

[14:22:56] <purplefox> it's like now, *everyone* is doing microservices. when i started vert.x they were very much looked down upon

[14:23:11] <purplefox> and now *everyone* is reactive, of course, too

[14:23:19] <aesteve> i was about to say it

[14:23:27] <purplefox> even some are trying to rebrand JavEE as reactive microservices. #facepalm

[14:23:38] <aesteve> I looked at the java implementation of wamp and it uses rxjava

[14:23:57] <aesteve> I think everything is started to converge

[14:25:12] <aesteve> and regarding examples, maybe the webRTC signaling server could be nice too. I've seen some implementations using nodejs/socketio and it looks easy.

[14:25:36] <aesteve> (and in my news feeds WebRTC looks like a trending keyword, so I'll give it a try, too)

[14:26:27] <aesteve> but that's kinda nice when you see some new technology and just think “hey, I could implement it with Vert.x that would be easy”

[14:30:00] <AlexLehm> purplefox: I have looked into the processing time issue in the tests, but I am kind of at a loss how this fix that

[14:30:36] <AlexLehm> its probably happening for large mails always

[14:35:23] <purplefox> the one that takes a long time to run for me is this one:

[14:35:24] <purplefox> T E S T S

[14:35:24] <purplefox> Running io.vertx.ext.mail.impl.Pool1SlotTest

[14:35:25] <purplefox> Starting test: Pool1SlotTest#mailTwiceTest

[14:35:25] <purplefox> 2015-05-21 13:34:24 INFO [main]org.subethamail.smtp.server.SMTPServer.start:278 - SMTP server *:1587 starting

[14:35:28] <purplefox> 2015-05-21 13:34:24 INFO [org.subethamail.smtp.server.ServerThread *:1587]org.subethamail.smtp.server.ServerThread.run:67 - SMTP server *:1587 started

[14:35:31] <purplefox> Thread Thread[vert.x-eventloop-thread-2,5,main] has been blocked for 2677 ms time 2000000000

[14:35:48] <purplefox> I will take a look to see if it is anything obvious

[14:38:04] <purplefox> AlexLehm: what's the idea with the idle wait?

[14:38:46] <AlexLehm> this test uses a 50 MB mail to test how the pool works when two mails are sent in parallel and that takes too long to process in write

[14:39:25] <AlexLehm> the idle wait is the time a smtp connection is kept open, which is already logged in for example until it is closed by the client

[14:40:25] <AlexLehm> if you send a mail every minute for example, it will use the same connection and run one command first to check if it still working and the send the mail

[14:40:38] <AlexLehm> if the time is more than 5 minutes, the connection will be closed properly

[14:41:08] <purplefox> AlexLehm: why is it important to do that?

[14:42:02] <AlexLehm> the connection is opened, usually tls will be done and the login is done, and we can avoid that if a connection is still open

[14:42:15] <AlexLehm> (same with https btw)

[14:42:42] <purplefox> no, i mean why do we close connections if they are idle?

[14:43:03] <purplefox> we don't do this with other connections (http connections, mongodb connections, jdbc connections…)

[14:43:13] <purplefox> why is it important for mail connections?

[14:45:16] <AlexLehm> if they are not used anymore in a running server I think they should be closed at some time

[14:45:29] <AlexLehm> the server will close the connection after a few minutes as well

[14:46:38] <AlexLehm> http connections are usually closed after a idle time as well, either by the server or by the client

[14:46:45] <AlexLehm> though this is not currently implemented I think

[14:47:15] <AlexLehm> at least http keep-alive has a field that defines how long the idle connection may be kept open

[14:48:03] <AlexLehm> and if you have bad luck your firewall will time out the idle connections as well (happens with oracle connections sometimes)

[14:50:55] <purplefox> AlexLehm: this is the track from where the event loop is being blocked:

[14:50:56] <purplefox> https://gist.github.com/purplefox/4cef82fb76f8b6ccc6cb

[14:51:03] <purplefox> stack trace]

[14:51:37] <purplefox> it's weird it's like you're receiving data from the network and then you're immediately sending more data…

[14:52:30] <AlexLehm> is there a limit for the length of a netsocket.write operation?

[14:52:49] <AlexLehm> this will call write with a 50MB string, maybe that is not working well

[14:53:38] <purplefox> why are you sending such large messages for this test?

[14:54:00] <AlexLehm> the result handler for the previous reply calls the write operation, that is here: https://github.com/vert-x3/vertx-mail-client/blob/wip/vertx-mail-client/src/main/java/io/vertx/ext/mail/impl/SMTPSendMail.java#L146

[14:54:41] <AlexLehm> to test the behaviour of the mailclient I used a large message to make sure that is spends a few seconds in the client

[14:54:42] <purplefox> ok but why so big?

[14:54:54] <purplefox> i don't follow

[14:54:57] <AlexLehm> this takes about 5 seconds on my config, but it takes way longer

[14:55:30] <purplefox> how is a big message relevant to this test?

[14:55:45] <purplefox> this test, tests pooling

[14:56:07] <purplefox> is pooling related to message size? i would hope not

[14:56:16] <AlexLehm> to assert that the messages are sent in the pool in parallel it has to take long enough for the 2nd message to start while the first is still being processed

[14:56:25] <AlexLehm> no its not

[14:56:44] <AlexLehm> maybe we can just make the message smaller like 1 mb

[14:57:43] <purplefox> in parallel? the tests send messages sequentially, not in parallel

[14:58:23] <purplefox> ah sorry, mailTwiceTest

[14:58:41] <AlexLehm> i may have confused the tests

[14:58:56] <purplefox> but in any case, i don't think message size gives you any control over this

[14:59:09] <purplefox> also… sending a 50MB message in a single write is not a good idea

[14:59:23] <AlexLehm> there is one with a pool size 1 and that tries to send two mails and measure the running time

[14:59:48] <AlexLehm> i have started to rewrite that to write individual lines, but that has not improved the behaviour much

[14:59:52] <purplefox> large messages would need to be split up into chunks

[15:00:19] <purplefox> also your PassOnce object is not threadsafe

[15:00:55] <AlexLehm> ok, i have the rewritten write operation almost finished, but I didn't commit that yesterday evening

[15:01:18] <AlexLehm> i thought that it doesn't have to be if it is in the same context

[15:02:09] <purplefox> it's not used on the same context. you create it on the main thread, then its used from two other contexts (one for each send)

[15:03:31] <AlexLehm> ok

[15:05:39] <AlexLehm> ok, i have to log out, i will come back this evening if you have time

[15:06:40] <purplefox> ok thanks Alex

[15:14:28] <aesteve> purplefox: is it intended that here : https://github.com/vert-x3/vertx-web/blob/master/pom.xml

[15:14:37] <aesteve> the version number for vertx-auth is missing ?

[15:15:00] <aesteve> that seems to annoy Gradle :\

[15:15:13] <aesteve> > Could not parse POM http://oss.sonatype.org/content/repositories/snapshots/io/vertx/vertx-web/3.0.0-SNAPSHOT/vertx-web-3.0.0-20150521.090340-1.pom

[15:15:13] <aesteve> > Unable to resolve version for dependency 'io.vertx:vertx-auth:jar'

[15:15:26] <aesteve> nothing urgent, just wondering :)

[15:29:46] <purplefox> aesteve: i'm not sure i follow.. what version number is missing?

[15:30:01] <aesteve> in https://github.com/vert-x3/vertx-web/blob/master/pom.xml

[15:30:09] <aesteve> vertx-auth has no version number

[15:30:15] <aesteve> (explicitely declared)

[15:30:28] <aesteve> that's what Gradle doesn't understand

[15:31:26] <aesteve> Gradle is fine with optional dependencies (for example the handlebars one works like a charm) as long as the version number is declared explicitely (like the handlebars dependency)

[15:33:26] <purplefox> i don't think it's a problem with gradle or you'd have problems with any vert.x dependencies as never declare the versions expliticly, they are defined elsewhere

[15:34:20] <purplefox> most probably the vertx-dependencies pom isn't pushed to sonatype

[15:34:42] <aesteve> ah that's why it cannot find the version number

[15:35:09] <aesteve> I'll take a look

[15:35:54] <purplefox> actually it is pushed:

[15:35:55] <purplefox> https://oss.sonatype.org/content/repositories/snapshots/io/vertx/vertx-dependencies/3.0.0-SNAPSHOT/vertx-dependencies-3.0.0-20150519.101320-25.pom

[15:35:59] <purplefox> and it has vertx-auth in it

[15:36:04] <aesteve> that's bind news for me

[15:36:07] <aesteve> bad*

[15:36:13] <purplefox> so maybe you have a cached old copy locally?

[15:36:31] <aesteve> I'll try –refresh-dependencies

[15:38:23] <aesteve> doesn't work either. but if it's just a matter of cache I'll see if it works in the future, no worry

[15:39:11] <aesteve> if there are other places where optional dependencies aren't declared with an explicit version number you're right that should work

[15:51:54] <D-Spair> aesteve: You were right… JSch sucks! I'm looking into what it would take to port trilead to use NIO instead…

[15:52:23] <D-Spair> Plus, use BouncyCaste instead of their embedded crypto code so that someone upstream maintains the crypto code.

[15:52:26] <aesteve> I've wasted a lot of time in the past with JSch :(

[15:52:39] <aesteve> good luck :\

[15:53:10] <D-Spair> aesteve: I know I can make it work, but to make it work inside of Vert.x in a non-blocking fashion is more painful than what I would like it to be.

[15:53:41] <D-Spair> So, porting to use Netty as the underlying transport and using BouncyCastle seems to be the best option IMHO.

[15:54:13] <D-Spair> Then it would be relatively easy to make it reactive and more performant.

[15:54:52] <aesteve> probably ? Honestly I have forgotten about jsch like 2 years ago (and I'm happy I did)

[15:56:01] <D-Spair> From searching via Google, there appears to be a decent amount of demand for an SSH implementation which uses Netty/NIO as the transport

[15:56:39] <D-Spair> And if I can get most of the crypto capabilities from BouncyCastle it will just be a matter of implementing the protocol specs.

[15:57:19] <D-Spair> I've done that many times in the past (DNS, HTTP, SNMP, etc…)

[15:59:32] <D-Spair> I think that I will only target SSH v2 in the initial version. The 1.x spec for SSH is almost undocumented.

[17:07:18] <rajith> purplefox: are we on schedule for the milestone release tmr?

[17:08:02] <rajith> purplefox: The code is ready, but I need to finish up the docs and do a tutorial. Was wondering how much time I have

[17:08:18] <purplefox> rajith: the final milestone is on 28th may https://github.com/vert-x3/wiki/wiki/Vert.x-Roadmap

[17:08:51] <purplefox> so anything would need to be ready before that, and we need to allow time for review etc

[17:09:17] <rajith> purplefox: if I have everything ready on monday could you spare some time to review it?

[17:09:50] <rajith> purplefox: the only thing outstanding is the doc, tutorial and the examples in non java languages.

[17:10:27] <rajith> purplefox: the java examples are good and I've done two demos to my team to get feedback and a fair amount of testing has gone into it.

[17:10:43] <rajith> purplefox: if u notice the diff btw master and initial-work is significant :)

[17:10:56] <purplefox> monday next is a holiday so I won't be around probably, but if you can get a PR we hopefully will review it.. the only thing is we have a lot to do next week, and other things may take priority, we'll see

[17:11:24] <purplefox> don't worry about examples in other languages, if you create java examples they will be automatically translated

[17:11:40] <rajith> purplefox: if have a video tutorial (which is what I'm planing) it might make it easy for someone to quickly run it… maybe u or julien can give it a try

[17:11:57] <rajith> purplefox: gotcha

[17:12:02] <purplefox> it's not the end of the world if it doesn't get into 3.0, we can just push it to 3.1 if need be

[17:12:38] <rajith> purplefox: I will try to have the documentation ready for tomorrow morning. The tutorial on monday.

[17:12:52] <rajith> purplefox: gotcha … but it would be nice to have it in 3.0 given the work that went into it

[17:13:09] <purplefox> i wouldn't worry too much about a tutorial, i'd rather see something sooner, without a tutorial if possible

[17:13:14] <purplefox> then we have more time

[17:14:07] <rajith> purplefox: I will email tonight, so u have it ready for review tomorrow morning (your time)

[17:14:25] <purplefox> ok great. thanks rajith

[17:14:30] <rajith> purplefox: the code and examples are ready even now :D

[17:14:44] <rajith> purplefox: but the docs will help to navigate it.

[17:14:48] <purplefox> is it in a branch somewhere?

[17:14:55] <rajith> purplefox: yea initial-work

[17:15:03] <purplefox> ok great, so we can take a look anyway :)

[17:15:24] <purplefox> but like i say, we do have a lot on our plate at the moment, and the core stuff will take priority

[17:15:31] <rajith> purplefox: yes please … the last commit was 28 days ago :p

[17:15:40] <rajith> purplefox: I understand

[17:15:55] <rajith> purplefox: I did a nice demo for my team and even one for david :)

[17:16:40] <rajith> purplefox: maybe I could have invited you to one of those :( … I should have thought about it

[17:17:54] <purplefox> hey np. anyway whatever happens we'll get there in the end

[17:18:22] <purplefox> thanks for putting the effort in :)

[17:19:10] <rajith> purplefox: yw .. thx for the help with figuring out the service interface. Btw Julien also helped with a lot of my questions.

[19:20:08] <AlexLehm> purplefox, i have changed the test to use a smaller mail

[19:21:06] <AlexLehm> not sure if the test really makes sense now

[21:44:06] <andyhedges_> Quick question on CORSHandler if I may. If I don't send an Origin header (e.g. a normal http request) then it returns a forbidden and doesn't continue processing routes

[21:44:39] <andyhedges_> is this a bug or deliberate?

[21:59:26] <purplefox> andyhedges_: i could be wrong but I believe valid CORS requests must contain an origin header, so this seems right to me…

[22:01:10] <andyhedges_> Yes, but a non CORs request shouldn't be forbidden for having an absent Origin header

[22:01:38] <andyhedges_> It happens when the pattern is set it ”.*“ not “*”

[22:01:46] <andyhedges_> works find with “*”

[22:02:20] <purplefox> it's been a while since i looked at this stuff… but i'd guess that if no origin header is sent then the server can't know whether it's an allowed origin or not, so the only sensible thing it can do it to reject it

[22:03:26] <andyhedges_> This is what happens when you make a normal browser request though

[22:03:40] <andyhedges_> i.e. you put the URL in the address bar

[22:06:06] <purplefox> i see so what you're saying is you want resources that are sometimes also accessed in a non cross origin way

[22:06:13] <purplefox> that seems fair enough

[22:06:48] <purplefox> the current impl assumes if you've put a CORS handler on some resources then they should always be acessed via cors

[22:07:32] <purplefox> could you add an issue to track this? looks like an easy fix :)

[22:21:16] <andyhedges_> Yes, easy fix

[22:21:27] <andyhedges_> I'll file an issue

[22:22:17] <andyhedges_> Most people using APIs try them out with Postman or a browser and come complaining if they get error codes back

[22:22:24] <andyhedges_> :)

[22:28:38] <andyhedges_> Filed against vertx-web in github, hope that's the right place

[22:47:45] <purplefox> andyhedges_: great. thanks

[22:48:52] <andyhedges_> np

[23:46:10] <AlexLehm> purplefox, after thinking a bit more about the pool test (while watching Eurovision) I have decided that the idea to time the operation is not good and changed it to asserting the connection count instead

[23:46:23] <AlexLehm> that works much better and doesn't rely on large mails