Magic Link failing for org using Mimecast and AD

davidmw

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.

joshua

Hi @davidmw!

I don't know much about how Mimecast works. However, as a quick take, you could follow the conversation listed in a related Github issue here.

If anything else pops to mind, I will be sure to post it here.

Thanks,
Josh

robotdan

Is this the issue described here? https://github.com/FusionAuth/fusionauth-issues/issues/629

davidmw

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&amp;client_id=3D356ad7a7-224e-4ecf-be52-414d23a00fb2&amp;metaData.device.name=3DWindows%20Chrome&amp;metaData.device.type=3DBROWSER&amp;redirect_uri=3Dhttps%3A%2F%2Fapi.proxy.become.me%2Fcommon-production%2FOAuthLoginFlowHandler%2F356ad7a7-224e-4ecf-be52-414d23a00fb2&amp;response_type=3Dcode&amp;scope=3Doffline_access&amp;timezone=3DAmerica%2FDenver"

robotdan

It looks as though Trend Micro (or whatever security solution is being used as a pass through) is modifying the URL and not properly preserving the URL encoding. You will need to inquire with Trend Micro about why this would be occurring.