@sergey_smirnov Hmm, the 10 sec between the logs does lead me to similar speculation that it is being caused by the user. I would think they would be closer together if it was something the application was doing on its own (although I am not entirely ready to rule that out either).

That being said, it seems like just guessing unless you can get the application logs and trace the users page views for sure. Is that possible?

There is a setting in the Tenants for the Session timeout.
Tenants -> Edit -> OAuth tab -> Session timeout

Screenshot 2025-06-26 at 8.46.22 AM.png

Let me know if you are able to log the users page views.

@eakpan Awesome, thanks for posting. This may end up helping others. Glad you are able to configure FusionAuth to work for you.

@laurahernandez I hope you are able to achieve the look and feel you are going for. I understand you would like to be able to show and hide the password dialog in simple themes and you are not the only one. Please be sure to upvote the issue here.

I understand using advanced themes may require more work, but ultimately it is more flexible that simple themes. Good Luck.

@mark-robustelli said in Logout with multiple subdomains fnaf:

@ext_figuvini this is an interesting use case. I would think the way you have it configured would work. I would have to recreate you situation to test. Unfortunately it may be a while before I can get that done. I should be able to take a look next week. If anyone has experience with this, please feel free to chime in.

Make sure to set the Redirect URIs in the application settings to include all relevant subdomains (e.g., https://backerstats.localhost/, https://pokerstats.localhost/).

@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.

@atakan thanks for sharing the information.

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.

@davidhaven1246 Have you checked out the documentation on using the basic registration form? Will enabling the Self-service registration for the application what you are after? If not, a little more detail on your flow and how you have implemented may help.

This post may help provide some clarity as well for an invitation flow. Keep in mind, this flow utilizes some paid features of FusionAuth, but you may be able to figure out some work arounds with the community edition.

This post talks about passing some parameters in a link that may help as well.

@jobclone20 I just took a look at the page for the FusionAuth Visual Studio Templates. It appears they are only for Visual Studio 2022.

@haziqt have you taken a look at the documentation on How To Us a Proxy? There are a few headers you will need to add.

@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?

@jobcuatoi14, Since I work for FusionAuth, I obviously have a pretty strong opinion on this one. Beyond that, I still have a strong opinion as a developer in general. I will share with you my thoughts so you can take them under consideration.

I'm not going to tell you what you should and shouldn't do. Everyone's authentication strategy is their own decision. Personally, in general, I would recommend against building your own. Instead of listing reasons, I will pose questions for you to consider so you can come to your own conclusion.

Are you a security expert? If not, you will need to implement all the standards. Yes, you can use common libraries, but you will have to always stay up on the latest and greatest. Everyday you will need to check for vulnerabilities in every library you use. If something breaks, you will have to stop what you are doing on your core product and fix it. You also mentioned JWTs and there are many other well known standards out there such as OAuth. Knowing the recipe and executing it are two different things. You may read how to prepare Fugu, but do you really want to do that yourself or leave it to an expert?

Is authentication your product? If not, you will have to consider all the time you will be dedicating to authentication as a developer. How much better would your core product be if you spent that time focusing on it?

How much time do you have to dedicate to building your own auth? Even with standard libraries, you will have to build a lot. Probably more than you initially thought. I know you talked about using bcrypt for hashing, but are you aware of the concept of using salt with the passwords? If not, I would really recommend not doing it. If you are, that is just one more thing you will have to deal with. You mentioned the forgot password flow, but you will likely need other things like initial registration flow. What about updating user data in general?

What features do you need? Of course that comes down to what you are trying to protect. If you are just maintaining your small blog subscription, username and password may work. If it is more sensitive, you may need things like MFA. Will you need to allow social logins? Will you need to enforce password policies? Will you need to support passwordless login? Role Based Authentication?

Do you have time to maintain what you build on top of your core product? Once you have it built does not mean you can forget about it. Security is an evergreen process. The consequences of a lapse and impact on your product/company can only be measured by you.

I could go on and on, but I think for a forum post this gives a pretty good support of my recommendation.

Whatever issue you have with the other tools you mentioned or even FusionAuth itself, I would challenge you strongly to consider if the issue is easier to deal with than creating the whole system yourself. In my experience, it is usually easier to work around the issue than build your own.

I can't necessarily speak for the other products you have listed, but if you list some of your concerns with FusionAuth, I may be of some assistance.

Are you aware FusionAuth has a free Community Edition?

Also, I would recommend going through a FusionAuth Quickstart in the programming language of your choice to see how easy it is to get started.

Deciding which authentication to use is not a simple choice, I hoped this helped and didn't sound too "salesy".

I'd love to hear other's thoughts on this as well.

@valerii15298 said in can't use fusion auth react sdk when fusion auth server runs locally on fusionauth.localhost::

I followed react sdk example https://github.com/FusionAuth/fusionauth-quickstart-javascript-react-web/tree/main

I changed in kickstart tenant issuer to

"issuer": "http://fusionauth.localhost:9011"

and variables to

"allowedOrigin": "http://fusionauth.localhost:4000", "authorizedRedirectURL": "http://fusionauth.localhost:4000", "authorizedPostLogoutURL": "http://fusionauth.localhost:4000/logged-out", "authorizedOriginURL": "http://fusionauth.localhost:4000", "logoutURL": "http://fusionauth.localhost:4000",

and started fusion auth in docker compose, also specified env var:

FUSIONAUTH_APP_URL=http://fusionauth.localhost:9011

For react sdk use this config:

const config: FusionAuthProviderConfig = { clientId: "e9fdb985-9173-4e01-9d73-ac2d60d1dc8e", // even started my app under the same local domain redirectUri: "http://fusionauth.localhost:4000", postLogoutRedirectUri: "http://localhost:4000/logged-out", // serverUrl: "http://localhost:9011", // this one works serverUrl: "http://fusionauth.localhost:9011", shouldAutoFetchUserInfo: true, shouldAutoRefresh: true, onRedirect: (state?: string) => { console.log(`Redirect happened with state value: ${state}`); }, scope: "openid email profile offline_access", };

And when I log in and am redirected back to my app, fusion auth hook does not show me that I am logged in(it does not even send any requests I checked network). But when I strip everywhere fusionauth. prefix then everything works fine. Why does not fusion auth work locally with custom domains?

Cookies on my local app fusionauth.localhost:4000 are also saved after I logged in: https://freeimage.host/i/3FVbSJsWacky Flip

And when I click login button again (or invoke startLogin function from useFusionAuth hook) I am redirected right away to the app since I am logged in. But isLoggedIn is false and useFusionAuth hook does not recognize that user is logged in.

(I have mapped fusionauth.localhost to localhost in my hosts file locally)

#docker #react-sdk

Set SameSite=None; Secure explicitly on the FusionAuth Cookie: this tells the browser to send the cookie with all requests, even cross-site requests. SameSite=None requires the Secure attribute, meaning the cookie will only be sent over HTTPS. Since you are using http://, this won't work directly without HTTPS set up locally.

@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!!

@dan geometry dash lite said in LDAP:

@david-billings

Does FA remove users once they've been removed from LDAP?

If you use the LDAP as the source of truth, the users won't be able to login, but they won't be removed.

So, consider this scenario (no migration, just always going back to LDAP):

User A logs in successfully through a tenant configured with an LDAP Connector. User A has an account in the LDAP server. FusionAuth checks with the LDAP connector, passing the credentials. The LDAP server says "yup, User A is okay." FusionAuth creates a user. Time passes. User A is removed from the LDAP server. User A tries to login. FusionAuth checks with the LDAP connector, passing the credentials. The LDAP server says "User A is not found" FusionAuth denies the login.

But the user still exists.

Is there anyway to sync this and sync the users without each user having to login?

You want to sync the users between LDAP and FusionAuth without the user having to login? Is this a one way sync?

You could do a bulk migration using the Import User API if you have access to the LDAP database and can provide the password hashes.

That is the only option that comes to mind.

Thanks for your help, it was very helpful.

@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.