They run in AWS.

FusionAuth increments each release using semantic versioning.

So after 1.5 comes 1.6, then 1.7, then 1.8, then 1.9, then 1.10, then 1.11.

So 1.5 is about 40ish versions behind 1.47.1.

Hi @saugat-nepal ,

Thanks for using FusionAuth.

Is this the process you are trying to do? https://min.io/docs/minio/linux/operations/external-iam/configure-openid-external-identity-management.html

Or is there another document you are trying to work through?

When using FusionAuth as the identity provider for a third party piece of software, it's often helpful to turn on debugging (under Application -> Your Application -> OAuth, then turn on Debug enabled). Then go through your login process. Then check the Event Log, under System -> Event Log. This should give you additional information about the handshake and OIDC process.

Please share those logs here (please remove any sensitive information from them) and we'll see if we can help.

JDK 17 turned off RSA-SHA1 XML signature support. It can be re-enabled by modifying java.security file in the JDK conf/security folder.

This is addressed in the release notes and Github issue 1814.

Hiya @jkyser ,

Hmmm. What version of FusionAuth are you running?

It looks like this is a known issue that was fixed in release 1.46.0.

@eric-vigiani Sorry about that! We pull in the code for server.py from GitHub, and it looks like it is missing.

We have a new, simpler python flask tutorial: https://fusionauth.io/docs/quickstarts/quickstart-python-flask-web

which we just reviewed and tested.

Sorry for the hassle!

@bhardwajmunish88 From the stackoverflow link:

According to this github issue this is corrected by using docker 20.10.5.

Can you try with a later version of Docker? I think this is due to the Java Docker image, and isn't an issue with FusionAuth.

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.