-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using auth.authorize without res and scope #51
Comments
That is not correct. If you already have the
Regarding the
Even skipping the Let me know if I got you correct. |
I'm getting the first part now indeed. But is it necessary to explicitly set the scopes? The LinkedIn API states that in the request scope variables don't have to be passed. When they aren't passed the standard ones in the About the side note. I don't have the
This is correct right? If you'd make the check against the saved state in the object check if the state in the object is set, then you can also provice the getAccessToken method when not first calling |
scopes: Fair enough, I wasn't acknowledged that its OK to not pass the state: I think I got your point. You're referring in a case if you didn't use the wrapper to initiate the authentication and then you have to phase the error message as the https://github.com/ArkeologeN/node-linkedin/blob/master/lib/auth.js#L66 Which is practically OK and important from the security standpoint. Perhaps, you can also input your state while calling https://github.com/ArkeologeN/node-linkedin/blob/master/lib/main.js#L10
In either case -- you need to be aware of the state you're exchanging. |
Right now it is not possible to use auth.authorize without res and without wanting to pass scope variables (because you want to use the standard ones set in the API of the provider).
Side note: I'm using node-linkedin now without the authorize step (because in an AWS lambda environment I'm handling the code frontend with Satellizer and handling the access_token retrieval backend with node-linkedin. If I got the code correctly, I do have to first call auth.authorize now to set the state in de module, before being able to call auth.getAccessToken. Isn't this maybe an improvement?)
The text was updated successfully, but these errors were encountered: