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

[01:26:57] <jtruelove> purplefox: i'm noticing that on the startup of a server via extending the abstract verticle that when it fails (I'm calling both and vertx.stop() ) it isn't exiting immediately it sits and hangs for a long time

[09:55:02] <purplefox> temporalfox: morning julien

[09:55:11] <temporalfox> hello purplefox

[09:55:12] <purplefox> temporalfox: how are you sir?

[09:55:25] <temporalfox> purplefox doing good

[09:55:37] <purplefox> great

[09:56:49] <temporalfox> I'm reviewing your changes

[10:03:12] <aesteve> purplefox: sorry to annoy you, may I ask for an advice ?

[10:07:36] <purplefox> temporalfox: ha, you read my mind ;)

[10:07:39] <purplefox> aesteve: sure…

[10:08:21] <aesteve> do you think it's more interesting, in an example, to show how to use a worker verticle, or to show how to make async http requests ?

[10:09:09] <aesteve> in your opinion what do people have the most trouble with ?

[10:13:06] <purplefox> we should have examples of both

[10:14:42] <aesteve> mmh ok. I just thought maybe if I add another type of “feed” like a twitter feed I could use both

[10:15:38] <aesteve> a blocking API reading RSS feed like Rome, standard httpClient.get(“…”)

[10:15:42] <aesteve> I'll try to do that

[10:15:49] <purplefox> ok.. but try not to make the example too contrived

[10:16:02] <purplefox> they should be real world


[10:16:40] <purplefox> so we have webapps and inside webapps there are:

[10:16:41] <aesteve> that's why I chose an RSS aggregator in the first place, it was some concrete example

[10:16:44] <purplefox> 1. server side rendering

[10:16:47] <purplefox> 2. client side rendering

[10:16:49] <purplefox> 3. REST style

[10:16:51] <purplefox> 4. etc

[10:17:29] <aesteve> I think the example responds to all that. But all at once

[10:19:01] <aesteve> but anyway, the best thing I can do is finish it and let you see it. If you think it fits it's cool, if not I'll write some documentation/blog article detailing how I used Vert.x and why for that kind of application

[10:19:04] <aesteve> no big deal

[10:19:26] <aesteve> thanks for the answer

[10:57:09] <purplefox> aesteve: hey, no worries. thanks for doing this :)

[10:59:56] <aesteve> np :) btw I also think the blog in vert.x website would be a very very good idea. (I think Julien mentionned it some days ago). It would be a perfect way to show how dynamic and creative the community can be

[11:00:50] <purplefox> agreed, but we need someone to do this :)

[11:00:59] <aesteve> maybe not for 3.0 as you mentionned, but don't forget about it ! ;) a lot of people have been working (or are working) on vertx side projects and it's always nice to discover things through blog article

[11:01:45] <purplefox> well i would say.. if you want it, submit a PR. It just doesn't scale for me (and Julien) to do everything ;)

[11:02:24] <aesteve> OK, perhaps I should ask first on the group which blogging engine we should use ?

[11:02:33] <aesteve> but I'll do it :)

[11:07:35] <stephane_bastian> purplefox: hello

[11:07:51] <stephane_bastian> purplefox: i am going over the detail of the Auth refactoring.

[11:08:38] <stephane_bastian> quiick question: I have been puzzled as to why AuthProvider.hasRole(JsonObject principal)

[11:11:42] <stephane_bastian> takes a jsonObject. Is there any use cases where a Set<String> princpals would not do it? –> AuthProvider.hasRole(Set<String> principals)

[11:12:00] <stephane_bastian> for instance principals could be userId, social security number, or something else?

[11:13:55] <stephane_bastian> is the idea that the princpal jsonObject could be somethign like this: {'userId': 'myid', 'socialSecurityNumber': 'mysocsecnumber'} ?

[11:15:47] <purplefox> i think the principal can be anything, e.g. in shiro it is just “object”

[11:15:56] <purplefox> so we use jsonobject to make it as flexible as possible

[11:18:34] <stephane_bastian> Ok. Thx

[11:24:43] <stephane_bastian> purplefox: the way I am planning to proceed is to model a use case that is fairly 'advanced'.

[11:25:30] <stephane_bastian> we know that the common use case works because that's what is already implemented in vertx right now ;)

