Skip to content
This repository has been archived by the owner on Aug 30, 2021. It is now read-only.

OAuth - not supported refresh case #288

Closed
sielay opened this issue Dec 4, 2014 · 5 comments
Closed

OAuth - not supported refresh case #288

sielay opened this issue Dec 4, 2014 · 5 comments

Comments

@sielay
Copy link

sielay commented Dec 4, 2014

Hi

From what I understand OAuth executed against some provider will not update user (will throw Exception that this provider is already used for this user). I think that is good, as far as you don't want to re-use same feature/redirections to refresh tokens.

If you agree with me I can prepare patch, that:

  • checks, if provider id field is the same, in that case update provider data
  • still throws error on mismatched id in the same provider
  • works both with user.providerData and user.additionalProvidersData

Hope it makes sense

@NeverOddOrEven
Copy link
Contributor

@sielay I am afraid I am not sure I follow. I am not the strongest with the OAuth portion of the stack. Can you provide some steps to recreate the issue you are reporting?

@sielay
Copy link
Author

sielay commented Dec 4, 2014

@NeverOddOrEven sorry, but that might be also my clunky English ;)

So imagine situation you use LinkedIn strategy to login. Your LinkedIn data including accessToken is being saved into user.providerData. That token in LinkedIn is valid up to 60 days (in theory). After that period you need new one.

Let's say you do a call to their API using token saved in user object. Their API says "sorry buddy, but your token has expired".

Most sense IMHO (to not duplicate functionality would be then redirect user to path /auth/linkedin which same like on login does a call to the API, gets token and should update data stored in the user object. Anyhow current flow in app/controllers/users/users.authentication.server.controller.js line 156 (https://github.com/meanjs/mean/blob/master/app/controllers/users/users.authentication.server.controller.js#L156) will say "Sorry buddy, but you have already connected that user to that provider, so bugger off".

IMHO in that else we should verify if ID from strategy is the same and in that case update rest of the data.

Hope it makes it more clear.

@NeverOddOrEven
Copy link
Contributor

Connect a meanjs install to some provider (facebook), allow your app to access your provider (facebook) data, then revoke your app's permission to that provider from within the provider (facebook). You should be able to reauth without a problem if you try to login with that provider again.

@sielay
Copy link
Author

sielay commented Dec 4, 2014

@NeverOddOrEven yes, but that is not a problem. Problem is that new (changed) data from provider aren't updating providerData. Logic of given line keeps entry from first binding.

If you store third party data, you should update it every time you have a chance to.

If you remove app in provider (facebook), my app will not know about it. If I re-enable it, in app nothing will change. App won't even know about anything changed.

This was referenced Dec 4, 2014
@NeverOddOrEven
Copy link
Contributor

Closing this. Active issue can be found here: #343

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants