I am starting to build an app that authenticates to a third party web service, and I'm having problems getting the authentication working. The login page is displayed correctly, but once the user logs in an error message is displayed: "The URL can't be shown".
I'm working on the iOS version of my app first, so I've only tested this on iOS so far using the Simulator. I initially thought that I wasn't registering the URL scheme for the redirect URL correctly, but if I put a breakpoint in AppDelegate.OpenURL(), and enter a URL with my URL scheme in Safari my app is launched.
Handling the OAuth2Authenticator.Error event didn't give any more information beyond the same error message.
This is my first time working with Xamarin Forms and Xamarin Auth, so I'm not sure what else to do in order to debug the problem. What else can I do in order to figure out the root cause of this error?
Turns out this was due to user error.
The redirect URL I was using didn't match the redirect URL I registered with the web service. Once I made them the same, the redirect URL worked as expected.
Related
We have an issue with a asp.net core 3.1 MVC application. The application is using the built in asp.net Identity feature. The application is working well for existing users. If you hit any [Authorized] route, you are redirected to the login page as expected.
However, rather than have a registration process in our app, for new users, we onboard them via Stripe Checkout. Upon successful payment, stripe redirects to a specific route in our application /conversion/success/{sessionid} where sessionid is the Stripe session. This action is marked as [AllowAnonymous].
We then pull the necessary customer details from Stripe, create a user in our repository via UserManager<T>. We then call SignInManager<T>.SignInAsync() to sign in the new user, before redirecting the new user to the [Authorized] home page.
This process works perfectly when running locally on our test machines. Also, when running on our production server (Azure App Service) it also works perfectly when we hit the route manually through the browser.
However, when we actually run the process through Stripe, complete a payment and let Stripe redirect the customer, we get a strange behaviour.
The conversion route is hit, the user record is created, the sign in process completes but upon redirection to home page, the authentication middleware takes over, says it's not authenticated and redirects to the login page.
Just to compound matters further, if you then simply type in the home page route in the browser, the user is in fact logged in exactly as expected and the application works perfectly.
Using Fiddler to intercept the calls and look at headers, etc. we can't see why there would be a different behaviour when coming from Stripe as opposed to typing directly. We've even tried redirecting from a different website to our registration process and that works as expected too.
Any idea why we are seeing this behaviour?
---- Update ---
If, rather than redirect to home page at the end of the onboarding process, we simply show a simple View with an anchor link to home page, the user can then go to home page as expected.
Is it possible that you're rendering the page before authentication has been completed? Since UserManager uses a cookie to establish the user's session, authentication needs to complete before any response headers or body is set so that the Set-Cookie header can be sent in the response.
Based on what you described it sounds like the user is hitting the homepage after the redirect without having the authentication cookie. Where I'd start debugging this is by using your web inspector with "Preserve log" turned on and going through the Stripe Checkout process. Then, inspect the headers sent to the browser when you land on the redirect page & make sure the authentication cookie is set.
Between requests to Stripe and SignInAsync it seems possible that there might be a missing await, so the redirect is happening before the authentication context is updated. Hard to say more without seeing your code!
We are creating a Xamarin Forms app, only Android for now, which connects to a web API also created by us (ASP.Net Core). I have managed to get OpenId Connect authentication working by:
Using Azure as the identity provider.
Using Android custom tabs to show the Microsoft's login page.
Detect when the custom tab is redirected to our redirect URL.
Get the id token and use it as the authentication bearer token sent to our web API.
Using JwtBearer authentication in the web API.
The problem appears when the id token expires. We want to get a new one without asking the user any question.
To do that, we repeat the authentication process by adding the prompt=none, id_token_hint=THE_TOKEN and login_hint=THE_USER parameters in the authentication request, as defined in the OpenId Connect specification, and supported by Azure.
During that request, we have an issue with the redirect URL:
If the redirect URL has a custom scheme (like myapp://...) Azure responds with an interaction_required error.
If the redirect URL has an HTTPS scheme, then Azure responds successfully (including the necessary parameters to continue the process), but I am not able to detect the redirect URL in the Android custom tab. So my app gets stuck in the custom tab trying to load my invalid redirect URL.
The explanation for #2 is that HTTPS URLs are handled by the browser (Chrome in this case), so it does not trigger any action that I can detect from my app. This seems reasonable.
I also tried to detect custom tab navigation events from Xamarin, trying to detect the event "manually", but failed. Such events are never triggered.
Now, as for #1, I do not have any reasonable explanation. So my question is:
Is there any way to make Azure accept a redirect URL with a custom scheme when trying to refresh an id token by using the standard prompt=none OpenId Connect parameter?
I know this question has asked before many times. I've tried every one but no luck,
I my situation,
Website url: https://mywebsite.com/qa
redirect url: https://mywebsite.com/qa/login/facebook/callback
I have added my domain to app domain, redirect url to valid oAuth redirect url. But same error.
I even created a new app.
However facebook authentication is working fine with https://mywebsite.com/ domain. It's is a different app and a website.
The issue happens only with the site in the sub folder.
Any help ?
Thank you.
EDIT
Screenshot
Can you check if "Valid OAuth Redirect URIs" in Facebook app "Facebook login" setting is properly defined like shown in screenshot attached ?
Also have you checked if your app has strict mode enabled ?
This error occurs if your OAuth setting is not correct.
I would suggest to check all settings of your app thoroughly.
The app I am maintaining has a custom Single Sign On implementation.
After receiving a valid token (which it provided earlier and stored to db),
the app executes a CustomAuthenticationFilter successfully.
The app works fine at "Jetty" on Eclipse. After a valid url request sent, the app successfully opens the welcome page which is just after login page.
Url request:
http://99.99.99.99:8090/MyApp/j_spring_security_check?tokenId=19d79b76-0d1e-4327-871b-0e8792e03be2
But when deploy it to a "tomcat", do a valid url request, instead of opening welcome page, it stucks at login page (below)
http://99.99.99.99:8090/MyApp/login.xhtml;jsessionid=3B8C865260E86F3609F75199A23A1120
The application deployed to both, ports purely the same. No exception in logs. Even I can read successful login logs in tomcat. I can't figure out why it behaves different?
I have a simple google places library implementation.
var place_service = new google.maps.places.PlacesService(map);
place_service.search(request, place_callback);
It stops working if the browser (Chrome) is left open for several days, untouched. Upon trying the next search, I get 403 error from the library search call.
Unable to authenticate the supplied URL. Please check your client and signature parameters.
Here is the captured request URL:
Closing browser and restarting fixes.
Also have a mobile HTML mobile app (iOS, Android) with same implementation. The apps places functionality also stops working after several days. App must be killed and restarted to fix.
Something seems to be expiring?
This is normal behaviour, the token parameter in the request can expire after as little as a few hours. I would recommend issuing a page refresh when the user returns if the page or app has been dormant for more than a few hours.