[11:26:36] <stephane_bastian> purplefox: the use case could be something such as authentication via a third party such as Facebook + rememberMe. Sounds good to you?

[11:36:08] <purplefox> stephane_bastian: ok

[11:40:37] <purplefox> stephane_bastian: i'm going to grab something to eat, then i'm going to spend some time looking at this as well, so we can chat and exchange ideas

[11:41:02] <stephane_bastian> great

[11:41:16] <purplefox> adietisheim: welcome to the vert.x irc channel :)

[11:41:54] <purplefox> adietisheim: this is one major part of the Vert.x community, the other are the google groups

[11:42:08] <adietisheim> purplefox: thx :)

[11:42:39] <purplefox> stephane_bastian: so basically this is the biggest piece of work outstanding for 3.0, so i'd like to get it sorted asap

[11:43:00] <purplefox> adietisheim: julien is temporalfox

[11:44:04] <stephane_bastian> I am working on it all day today. half day Thursday and half day Friday + Wednesday til Friday next week

[11:44:54] <stephane_bastian> that's the best I can do right now. Can't commit the whole week next week :(


[11:47:04] <adietisheim> temporalfox: hi, julien viet?

[11:47:10] <temporalfox> yes

[11:47:20] <adietisheim> temporalfox: cool, bonjour! :)

[11:47:59] <adietisheim> temporalfox: joining an watching here and there, but unfortunately not much spare time to contribute :(

[11:48:11] <adietisheim> temporalfox: even though I'd love to

[11:49:44] <purplefox> adietisheim: ah sorry, i thought you were someone else! ;)

[11:50:01] <adietisheim> purplefox: np, figured out ;)

[11:50:01] <purplefox> apologies. but in any case, you have an introduction now ;)

[11:50:36] <adietisheim> purplefox: sure thing, always nice. Even though we already know each other, met once at EclipseCon with Max in Boston (?)

[11:50:54] <purplefox> yeah sorry, too much context switching makes my brain malfunction ;)

[11:51:00] <adietisheim> purplefox: np

[12:03:27] <purplefox> stephane_bastian: no problem. i totally understand, you're making a great contribution already :)

[12:40:40] <purplefox> stephane_bastian: regarding the session/auth stuff…

[12:40:58] <purplefox> stephane_bastian: if we just remove the auth related stuff from session

[12:41:11] <purplefox> stephane_bastian: and have a routingContext.getUser() which returns the user object

[12:42:18] <purplefox> stephane_bastian: and change auth provider to accept combined credentials/principal in login

[12:42:24] <purplefox> then are we done?

[12:42:35] <purplefox> is there any use case this doesn't support?

[13:14:42] <purplefox> stephane_bastian: are you there?

[13:41:56] <stephane_bastian> purplefox: I am back

[13:43:23] <purplefox> stephane_bastian: could you take a look at my last comments above?

[13:43:30] <stephane_bastian> purplefox: not sure we are done.

[13:44:09] <purplefox> could you describe a user case where this does not work?

[13:44:11] <stephane_bastian> when I look at authenticating via an external AuthProvider such as Twitter or Facebook, it gets tricky

[13:44:53] <purplefox> could you elaborate on that?

[13:45:59] <stephane_bastian> ok. lets go over a possible impl of a Facebook or Twitter provider then

[13:47:39] <stephane_bastian> first I assume that we've got to implement a FacebookAuthHandler and a FacebookAuthProvider. Right?

[13:48:11] <purplefox> i'm not worried about the various handlers at this point

[13:48:42] <purplefox> we're not going to do those before 3.0

[13:48:58] <purplefox> but what we do need to do is make sure the Session/User/AuthProvider interfaces are correct

[13:49:12] <purplefox> so that oauth and stuff like that can be added later without having to make further changes

[13:49:29] <stephane_bastian> I know they are out for 3.0 , just want to make sure the various abstrations works for them.

[13:49:33] <purplefox> yes

[13:49:45] <purplefox> so my question is, what part of the proposal above does not work for oauth?

[13:50:33] <stephane_bastian> ok so in your opinion what it suppose to happen when I call FacebookProvider.login(xyz) ?

[13:51:25] <purplefox> what is xyz?

