0.8 - OAuth fixes #304
0.8 - OAuth fixes #304
Conversation
If the callbackURL doesn’t begin with a slash, the Passport `authenticate()` call will mess up the URL depending on the referrer’s url. So if the page is `domain.com/auth/github`, the callback URL will become `domain.com/auth/auth/github`. This normalizes the URL so that relative URLs always begin with a leading slash and absolute URLs don’t get touched.
This performs the same normalization to the comparison URL for the callback (as is done for the callbackURL). Also fixes typo in callbackUrl, updates it to callbackURL.
Previously, we were setting up this._tokenService and this._userService in the `setup` function. This was a problem because not all services are registered by the time `setup` runs. In order to continue to allow the passing of either strings or an actual service object, this PR checks if we only have a string reference to the service stored. If so, it uses the `app.service` method of service lookup before attempting to use the service. This also fixes a problem that was occurring when trying to call this._userService or this._tokenService when this was undefined inside the middleware callbacks.
|
I fixed a few more things, but it's still not quite finished. The OAuth flow completes correctly, now, but the response needs to be fixed, still. It's currently returning the JSON (includes the token and user fields) in the response instead of redirecting. So, we need to implement the |
| @@ -36,22 +38,24 @@ export class OAuth2Service { | |||
| updateUser(user, data) { | |||
| const idField = this.options.user.idField; | |||
| const id = user[idField]; | |||
| const userService = typeof this._userService === 'string' ? this.app.service(this._userService) : this._userService; | |||
There was a problem hiding this comment.
@marshallswain rather than duplicating this in each method can we DRY it up and put this in the setup like I have here: https://github.com/feathersjs/feathers-authentication/blob/0.8/src/services/oauth2.js#L176-L177?
There was a problem hiding this comment.
That's how it was originally setup, but if you do something like this:
app.configure(authentication);
app.use('/api/users', service(options));
The users service hasn't been setup by the time the auth plugin's setup method runs, so this._userService and this._tokenService are both stored on the class as undefined. I made it more DRY by putting the lookup into a class method in that last commit.
There was a problem hiding this comment.
Hmm. I don't remember that being an issue but you could be right that order might matter. In any case this is totally good for now. I might double check that order matters when it is in the setup method but it's pretty low priority right now. 👍
|
Other than my one comment, looks good. We have the default success handler (which is just redirect middleware) so you can set So I think we are pretty well covered there but maybe if we are using the default successhandler and don't have a successRedirect we should set a default one or throw an error telling the developer they need to set one for OAuth. I personally prefer the latter. |
This moves the dynamic service lookup to a function to be a bit more DRY.
If a successHandler hasn’t been passed, then the default `successHandler` will be used. The `successRedirect` will now be required in that scenario.
|
@ekryski I committed a line for the successHandler. Please check to make sure I understood you correctly. |
|
yup looks good homie. |
* First cut for authentication middleware * Fix service methods * Allow passing user service and service name
This fixes a couple of problems that were occurring in the 1st half of the OAuth flow (up until showing the GitHub auth page)I think the entire OAuth flow should work for every supported provider, now./, Passport would mess it up. (includes tests)See commit messages for more details.