@ezequiel-rebasa If you are just talking about testing, you could just add some data to the Lambda's to see if it works for your needs. This would allow you to test without having to spin up a second Docker instance. If it does work, then you may need to upgrade or figure out if you can use APIs to update the lambdas in the instances with the data you need.

@nate Can you successfully Send test email from Tenants -> Select Edit from desired Tenant -> Email in the AdminUI? This will test if your SMTP settings are correct.

@mark-robustelli
Thanks I just did that.
https://github.com/FusionAuth/fusionauth-issues/issues/3113

@pocfused said in Email verification fails in new incognito mode:

https://fusionauth.io/community/forum/topic/1406/link-in-email-verification-not-working-first-time

Glad you were able to solve your issue.

As far as the automatically verify the email part. What settings do you have for Applications -> Your Application -> Registration -> Verification strategy? There is a setting Clickable link. Is that what you are after?

Another thought would simply turning off Verify registrations in the Applications -> Your Application -> Registation tab work for you or do you still want the user to actually have to click on a link? (It would make sense to ensure the user owns the email address.)

You could also do something like provide a custom template and direct them to your application and then automatically verify them using the APIs. Check out this blog post.

Good luck.

Yes. You can use FusionAuth's OpenID Connect Identity Provider.

I did this a few weeks ago, so am writing these instructions from memory.

Prerequisites:

A yahoo account A running FusionAuth instance (localhost is fine)

Steps:

Go to the Yahoo! developer network and create an app. The redirect URI for Yahoo is https://<your instance>/oauth2/callback Save off the provided Client ID (Consumer Key) and Client Secret (Consumer Secret). Then go to FusionAuth and create an OpenID Connect Identity Provider: <your instance>/admin/identity-provider/add/OpenIDConnect Put the Client ID (Consumer Key) and Client Secret (Consumer Secret) into the Client Id and Client secret fields, respectively. Uncheck Discover Endpoints. Manually configure the endpoints: Set the Authorization Endpoint to https://api.login.yahoo.com/oauth2/request_auth Set the Token Endpoint to https://api.login.yahoo.com/oauth2/get_token Set the Userinfo Endpoint to https://api.login.yahoo.com/openid/v1/userinfo Set the Scope to openid email profile and any other scopes you might need. (I was unable to find an authoritative list, but here's info about the mail scopes.) Update the Button text and Button image as needed. Enable it for applications as needed. Save the Identity Provider.

@jakub-hajto , you may want to check out the Google Reconcile Lambda documentation. I also found this post that may be useful for you.

@mark-robustelli said in Logout with multiple subdomains:

@ext_figuvini after reading your post again, I think I read it differently. The way the SSO logout works is that on logout, FusionAuth calls all the logout urls for each applications. It would seem that you are correct in that creating an application for each subdomain makes sense and would work. (You can create applications through the API so you should be able to automate this.) Can you try this for a few domains and confirm it works?

Your point is correct. Creating a separate application for each subdomain is a reasonable and correct solution.
When a user logs out of the SSO system, FusionAuth will call the logout URLs defined in each configured application in turn. This allows each application to clean up its own session. Pretty good solution

This is due to non-ASCII characters in headers causing an issue in the FusionAuth parsing code. Cloudflare sends headers with non-ASCII characters (such as cf-region: São Paulo) which triggers this issue.

This is a java-http bug that was fixed in 2024, and released in FusionAuth version 1.51.2.

So, two options:

upgrade to a version of FusionAuth 1.51.2 or newer. This is the recommended approach, but may require some work. as an interim workaround, you can disable the "Add visitor location headers" option from your CloudFlare console. This should not have any negative impact, since we do not inspect those headers.

@Alex-Patterson tunnel rush said in Adding supplementary user data:

@evanm Yes you can use the sub inside of the JWT when making any API call to your backend. In your database this will be a unique Id for the user. You can even get more details about the user from FusionAuth by calling the User endpoints.

https://fusionauth.io/docs/apis/users#response-1

Thanks for sharing!!

@mark-robustelli Yes, it's all working. After the logout flow executes, the sessions that were being left behind on FusionAuth are now being revoked properly. Thanks.

@robert-regnier Unfortunately, it looks FusionAuth does not support this. I did find an
open issue that you may want to upvote if it is in fact the same issue you are experiencing.

You may also want to check out this blog. It talks about a custom domain using one of FusionAuth's hosting packages, but think it should work in your case as well.

Does anyone else have a similar setup? How did you implement it?