[13:52:13] <purplefox> i thought with oauth the login is done elsewhere

[13:52:22] <purplefox> i.e. on the google site/facebook site

[13:52:27] <purplefox> so we just have a token

[13:52:31] <purplefox> and we *authorise* with it

[13:53:35] <stephane_bastian> o we call the Facebook end point which basically check that the token is valid. right?

[13:55:57] <purplefox> i am not an expert on oauth but i think that's how it works

[13:56:39] <purplefox> so i guess with a vert.x oauth auth provider, we never call login, but call authorise passing in the token

[13:58:36] <stephane_bastian> that's how I feel it should work as well.

[13:59:22] <stephane_bastian> however these are the bits i am not so sure about:

[14:00:33] <stephane_bastian> 1) Should we call facebooProvider.authorize(xyz) on every request?

[14:01:36] <purplefox> we can cache results of authorise in the session

[14:01:51] <purplefox> (if there is a session)

[14:01:52] <stephane_bastian> 2) the access token we got from facebook may expire at some point and time. And so there is a refreshToken you should use to renew the access token

[14:02:37] <purplefox> where is refreshToken?

[14:03:31] <stephane_bastian> when you do auth with facebook it returns some json with the access token and other things such as a refresh token that you should use to renew the access token when it expires.

[14:03:54] <purplefox> ok, so that looks like something that would be done by a handler

[14:04:05] <stephane_bastian> this would be done in the FacebookHandler somewhere

[14:04:08] <aesteve> (that's standard OAuth, not something related to Facebook especially)

[14:04:09] <stephane_bastian> right

[14:04:24] <purplefox> so i'm not sure it requires anything special in AuthProvider, User or Session

[14:04:26] <stephane_bastian> aesteve: yep that? right

[14:06:45] <stephane_bastian> purplefox: Right. but it means that access token and the refresh token should be in the json when we call facebookProvider.authorize(xyz).

[14:10:12] <purplefox> why the refresh token?

[14:11:04] <purplefox> i thought we agreed the refresh token was handled by a handler

[14:11:13] <stephane_bastian> because in facebook.authorize(xyz), we call the facebook end point to check that the token is valid.

[14:11:35] <purplefox> why?

[14:11:43] <stephane_bastian> if it's expired, we shold then renew it with the refresh token, no ?

[14:12:00] <purplefox> yes but i thought we said previously that's done in a handler…?

[14:12:11] <purplefox> “this would be done in the FacebookHandler somewhere”

[14:13:16] <stephane_bastian> what is done by a handler is the fact that we call the various facebook end points to eventually get an access token along with a refresh token and some others things

[14:14:48] <purplefox> the handler can also refresh the token if need be. i don't think that wold have to be done in an authprovider

[14:16:51] <stephane_bastian> so I am confused. what are exactly the roles and responsabilities of an AuthProvider in the case of a Facebook or oAuth authentication ?

[14:17:09] <purplefox> but i think it is moot anyway. if authorise can take anything then the implementation can do whatever it wants with it

[14:17:48] <stephane_bastian> ;)

[14:17:49] <purplefox> i don't think it does authentication at all. in oauth i believe the authentication is handled by the provider. but it can do authorisation

[14:18:39] <stephane_bastian> I am really not sure how it is supposed to work.

[14:19:03] <purplefox> like i say i am not an oauth expert.. but it's my understanding in oauth

[14:19:13] <purplefox> that you are redirected to the provider to login (authenticate)

[14:19:18] <stephane_bastian> my first thoughs was that the Handler was supposed to call the facebook endpoints to get a temp code.

[14:19:24] <purplefox> so this is not something we handle at all

[14:19:35] <stephane_bastian> then my second though was that the AuthProvider would use that code to get an Accesstoken

[14:20:01] <stephane_bastian> that'sfine if everything is done in the Handler.

[14:20:24] <stephane_bastian> however, it facebookHandler.authorize check that an access token is still valid

[14:20:49] <stephane_bastian> then at the very least we should modify the api so that the asyncResult returns an error code and not null

[14:21:03] <stephane_bastian> so that the handler knows that the token ios expired and must be renew.

