@francis-ducharme-0 It looks like you can do it through the AdminUI and generally if you can do it through the AdminUI, you can do it through the APIs. I should have some time later this week to test this out. If anyone else gets a chance to before then, please let us know.

@lambert-torres You can get support for FusionAuth. Please see the pricing page if you are interested. I'm not sure if this is your exact situation, but you might want to look at this blog post as well.

@witard91335 Interesting, how do you see the flow working? What kind of tags are you trying to track though FusionAuth?

Hi @mark-robustelli, thanks for your reply. I need an API that logs out a user, but apparently that’s not possible. Is there any way or approach to log someone out.

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.

@john-0 Glad you got it figured out. 👍

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.

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

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

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