@owork138 Thank you so much for the detailed and thoughtful explanation. Your insights have helped clarify the likely cause of the confusion with the authentication setup in our FusionAuth application. Understanding that the lack of distinction in the session data may stem from FusionAuth’s default handling—and that customization in our Express.js logic might be required—gives us a clear direction to move forward.

We truly appreciate the time and effort you put into outlining potential solutions. We'll be reviewing our current middleware and exploring the recommended approach to better capture identity provider information during authentication.

Thanks again for your support!

@jay-saxophone383 I do believe you can get FusionAuth to work as you described here. Here are some links that may give you a little more detail.

SAML v2 with ADFS

OpenID Connect with Azure AD

Enabling Single Sign-On in an Organization

Product Update

As mentioned above, some of the features described are only available with paid planes and if you need to test them out, you will want to contact FusionAuth and see what can be worked out.

Existing Role Limitations in FusionAuth FusionAuth provides predefined Admin UI roles, which are not modifiable. You can review the available roles here:
FusionAuth Admin UI Roles The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available. Requesting Read-Only Roles as a Feature FusionAuth does not currently support read-only access roles for applications or tenants. The likely reason for this is that users who need to view application/tenant properties often also need to update them. However, you can submit a feature request to suggest adding read-only roles:
Submit a Feature Request Workaround: Implement a Custom Read-Only View

If immediate read-only access is required, consider:

Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data. Relevant APIs for this purpose: Application API Tenant API

Summary

No built-in read-only roles exist for applications or tenants. FusionAuth Admin UI roles are not modifiable. You can request read-only roles as a feature via GitHub. A workaround is to build a custom, API-based read-only view.

@robin-singh said in Getting 403 : disallowed_useragent with Google Auth:

We have android/iOS app where authentication redirects to fusionauth login page.
And here we have Facebook/Google login setup.
Facebook and native login is working fine but with Google login getting Error 403: disallowed_useragent.

Is there any way to directly open sign in for google which will send data to fusion auth only.

Are you trying to open the login in your application? Maybe try to use the system browser to up the Google login and see if that works. Google disallows OAuth login flows inside embedded web views (like those used in many mobile apps).

This is not available today without some glue code.

Currently our suggestion is to use Javascript on the Login page to jam the claim into a meta field that is shown on a Webhook payload, like jamming stuff into event.info.deviceDescription .

Then you create user.login.success webhook, making sure it is transactional. On login, the event is fired that off to your system and then you extract the claim off the event.info.deviceDescription field and make a PATCH call to FusionAuth. In that PATCH call, you add this to a field on user.data.x.

Then once that PATCH is successful, the 200 response back to the user.login.success event which completes the login and triggers the JWT populate lambda. That lambda extracts the claim off the user.data.x field and puts it into the JWT.

It's not pretty but it is the only way to have this work for now. (For self-service registration you can use a custom hidden field, much easier.)

Relevant docs:

https://fusionauth.io/docs/extend/code/lambdas/jwt-populate https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success https://fusionauth.io/docs/apis/users#update-a-user

@d-chinguun-0301 No problem. Glad you figured it out. No need for apologies, if you were confused others may be as well. Now when they search here, they will have an answer. Have a great one

This is possible in a couple of ways.

First, to allow users to register for an application on login, you need to turn on self-service registration. From the docs:

When you enable self-service registration for an application and a user who does not have a registration for that application successfully logs in to that application, the user will automatically be registered for that application, and have a registration added.

Then the question becomes, how can you disable the hosted login pages self-service registration form?

To do so, take the following steps:

update your theme to remove the link to the "Don't have an account? Create one" link from any pages, including the login page. You can also remove all the content from the registration themed page and replace it with not implemented or similar. However, a sinister user may still be able to post to the register endpoint and create a user if you are self-hosting, block access to the /register endpoint using a proxy if you are not self-hosting, prevent self-service registration by adding an encrypted secret value to all user accounts you create via the API. Then, create self-service registration validation lambda which will examine the user object. If the user object comes through without the secret value, fail the registration. Otherwise allow it through because it is a user who has logged in.

The self-service lambda may not fire unless there are required fields on the registration form, but that behavior is undocumented and may change.

@hamza-chouaibi Been having this same exact issue for the last one week. When I stumbled onto this and applied the suggestions here is when it now seems to work. I use the .dev TLD instead.

By using a proxy or gateway that supports mutual TLS, you can use it with FusionAuth.

For example, AWS ALB supports Mutual TLS verify where the ALB does client certificate verification. Nginx has similar functionality.

If you are running FusionAuth 'bare' and terminating TLS directly at the FusionAuth server, mutual TLS is not supported.