[14:22:22] <stephane_bastian> otherwise the Handler does not know why the provider.authorize didn't work. bad token? expired token? tampered token? revoked authorization from the facebook user?

[14:24:42] <stephane_bastian> do you understand what I am saying?

[14:26:46] <purplefox> i don't know enough about oauth to answer really

[14:27:21] <purplefox> but does it matter? if the authprovider interface is flexible enough the auth provider can do whatever it wants

[14:30:13] <purplefox> aiui, with oauth they basically have a token, doesn't really matter HOW they get the token, but as long as we can authorize based on that, i think we are good

[14:31:16] <purplefox> it's actually surprising hard to find a clear diagram on the interwebs which shows the interactions in oauth :(

[14:32:14] <stephane_bastian> I know it's a real pain in the ass, spending too much time to understand something farly simple …

[14:32:57] <stephane_bastian> the thing with oAuth though is that we will never really authorize anything in Vertx right?

[14:33:04] <aesteve> guys, there's something I don't understand in your discussion : are we talking about providing OAuth (in the users' app) or connecting to OAuth 3rd party services ?

[14:33:21] <stephane_bastian> connecting to oAuth

[14:33:24] <aesteve> ok

[14:33:44] <stephane_bastian> I thing someone is working on an oAuth client though

[14:34:56] <stephane_bastian> In any case we'll see qickly how if it flies or Not with Oauth because I will use the refactor API and quickly hack a Provider that connects to Facebook

[14:37:29] <stephane_bastian> question: right now a call to provider.login(xys) return the result in a handler → Handler<AsyncResult<Void» handler. To be safe we should probably make it Handler<AsyncResult<Integer» handler so that it can return error code no?

[14:38:31] <stephane_bastian> Integer or String or whatever you like to stuff in error codes that someone could use.

[14:39:36] <stephane_bastian> purplefox: in the interface User we currently plan to provide a method session() to return a Session.

[14:40:43] <aesteve> if it helps, GitHub's documentation is the best I've read so far to explain Oauth's flow :

[14:40:44] <stephane_bastian> I think it would be even easier for end user to simply return a Map<String, Object> containing user's data –> Map<String, Object>

[14:41:03] <stephane_bastian> Thx.

[14:41:15] <stephane_bastian> I am using not that bas but still not great

[14:55:00] <stephane_bastian> purplefox: so what do you think of removing the Session interface

[14:56:23] <stephane_bastian> purplefox: if contains any data we persist them just like today.

[14:57:10] <purplefox> i like session

[14:57:51] <stephane_bastian> IMHO Session has always been a strange name to say 'user data'.

[14:58:22] <purplefox> most web frameworks have the concept of a session so it's not unusual :)

[14:58:29] <purplefox> i think users expect that

[14:58:38] <stephane_bastian> you are used to the name session. If you were to explain what it is to someone who is not in software, you'll say 'the data of the user'. ;)

[14:59:34] <stephane_bastian> well…. it's like saying people have been using servlet for years. let keep servlet around in Vertx because people expect that :)

[15:01:46] <stephane_bastian> plus, a User should have a method such as User.lastSeen() or User.lastAccess() which is redundant with the Session.lastAccess()

[15:02:01] <stephane_bastian> the only thing left in the Session is the map<String, Object>

[15:29:49] <purplefox> I think Session is different to user since it's linked to the lifetime of a browser session

[15:32:14] <purplefox> i think there are two separate issues here:

[15:32:24] <millrossjez> @purplefox, I found some useful OAuth2 stuff eventually @stephanebastian I'm working on an oAuth2 client at present but it's not getting nearly enough of my time

[15:32:45] <purplefox> 1) is the authprovider api flexible enough to cope with authorization using, e.g. a bearer token?

[15:33:38] <purplefox> 2) session/user

[15:36:36] <stephane_bastian> @millrossjez: thx for the info. let me know when it's good enough to be tested

[15:38:37] <millrossjez> I haven't even looked at the refresh token side of things yet but there's been an underlying assumption on my part all the way through that tokens will be associated with the user session (though we can wrap them in whatever structure we want)

[15:39:51] <stephane_bastian> purplefox: right now for authorization the api expects the principal not a token

[15:40:15] <stephane_bastian> currently the signature is: void AuthProvider.hasPermission(JsonObject principal, String permission, Handler<AsyncResult<Boolean» resultHandler)

