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?

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.

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.

I'd like to off a "Login with Yahoo!" button. Can I use FusionAuth to do so?

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.

We were using a FusionAuth cloud deployment directly but now want to use Cloudflare in front of it.

We are now seeing intermittent, infrequent 502 errors.

We see errors like this in the logs

2025-06-24 14:05:09.345 PM ERROR io.fusionauth.http.server.HTTPServerThread - An exception was thrown during processing
java.lang.IllegalArgumentException: Not a valid Unicode code point: 0xFFFFFFC3 

How can we resolve this?

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

How can I add in custom claims in to the JWT based on a custom login field or other parameters on the login form?

I have a parameter/variable that can change between each login (like a device id) and want it to be in the access token.

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.