Hiya @benjamineroommen ,

I'm not sure what you mean? Are you talking about the JWT generated for a login event?

The issue with the redirect URI specified in your code. FusionAuth is indicating that the redirect URI you provided is invalid.
The redirect URI must match the one registered for your FusionAuth application.

Hiya @diego-carreras !

Hmmm. Did you ever solve this? I have not run across this before.

Did you try other email clients? Did you search the MS Outlook forums? Did you turn on the email debugging?

Hi there!

I don't have any experience with Apache Traffic Server to be honest but are you running your FusionAuth instance with HTTPS? If so, does Apache Traffic Server trust the FusionAuth certificate?

I did manage to make it work locally by configuring the reverse proxy like shown on their docs and adding this mapping to the remap.config file:

map http://fusionauth.local:8080/ http://fusionauth-fusionauth-1:9011/

This will make it proxy requests to http://fusionauth-fusionauth-1:9011/ when it receives a request with Host: fusionauth.local:8080. Then, I added fusionauth.local to my /etc/hosts to point to Traffic Server.

This was enough to reach the FusionAuth instance, but I still needed to configure some HTTP headers to make it function correctly. Using Traffic Server's header rewrite plugin, I changed the config above to:

map http://fusionauth.local:8080/ http://fusionauth-fusionauth-1:9011/ @plugin=header_rewrite.so @pparam=fusionauth.conf

And created a fusionauth.conf file with the needed headers:

set-header X-Forwarded-Host %{CLIENT-URL:HOST} set-header X-Forwarded-Port %{CLIENT-URL:PORT}

Please let me know if that works.

@dan The configuration files and logs are inaccessible, assuming you're talking about the ones residing up a directory from /fusionauth-app/.

Thank you for stating the risks of the leakage. The only thing that raised flags here was the default fusionauth.properties file in the template directory had the default database user and password, but those should be, and were, changed when installing.

I will fork and submit a PR later tonight or this week.

Thanks again.

@dot-realities

Hmmm. It seems like you want to have email verification take place entirely outside of FusionAuth. Is that the case?

If so, you should:

suppress sending any emails to FusionAuth, which will typically will verify emails (you can turn that off by setting tenant.emailConfiguration.implicitEmailVerificationAllowed to false) send emails yourself, using whatever system you want verify the user's email directly, using an API key (search for Administratively).

Does that meet your needs? If not, please provide more information.

@joaogoncalves Hiya, I don't think that is supported. I'd suggest using two different Application configurations in FusionAuth, though I'm sure that's something you've already considered.

Feel free to file a feature request: https://github.com/FusionAuth/fusionauth-issues/issues/

@troy-squillaci I think you need to set the value of database.root.user.

If that is not set, FusionAuth can't create any tables, which it will try to do if the tables are not set up.

Have you manually bootstrapped your database (that is, run the sql as documented here to create the needed tables)?

@vinicius-campitelli thank you!

@tiny-lamp6590 said in React SDK Example Issue:

I think I am a bit burned out on getting this to run locally, will probably eject the whole thing and retry with a clean start with only changes to the cookie security when I have the bandwidth. Thanks again for your suggestions.

Maybe that would be the best approach to be honest... I just cloned the repository, started the FusionAuth instance with docker compose up in that folder, installed dependencies from client and server and everything works, even with the secure: true (which I think browsers just ignore when running locally).

I tried both Firefox Developer Edition 114 and Chrome 113 and they run fine. Which browser are you running on? Have you tried disabling extensions or going incognito?

image.png

@tiny-lamp6590 Hey folks

As of FusionAuth 1.45, we have something that mimics the express server functionality built into FusionAuth. We call it the 'hosted backend'.

You can see it used here: https://github.com/FusionAuth/fusionauth-example-react-guide

It's documented here: https://fusionauth.io/docs/v1/tech/apis/hosted-backend

But using an express app will give you more flexibility (to choose a different cookie name, or do additional processing during the token exchange).

We are working on a tailwind integration doc so that you can use the same tailwind css between your react app and FusionAuth login pages. Here's the PR for that: https://github.com/FusionAuth/fusionauth-site/pull/2117 (still under review).

Thanks for using FusionAuth!

Note for future folks -

Resolved under this issue https://github.com/FusionAuth/fusionauth-issues/issues/1742

And in version 1.44

https://fusionauth.io/docs/v1/tech/release-notes#version-1-44-0

Apologies for reviving a months-old thread, but I'm new on this forum and I'm hunting for similar info. I came across your post about SSO using the /api/login endpoint in FusionAuth.
From what I've learned recently, the login API doesn't currently support SSO. The hosted login pages, on the other hand, provide a bunch of functionalities, including SSO. So, for now, it seems like using the standard hosted login page is the way to go.

@dvanmil Thanks for the clarification. Currently FusionAuth returns the totalCount as part of the user search results. You could use that, with multiple requests, to build the facet numbers.

@dvanmil I think I answered your question here: https://fusionauth.io/community/forum/topic/2382/elastic-search-facet-search/1

I'm sorry for the moderation that might have caused you to post twice. We have a spam problem so every new poster needs their first post reviewed. Future posts from your account shouldn't be delayed.

If a user is still receiving a SearchEngineRequestFailedException after a system reindex and patching, there could be several reasons for this.

Firstly, the issue may not have been related to the index or patching, but rather a problem with the user's search query or the way they are interacting with the system.

Alternatively, it could be that the reindex and patching process did not fully resolve the underlying issue, and further investigation or troubleshooting is necessary.

It's also possible that there are other technical or environmental factors at play that are causing the exception to continue occurring. In any case, it may be necessary to consult with technical support or seek out additional resources to diagnose and resolve the issue.

Based on the information you have provided, it seems like the issue with your FusionAuth deployment is related to license registration. It's possible that the non-production license you were using is not appropriate for your current usage, and that may be the reason for the message you received.

Regarding your question, deactivating your non-prod license and activating your prod license should not affect your current configurations, users, and permissions. As per the documentation you shared, deactivating a license does not remove any configuration previously saved while the license was active. Therefore, if you activate a new license, all of your previous configurations and settings should still be in place and accessible.

It's always a good idea to take a backup of your current configuration before making any changes, just in case. Additionally, I recommend double-checking with the FusionAuth support team or your Client Service Operations Specialist to confirm that switching to the prod license is the right course of action for your situation.

@boris

FusionAuth doesn't have a native MetaMask integration.

Does MetaMask support OIDC? A brief google doesn't show any options.

FusionAuth may not be the best fit.

But if you would like, feel free to file a feature request: https://github.com/fusionauth/fusionauth-issues/issues with more details.

@georgeandersons241

Hmmm. Can you show the error output? And share what installation method you are using?

Thanks!

@rcdunn

Welcome to the FusionAuth community!

Your base URL depends on where you install FusionAuth.

If you are using FusionAuth cloud, you can pick a base URL (rcdunn.fusionauth.io, for example).

Hope that helps.