[15:40:44] <stephane_bastian> somehow the bearertoken must be translated to a principal (userid or something)

[15:41:15] <stephane_bastian> the method AuthProvider.login(xx) expects a token

[15:42:57] <stephane_bastian> for 2) session/user, yes they are different BUT I would not say that a Session is linked to the lifetime of a browser session

[15:47:32] <purplefox> ok… so lets rewind a bit

[15:47:52] <purplefox> fundamentally the API that the user interacts with is the Session API (or now the User API)

[15:48:06] <purplefox> which has methods hasrole, haspermission etc

[15:48:54] <purplefox> depending on what kind of auth is being used the way of determining hasrole, haspermission could be completely different

[15:48:58] <purplefox> it could be:

[15:49:06] <purplefox> basic database auth

[15:49:08] <purplefox> jwt token

[15:49:12] <purplefox> oauth bearer token

[15:49:13] <purplefox> whatever

[15:49:45] <purplefox> so in the case of say jwt or oauth it might not be appropriate to use authprovider at all

[15:50:01] <purplefox> the appropriate handler could inject the implementation into the user

[15:50:35] <purplefox> so for oauth/jwt you just compare the role requested to the role in the jwt token

[15:52:04] <stephane_bastian> ok

[15:53:15] <stephane_bastian> for oauth they probably won't be any roles I think

[15:54:00] <purplefox> aren't scopes the same as roles in oauth?

[15:56:03] <stephane_bastian> it's true that the User Api now looks like a twin brother of the Session API ;) but the userId is always the same. The Session ID is different making it difficult to track the user

[15:57:52] <stephane_bastian> for scopes it's my understanding that they are more or less permissions not roles (you've got the scope 'view my friends' for instance)

[15:58:15] <purplefox> ok that's fine as we support permissions too

[15:59:03] <purplefox> so…

[15:59:16] <purplefox> if we let a handler set the User object on the routingcontext

[15:59:33] <purplefox> then an oauth handler can set a different implementation to a jwt hander to a basic auth handler

[15:59:36] <purplefox> and problem solved?

[16:01:08] <stephane_bastian> right. I think so.

[16:05:05] <stephane_bastian> Don't you think that this is weird that AuthProvider might not be appropriate for oAuth ?

[16:07:03] <purplefox> maybe not, if you think about it, when using oauth the actual auth provider is not local, it's a remote auth provider - i.e. google, facebook or whatever so it kind of makes sense

[16:07:58] <purplefox> and auth provider relies on a very specific principal, role, permission type model which doesn't make a lot of sense any more when you're dealing with oauth

[16:09:44] <stephane_bastian> yeah I agree, but at the same time, I would expect the AuthProvider API to do its job on something that's not local (JDBC, LDAP).

[16:11:10] <stephane_bastian> the problem is that I am not an expert on oAuth and can't really tell how the AuthProvider fits in this model. sure we can do everything in Handler, even JDBC, LDAP and such.

[16:11:17] <purplefox> when i say remote i mean, the interaction of login does not even go through our web app at all

[16:11:47] <stephane_bastian> yeah I got what you meant

[16:12:49] <purplefox> ok but that's different from remote jdbc as it will go through our app, even though its remote

[16:12:57] <stephane_bastian> hold on a minute. I just came accross an impl of someone who built a Shiro Realm to connect via Facebook

[16:13:09] <stephane_bastian>

[16:14:00] <stephane_bastian> to me Shiro Realm are almost equivalent in term of functionality to Vertx AuthProvider

[16:15:35] <purplefox> i don't really understand how that can possibly work, because in oauth you need to redirect the users browser to the facebook site - how can you do that by calling a shiro api?

[16:16:04] <stephane_bastian> well this is what I understood:

[16:17:15] <stephane_bastian> the guy enters its username/password in the facebook form. and get back an access code

[16:18:42] <stephane_bastian> they use the access code to get the final access token in the realm.

