You can create two values for the FusionAuth url:

internalFusionAuthURL="http://fusionauth:9011"
externalFusionAuthURL="http://localhost:9011"

So basically whenever you are sending the redirect to the browser (pretty much just the authorize and logout URLs) you use externalFusionAuthURL which references localhost.

When you are communicating with FusionAuth from the application backend (the express app) you use the internalFusionAuthURL which references the docker domain name.

I tested that out and it seems to work fine.

Give that a try.

Hiya,

I want to run FusionAuth and the backend app in Docker, but run into an issue with this quickstart: https://github.com/FusionAuth/fusionauth-quickstart-javascript-express-web/

When I modify the complete-application/.env file to have the value for fusionAuthURL=http://localhost:9011 the token exchange fails (because the dockerized express app doesn't know how to get to FusionAuth).

When I set fusionAuthURL=http://fusionauth:9011 where fusionauth is the internal docker network domain name of the FusionAuth server, the initial redirect fails, because my browser doesn't know about that domain (not being in Docker).

How can I fix this?

@john-0 Glad you got it figured out.

@sergey_smirnov hmmm..Ok can we verify this is 100% not user action? Can you add some logging to your application so we can see what a user is clicking or starting a new session? Then we can compare with the logs in FusionAuth.

@john-0 If you log into account.fusionauth.io and click on Hosting, you should see your instance listed. From there select Custom URL(s) from the Action drop down. If you do not see those options, you may need other permissions.

@john-0 have you been through the documentation for custom domains? Is there something that is not working for you?

@njanaskie You are correct in that magic links are designed to be a one time use. I do not know of any work around for your situation.

It will be interesting to see if others chime in.

@francesgee836 I came across this open issue that may be of use.

If you are using the Elasticsearch search engine:
You can search for users with active:false to find users who are not active, which typically includes locked users.

If you are using the database search engine:
You cannot directly filter for locked users in the search API. The workaround is to retrieve all users (using a wildcard search) and then filter for active:false in your application code after retrieving the results.

Currently, FusionAuth does not provide a built-in filter specifically for "locked" users distinct from "inactive" users in the API or UI. The active:false filter is the closest available option, and it may include both locked and other inactive users.

@sergey_smirnov I was referring to the application level. Try to disable it there and see if you are still getting the double login.

Worth re-emphasizing that this voids any warranty you might have from FusionAuth, per the license, exhibit A section 5.1.

You can't get support from FusionAuth if you modify the software.