Hi Dan,

Running single node of 1.18.5 on Kubernetes with postgresql on the same VM. We don't see the problem very often so let me get some load testing configured.

David

Thanks Dan - the manual endpoint configuration did the trick. I put the parameter on the authorization URL.

David

@dan - very useful. Thanks for the replies.

Afraid not. This isn't an issue of selecting the right IdP for the user or an issue of wanting to skip FusionAuth login screen .

Once control is passed to Google - I need to ensure that Google prompts the user for Google Account selection. I can't have Google assuming that the user wants to authenticate using the active Google Account - it needs to ask.

@dan Any support for wildcards? We've got a query parameter (subscription key) needed by our backend and it would be great to not touch all the redirects for this

I just had another customer experience problems from behind a Trend Micro security solution. He was able to add our domain to an approved origin list, which seems to allow redirection to the full passwordless URL. However login is still failing and I'll note that & has been replaced by amp; in the URL in his arrived magic link email:

href=3D"https://ident.become.me/oauth2/passwordless/4a7dLluFli__SQbno3MEXeRn6vnCKP3k2QI-kt1ySxI?tenantId=3D8d22a1b9-e709-443c-8147-f8796ddec84e&client_id=3D356ad7a7-224e-4ecf-be52-414d23a00fb2&metaData.device.name=3DWindows%20Chrome&metaData.device.type=3DBROWSER&redirect_uri=3Dhttps%3A%2F%2Fapi.proxy.become.me%2Fcommon-production%2FOAuthLoginFlowHandler%2F356ad7a7-224e-4ecf-be52-414d23a00fb2&response_type=3Dcode&scope=3Doffline_access&timezone=3DAmerica%2FDenver" 

Users requesting magic link login or password reset are viewing the inbound email just fine but when they click on the link in email they are seeing a FusionAuth error screen complaining about missing_redirect_uri.

Immediately when clicking on the button in the FA email the browser is flashing a Mimecast URL, then redirecting to https://ident.<mydomain>/oauth2/passwordless/4YbVFuAsLZ2EKaL31dL3ACBYAmzG5q_Ark70S743a_g?tenantId=8d22a1b9-e709-443c-8147-f8796ddec84e which looks both damaged and truncated (missing redirect_uri and more).

I'm hoping we can get past this via whitelisting but I'm wondering if there are other solutions so we can play nice with Mimecast or make configuration recommendations to the client.

In case it isn't clear, these emails work fine for most of our users. We are working with a new client that has Mimecast configured on their network.

Thanks Dan - the manual endpoint configuration did the trick. I put the parameter on the authorization URL.

David

Afraid not. This isn't an issue of selecting the right IdP for the user or an issue of wanting to skip FusionAuth login screen .

Once control is passed to Google - I need to ensure that Google prompts the user for Google Account selection. I can't have Google assuming that the user wants to authenticate using the active Google Account - it needs to ask.

We have users with multiple google accounts (private and school accounts, for example).

Some users will mistakenly connect on a private account, which isn't registered with us. FusionAuth automatically creates the account, but user doesn't get registered for our apps that way. So we bounce them out, returning them to our splash page.

Then they try to login again and this time they fall into our app, by-passing the Google account selection screen. The wrong Google account is still active and they get bounced. No easy way to get out of this mess, short of going to a Google site in the browser and logging out.

I'm thinking that perhaps we need to always show the Google account selection screen. For the record we aren't using the canned Google IdP but we've created two (managed and unmanaged) using OpenID. Google docs suggest that prompt=select_account can be passed on the OAuth2 authorization URL. Is there a way to specify options that should be used for each IdP? https://developers.google.com/identity/protocols/oauth2/openid-connect#prompt

Okay so if we refocus on the apparent instability of the nodes - how can we check on node startup times to see if the data reported in the About UI is accurate?

@dan do you have any ideas on next step to help figure out what is happening here?

Ugh, somehow I wasn't watching my own thread.

Yes this is deployed on Kubernetes.

On the About screen we have indications that all our nodes are sharing the same IP address. The nodes seem to be restarting at odd times too, unrelated to system load. The start times shown here are Saturday evening and we had zero login activity until my 9:30pm login to generate the screen capture.

Is any of this expected?