[16:19:42] <stephane_bastian> if we make the between Shiro and Vertx AuthProvider. this means that the AuthProvider is used to take the oauthaccess code and get the access token. right? [16:20:29] <purplefox> how do they implement hasrole/haspermission? [16:21:30] <stephane_bastian> they don't. [16:21:44] <purplefox> so how do you know if someone can access a resource? [16:23:18] <stephane_bastian> to me for a web app, oAuth is mainly used to simply authenticate. when you authenticate you create a user in your own app using the info you got from facebook. you can then freely assign roles/permissions [16:24:05] <purplefox> i see so only using it for authentication not authorisation [16:24:06] <stephane_bastian> but hey that's just how I would do thing. [16:25:00] <purplefox> but then you need to store the mapping of user to roles/permissions somewhere else [16:25:00] <D-Spair> purplefox: Yeah, OAuth doesn't do things like roles/permissions. [16:25:01] <stephane_bastian> well if you think about it, you are not going to use the facebook UI to manage the roles and permissions of *your* app. [16:25:02] <purplefox> e.g. in a database [16:25:56] <purplefox> but then JWT *does* contain the roles/permissions in the token [16:26:09] <D-Spair> stephane_bastian: I would suggest that you register handlers for OAuth to do authentication AND a handler for local roles/permissions and thus you avoid the problem… I am having to do the same thing in implementing OAuth for SonarQube. [16:26:09] <purplefox> summary: it's all a complex overloaded pita ;) [16:27:30] <stephane_bastian> yes. that? why in the requirement documents I wrote somewhere that we need to 'chain' AuthProviders. so you can authticate using facebook, google, linkedin, your db and authorize using your db [16:27:43] <stephane_bastian> it? definitely a pita ;) [16:28:28] <purplefox> my solution right now is not to worry about any of that, and choose a level of abstraction high enough that we can just plugin in whatever implementation we want later [16:28:36] <stephane_bastian> pmlopes: Hi, could you shed some lights on how you?l use jwt please? [16:29:33] <purplefox> if what we prevent to the user is a User object with: [16:29:56] <purplefox> getprincipal, hasrole and haspermission, then that can implemented however a particular impl wants [16:30:02] <purplefox> but we don't have to worry about that for now [16:30:09] <pmlopes> hi, sorry i wasn't following the discussion, currently with yoke we use it like this, we have a known api where given a set of credentials username/password you will get a json response with a token [16:30:44] <stephane_bastian> ok. what I suggest is that we still rename the Session to User [16:31:20] <pmlopes> now for each client request the header Authorization is added with bearer + token [16:31:40] <D-Spair> JWT is difficult to explain easily. [16:31:58] <stephane_bastian> 2) we make sure that user's data ;) can be stored on the server-side OR client-side [16:32:15] <pmlopes> now the token is a json document, and inside i keep claims, a claim is whatever you want it to be, only a few are registered in the official registry [16:32:35] <D-Spair> You have to build the JWT JSON doc, encrypt is using a key along with some metadata, send it to the OAuth provider, and receive back a token document. [16:32:44] <pmlopes> a typical usage is that you create a claim for your roles so say for example {roles: [r1, r2, r3]} [16:34:14] <stephane_bastian> purplefox: when it's done, I will quickly spend some cycles to hack a oAuthProvider along with a Handler that does what we talked about. this way is something is missing in the API, we'll know and have time to fix it before the final release [16:34:29] <D-Spair> And worse yet, with OAuth, the specification allows for different returned document types. GitHub/Google return JSON, but Facebutt returns a multipart/form-data IIRC [16:34:33] <purplefox> ok sounds good [16:34:48] <pmlopes> stephane_bastian: did you saw my reply with a example fo required handlers for oauth2? [16:34:56] <stephane_bastian> in any case, I desperately need to be able to auth using Facebook, Twitter, google and Linked [16:34:59] <purplefox> i have to shoot out for a bit guys, but will be back later. i trust you will have solved all the issues by then! ;) [16:35:17] <D-Spair> purplefox: Sure, no problem </sarcasm> [16:35:22] <D-Spair> :stuck_out_tongue: [16:37:20] <pmlopes> ok, from what i read i think we need to split things, OAuth2 and JWT are different things, one can have JWT without OAuth/Oauth2 at all [16:37:21] <stephane_bastian> pmlopes: no where is it? [16:38:16] <pmlopes> JWT by itself is simple, someone issues an access token and encodes there whatever they want you can of couse use this token as the OAuth token but for OAuth it does not matter since the token is opaque to the protocol [16:38:45] <pmlopes>!topic/vertx/IEti_jlVflg [16:40:03] <pmlopes> going back, the JWT RFC does not reference or mandate OAuth so that is why it is quite nice for APIs, the implementation is trivial I did it for Yoke, the only missing part is recursive tokens and encryption instead of signatures but the logic is the same [16:40:40] <stephane_bastian> pmlopes: agree that we've got to split things. JWT could be used to stored users'data on the client. no oauth at all [16:43:55] <stephane_bastian> pmlopes: for the key store (in the requirements document), it is used to sign/encrypt/mac right? [16:44:18] <pmlopes> now most people “Abuse” JWT to contain roles as claims, however the official registry “” does not refer to any standard name for the key, so we must agree and document something like, in a jwt token a key named: roles will be used to validate roles and a key named permissions will be used to validate permissions [16:44:39] <pmlopes> e.g.: {roles: [a, b, c], permissions: [a1, a2, a3]} [16:44:57] <pmlopes> or we even make these 2 properties names a configuration variable [16:45:34] <pmlopes> authentication of a JWT is performed by verifying the signature or performing a decryption of the token [16:46:18] <pmlopes> the principal should be a String, either the full token, or if the token contains a property “sub” the value of that field [16:46:44] <pmlopes> the reason for this is that according to the RFC all properties are optional [16:46:49] <stephane_bastian> pmlopes:ok [16:49:00] <pmlopes> now for OAuth2 it is a bit more tricky, first we need to handle the need to handle the grant type, and if i am not mistaken there are 4 [16:49:34] <pmlopes> authorization code, implicit, password, client credentials [16:50:02] <pmlopes> if we are doing the authentication with user/pass then we need to follow the “password” flow [16:50:26] <pmlopes> if we are relying to 3rd party we need to use authorization code, or client credentials [16:51:23] <pmlopes> i think client credentials is when the auth is handled server side, and authorization code when used in a single page application which cannot protect the client secret [16:52:56] <pmlopes> about OAuth1 i've no idea anymore about all its details, should we still support it? [16:54:24] <stephane_bastian> IMOH oAuth2 has higher priority right now [16:56:18] <pmlopes> i agree [16:58:24] <beckje01> I have some basic oauth2 working in milestone 4 I?m happy to share any code back if it would be helpful [16:58:44] <beckje01> I did it based on the OAuth Introspection draft spec [17:00:14] <stephane_bastian> beckj01: cool. do you have a github project somehwere? [17:00:53] <beckje01> I?ll put it out into gists [17:01:06] <beckje01> it was used in an internal project but would love to help get it into main [17:01:47] <pmlopes> i'll have to leave you guys, stephane if you need anything from me, you can contact me from the forum [17:03:37] <jtruelove> purplefox did you see the message I posted about failing verticle start and calling stop on the vertx object not making the process exit [17:04:18] <beckje01> [17:05:06] <beckje01> That is all for the bearer token and oauth intorspection stuff [17:05:38] <beckje01> I?m also happy contribute code directly once the session stuff was sorted out [17:05:52] <beckje01> I was a bit fuzzy around there [17:06:37] <jtruelove> that looks pretty clean, and you provide some auth provider in house or external etc…? [17:07:20] <beckje01> yeah we have a shared oauth system that exposes the introspection endpoint [17:08:09] <beckje01> that isn?t vertx, therer are similar endpoints available if you are doing bearer tokens [17:08:51] <beckje01> that aren?t the introspection spec but easy to adapt [17:13:30] <arek_deepinit> what You guys need? [17:13:44] <arek_deepinit> there is a framework for vert.x [17:14:00] <arek_deepinit> for vert.x 2 its Yoke [17:14:21] <arek_deepinit> for vert.x 3 its apex [17:15:43] <millrossjez> @stephane_bastian, pmlopes I wasn't going to support oauth1, at least initially, but only oauth2 [17:16:34] <arek_deepinit> pmlopes: Yoke author? [17:16:35] <stephane_bastian> millrossjez: ok fine [17:16:39] <millrossjez> @beckje01: awesome, I'll take a look, any chance you can post that on the group (either vertx or vertx-dev) - sounds like you've gone further with that than I've got so far [17:17:31] <beckje01> Sure any suggestions for a title? I don?t normally get a response if I post on there [17:19:22] <millrossjez> let me find the thread on vertx-dev, maybe we can extend that discussion :) [17:19:49] <millrossjez>!searchin/vertx-dev/oauth/vertx-dev/HolLTS-AU3Q/XD2267xvaQgJ [17:20:22] <millrossjez> if you've already got stuff working maybe we should build on that, all I've done so far is very incomplete, I just identified a couple of classes I'd need and built them out, adding the github link to my repo now [17:20:50] <beckje01> its only working for the bearer token flow [17:21:06] <millrossjez> ok, which is a bit different to what I'm doing I think [17:21:10] <beckje01> so vertx isn?t issueing the token at all and it isn?t doing the redirect flow [17:21:21] <millrossjez> I'm building a redirect flow :) [17:21:41] <beckje01> yeah that is only good for webapps and we tend to use vertx in our api layer [17:21:53] <beckje01> thats why we needed the bearer stuff [17:22:00] <millrossjez> but it makes sense to have all oauth2 stuff in one place though, not least to keep track of what is and isn't being done :) [17:22:02] <beckje01> stupid mobile clients [17:22:09] <beckje01> yeah [17:23:03] <millrossjez> when I have a redirect flow that actually seems to work (and I'll probably have to simulate an oauth2 provider with some hardcoded behaviours to test it out) I was going to look at the pac4j-vertx stuff as they want to port it to vertx 3 [17:23:40] <millrossjez> but I didn't want to change horses in midrace given how much more sidetracked I've been than expected [17:23:45] <beckje01> feel free to ping me if you want help on anything i?ve used pac4j outside of vertx as well [17:24:07] <millrossjez> thanks, all I actually need is a time machine to get myself an extra day a week or so :) [17:24:36] <millrossjez> (I hate working in 30 minute chunks) [18:51:48] <aesteve> does anyone know about cloud9 ? it could be interesting to add a Vert.x “cartridge” to the cloud9 environment ? [19:17:29] <temporalfox> purplefox tomorrow is french holiday [19:17:42] <temporalfox> purplefox and I left you a PR to review for the metrics stuff [19:25:07] <purplefox> temporalfox: ok thanks. have a good holiday! [19:42:35] <jtruelove> purplefox: did you see that message above about the app not exitng [19:42:43] <jtruelove> i don't have a bouncer setup yet [19:44:41] <purplefox> jtruelove: no, sorry [19:52:54] <purplefox> jtruelove: do you have a link? [19:53:14] <purplefox> back in a bit (dinner) [20:21:44] <jtruelove> here's the text of it “i'm noticing that on the startup of a server via extending the abstract verticle that when it fails (I'm calling both and vertx.stop() ) it isn't exiting immediately it sits and hangs for a long time” [20:25:23] <jtruelove> purplefox: I could give you a gist if you need it, locally I'm just initializing a cassandra session at startup that fails in this case intentionally then failing the startupCallback passed to the verticle start function and calling vertx.stop() [20:54:41] <purplefox> jtruelove: yeah, if you could come up with a simple reproducer that would be a great help :) [20:57:29] <jtruelove> cool i'll get you gist shortly [21:50:55] <jtruelove> purplefox: here you go [21:51:26] <jtruelove> it does eventually exit it just sits there for a very long time [21:52:07] <jtruelove> i'm running it like 'java -jar my-jar-here.jar' [21:52:29] <jtruelove> [21:52:42] <jtruelove> then it just hangs for a while [22:06:42] <jtruelove> i'm running on mac but i tried it on linux [22:06:53] <jtruelove> and it seems to be the same [22:07:09] <jtruelove> also it doesn't really respond to ctrl-C either which is sort of annoying [22:07:44] <jtruelove> on mac I ran it with 'time' and got this info [22:07:49] <jtruelove> [22:08:05] <jtruelove> do you want me to cut a bug or am I doing something wrong? [22:12:12] <jtruelove> [23:07:53] <jtruelove> purplefox: shall i just create a git issue? [23:51:58] <jtruelove> dropped it here just so we don't loose it