The dialogue routes need to be renamed

[wolfeidau]

In the oauth2 routes section you have two routes see https://github.com/ninjablocks/douitsu/blob/master/lib/oauth2-routes.js#L63-L64

Github has the following URL https://github.com/login/oauth/authorize

The thing here is that our current route name implies that only dialogues will be shown by this route, which is not the case if the user has already trusted the application see #11.

[chico]

I've fixed the oauth flow so that users who have already trusted the client application will not need to again. It's ready to be tested on stage.

To further clarify:

• The client application directs the user to /dialog/authorize in the browser
• If the user is logged in and has already trusted the client application then the dialog page is not shown and an oauth code is returned back to the client application
• Otherwise the dialog page is shown and the user's decision (allow or deny) is posted to /dialog/authorize/decision, which in turn returns an oauth code back to the client application if they've clicked allow or access denied if they've clicked on deny.

[wolfeidau]

I haven't had a chance to look into this, I was going to review how github worked by dumping all the information i get back in a small example https://github.com/jaredhanson/passport-github project.

Key things to observe are:

• When is the dialogue presented.
• What access-token is presented once authenticated
• What happens if you log out and relogin, are you presented with the same access-token again

I would rather follow the lead of an existing implementation in this case.

[paulsavo]

Is this still a pertinent issue / enhancement?

[wolfeidau]

I have done a review of the github oauth2 provider and it will reissue the same token for a given application between sessions.

At the moment we are generating a new token per login to the application, this is less than ideal with some users already at 15 access tokens just doing some testing.

So workflow should be:

• user accesses the application and is redirected to douitsu.
• douitsu looks to see if there is an access-token already issued for that user / application combination, if so it returns that token, otherwise it generates one.
• user is redirected back to the application with that access-token

This will avoid us ending up with an endless churn of access tokens.

[chico]

I've fixed it so that access-tokens already issued for that user / application combination are returned.

Mark, I've deployed the fix to stage, could you test and close this ticket if you're happy with the fix?

[wolfeidau]

Yeah I will do some testing tomorrow as we are doing some more integration with our existing services.

Thanks