-
Notifications
You must be signed in to change notification settings - Fork 822
Relax redirect URL matching for the forward slash path case #710
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?
Conversation
Thanks for the contribution @AlexPlekhov, could you sign the contributor agreements so we can get this merged? |
Hi @petea, I've already done it immediately after creating PR. I hope you got email notifications. If didn't I'm ready to send those PDFs via email. |
Hi @petea, could you confirm that everything OK? I followed the steps in the contributor agreements. Please, write me back if I missed anything and still have to do something. |
Would be great to have this PR merged as it fixes an issue with Azure AD we have been experiencing. The Azure Portal gives us a redirect URI which looks like |
Hi all, @petea, I've resigned all docs as required by Mike Leszcz, was added to a WG, got a subscription email. |
I think this should be merged, as this is mission critical for functioning apps that rely on third party services and thus cannot influence how the backend behaves. |
@developerfromjokela note that there are workarounds for this situation discussed in #446. |
Yep, we already did the same. But wants to help the community to not face with it again. |
…"/" as equal to an empty path of "".
Hi @petea, will this get merged? We encountered this issue just today. We have support for multiple IdPs that support OIDC and customer wanted to use ADFS but it is not working cause ADFS appends |
@davidkaya note that there is a straightforward workaround for this issue that is detailed in #446. |
Add a comment for changes.
Can we get this PR moving again? I think the only remaining question is a missing comment? Would help in our case (using the Flutter AppAuth library where this is an issue as well (and mentioned workaround does not apply in our case) |
@DelcoigneYves |
Then poking @petea for a merge 💯 |
@DelcoigneYves @petea @davidkaya |
@petea LGTM! Can we please now merge it? 🙂 https://github.com/openid/AppAuth-iOS/blob/master/CONTRIBUTING.md#pull-request-reviews |
Hi @petea, is this going to get merged? |
I’m encountering a similar issue in a React Native application that uses AppAuth on iOS. Interestingly, this works fine on Android, but iOS fails due to strict redirect URL matching. The problem is that I have no control over the Identity Provider (IdP). The IdP rejects the client if I register the redirect URL with a trailing /, so I must use the version without the trailing slash. However, the IdP does append a trailing / when returning the authorization response, causing AppAuth’s strict path comparison to reject the redirect. Requesting the IdP to change its behavior isn’t feasible, as adding a trailing slash for my client would risk breaking existing integrations. Could we consider making the redirect URI/path matching more relaxed, or at least providing a configuration option where developers can specify alternative acceptable redirect URLs (e.g., allow both myapp://callback and myapp://callback/)? The suggested workarounds from previous discussions didn’t solve this issue for me. I resorted to creating a custom patch that’s applied automatically during pod install, but this approach is fragile — any upstream file structure change in AppAuth forces me to maintain and update the patch manually. I even tried intercepting/replacing the matching method at runtime, but had no success despite multiple attempts. Could we please get an update on this Pull Request, or some guidance on a cleaner long-term solution? A small change upstream would greatly improve AppAuth’s flexibility for these kinds of real-world IdP inconsistencies. |
Seems rather hopeless trying to get this merged, 2 years oh boy. maybe starting a fork with the patch is worth it? |
@developerfromjokela Yeah, starting a fork with the patch is definitely an option, but it comes with a few drawbacks. Maintaining a fork means I have to keep it in sync with upstream, manually merge updates, and ensure compatibility with future iOS/React Native changes. It works as a quick fix sure.. but I don't want to have another burden... I think for now patching the file during pod install might be the easiest fix for me.. :) will just have to make sure with future updates to update my patch file... I think the issue with this pull request is that the reviewer @petea seems to not be active anymore.. Can we have someone else that is actively maintaining this to have a look? |
Based on issue #446 sometimes a trailing slash added to path for redirect url.
Here a fix to make comparison regardless that trailing slash.
This issue affects react-native-app-auth lib:
FormidableLabs/react-native-app-auth#123
FormidableLabs/react-native-app-auth#336
and a few others.