Skip to content
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

Fail with oauth errors instead of masking them #309

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

thefloweringash
Copy link

Fixes #192 by making the code parameter optional, and allows the super method to raise errors.

I defer to the authors to assess the security implications.

@kevingriffin
Copy link

Any chance of getting this merged?

@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@thefloweringash
Copy link
Author

The logic in master still requires all responses, including error responses, to include a code, and throws and fails if the response doesn't. I believe this PR is still relevant and not stale.

@simi
Copy link
Owner

simi commented Jan 24, 2020

@thefloweringash hello, thanks for check and your activity. The reason of marking this as a stale is to bring back some activity.

This introduces backwards incompatible change AFAIK. I'll test and see what we can do about that other than bumping major version. Some kind of deprecation cycle will be nice. Any ideas?

@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@chrisandreae
Copy link

To me, this seems like fixing a bug rather than changing an intended spec. As such, I don't feel that a major version change should be necessary.

I think there's an expectation coming from Omniauth that strategies will pass up an error returned from the provider's callback. That omniauth-facebook didn't do this (and instead crashed out with :no_authorization_code) is deviating from that spec. Fixing that isn't changing the expected behaviour between omniauth and its consumers, since the expected spec was already to do the updated behaviour.

This is an externally observable behavior change, but that is true of any bug fix. I don’t think it’s reasonable to say that every bug fix is a backward-incompatible change because some inputs are no longer mishandled. (At some level, every change is an XKCD spacebar heater!)

@kevingriffin
Copy link

Was any testing done on this to work out if it'd be possible to get it in?

@molfar
Copy link

molfar commented Sep 18, 2022

Why is this PR is not merged?

@simi
Copy link
Owner

simi commented Sep 18, 2022

It is not clear to me how to release (per #309 (comment)).

Would be major bump enough?

@kevingriffin
Copy link

As @chrisandreae commented, although it is introducing a change, the change is to remove a crash. Perhaps someone is relying on the crash, if it doesn’t seem like it’s necessarily a major bump to me.

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

Successfully merging this pull request may close these issues.

NoAuthorizationCodeError when user cancels authorization with FB
5 participants