-
Notifications
You must be signed in to change notification settings - Fork 90
fix: authorization code error should be redirect #193
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
base: master
Are you sure you want to change the base?
fix: authorization code error should be redirect #193
Conversation
// | ||
// so if redirectUri is not already set, we try to set request redirect_uri params, fallback to first redirectUri of client | ||
/** @psalm-suppress RiskyTruthyFalsyComparison !empty($e->getHint()),empty($e->getRedirectUri()) we really want to check null and empty */ | ||
if (!empty($client) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please use explicit checks instead of empty()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
explicit checks now used on $client
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I meant everywhere in the patch. I try to avoid using empty()
for the reasons mentioned here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok no problem, I understand
new commit pushed
I just pushed a new commit to fix the coding standards, but the other bugs about static analysis and unit testing seem to be out of my scope. |
According to the specification, errors on the authorize endpoint should be transmitted to the client via a redirect in certain conditions:
https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1
This is not the case currently.
This PR seeks to resolve this case.