You can customize the forgot password page by modifying the theme. More details here: https://fusionauth.io/docs/v1/tech/themes/

The template you are looking to modify is the Forgot password template.

There is currently no Forgot username functionality. Please feel free to file a feature request for this functionality.

Is there a way to get the actual error via the FusionAuth admin dashboard?

You can check the event logs and the system output if you have access to the logs, but I don't believe there's a lot of debugging info available for that particular path.

This troubleshooting doc may be worth reading: https://fusionauth.io/docs/v1/tech/troubleshooting/

Also, if you are interested in building a more secure JWT, this article may be of interest: https://fusionauth.io/learn/expert-advice/tokens/building-a-secure-jwt/

So, this appears to be a limitation of Facebook. Here are the API docs from Facebook which have no mention of how long the image URL returned if you pass redirect=0 is good for.

Looks like some Auth0 users also encountered this.

So I think you are on the right path with downloading the user's Facebook images and updating them on your side every time a user logs in.

This is unfortunately a known issue. See https://github.com/FusionAuth/fusionauth-issues/issues/629 for some discussion. There are some workarounds in some situations (allow lists in Office 365) but no general workaround.

@chakshu

Sorry, I pointed you to the incorrect setting.

You can go to Applications > FusionAuth > Edit > JWT > Refresh Token duration

Changing that to 1 (the value is in minutes) caused me to be signed out of the admin application after 60 seconds.

Hope that helps.

I wrote a guide for running fusionauth in a clustered/multi node setup: https://fusionauth.io/docs/v1/tech/installation-guide/cluster/

The bug about the ip addresses being the same (which was only a display bug, not a functionality bug) was also addressed in 1.23.0: https://fusionauth.io/docs/v1/tech/release-notes/#version-1-23-0

Awesome! I know this is on our minds, but don't have an exact timeline for when it'll be implemented.

Thank you. Merged the PR. That was a boneheaded mistake on my part, sorry about that!

We don’t currently support IdP initiated login.

This has come up a few times, we’ll likely end up adding it, but for now it is not possible. We have an open feature for this in GitHub.

Please feel free to upvote it or otherwise communicate your desire for this work to be done.

Hiya,

Which search engine are you using (database or elasticsearch)?

Do you see any log messages in either FusionAuth's logs or the database/elasticsearch's?

Dan

PS if you are running in production with 2.5M users and want specific performance help with a guaranteed response time and access to the engineering team, we recommend purchasing a paid edition which includes support. More info here (scroll down to see support options).

Looking at how the filter works, it looks like we either find * which allows all origins, or - we look for exact matches in the configuration based upon the Origin HTTP header.

So you can't allow all subdomains in FusionAuth at this time.

We have an open issue for this: https://github.com/FusionAuth/fusionauth-issues/issues/603 Please do vote it up.

We also are investigating OpenAPI which would let you build a C++ library. More here: https://github.com/FusionAuth/fusionauth-issues/issues/614

Finally, I will point out that you can use the REST API and a JSON library and FusionAuth will work just swimmingly. I'm not C++ savvy, but https://github.com/nlohmann/json and https://github.com/jgaa/restc-cpp look like they could be combined to do the trick.

@chirag have you seen these? https://fusionauth.io/learn/expert-advice/authentication/login-authentication-workflows/

Reviewing them and mapping your use case on to them may be helpful.

Yes. See the login_hint parameter here: https://fusionauth.io/docs/v1/tech/oauth/endpoints/#authorize

The JwtDecoders.fromIssuerLocation will attempt to resolve the jwks_uri from the OpenID Connect discovery document found using the issuer URI.

https://github.com/spring-projects/spring-security/blob/848bd448374156020210c329b886fca010a5f710/oauth2/oauth2-jose/src/main/java/org/springframework/security/oauth2/jwt/JwtDecoders.java#L119

The FusionAuth JSON Web Key Set (JWKS) only publishes the public key from asymmetric key pairs. This means there are no public keys published and the Spring boot library cannot verify the token signature.

For example, if your issuerUri is https://example.com then the OpenID Discovery URL is https://example.com/.well-known/openid-configuration and the value for jwks_uri found in the JSON response from that URL will be https://example.com/.well-known/jwks.json. If you hit that URL you will see no public keys are being returned, this is the JSON that the library is consuming in an attempt to build the public key necessary to validate the JWT signature.

To use this strategy then you'll need to configure FusionAuth to sign the JWT using an RSA or ECDSA key pair instead of the default HMAC key which is symmetric.

Generate a new RSA or ECDA key pair in Key Master (Settings > Key Master) and then ensure you have your JWT signing configuration use that key. The primary JWT signing configuration will be found in the tenant, with optional application level overrides.

https://fusionauth.io/docs/v1/tech/core-concepts/tenants/#jwt
https://fusionauth.io/docs/v1/tech/core-concepts/applications/#jwt

You could take a look at the system log. If the OOM killer ended a process due to memory constraints it will be logged there.

You might see lines like:

Dec 30 12:00:38 vps kernel: Out of memory: Kill process 30047 (java) score 98 or sacrifice child

The OOM killer will begin killing services once the kernel runs out of memory. The solution will be to allocate less memory to FusionAuth or to increase the amount of RAM available to the host OS. You can do the former with the fusionauth-app.memory setting. See the configuration reference for more details.

Note that as of 1.19.0, session pinning/sticky sessions are no longer required. More details here.

Yes, just confirmed the fact that this is a Safari only issue. Only Safari seems to be doing this, we don’t return a 403 so this must a CORS failure. Perhaps Apple is sending additional headers on the request when using Safari that need to be accounted for in the Allowed headers.

I added GET to the allowed methods for CORS and it works that seems to allow it to work in Safari. Please test and let me know.

The redirect workflow looks to be different in Safari when using native controls vs Chrome or other browsers.