Posts made by dan

@gean-ivamoto Hmm. Seems like a good feature request. Can you please file one here: https://github.com/FusionAuth/fusionauth-issues/issues/

@brad Interesting. The error message Connection is not available, request timed out after 155614ms makes me suspicious, but I hear you.

I'm not familiar with the performance characteristics of Aurora, to be honest. We definitely have some folks running FusionAuth with that as their database, but it isn't typical and is not listed as a supported database.

You could try tweaking some of the database connection pool settings mentioned here: https://fusionauth.io/docs/reference/configuration

I'd also suggest googling around to see whether anyone else has issues with Hikari (our connection pool software) and the version/engine of Aurora that you are using.

Finally, if you have a plan that includes engineering support, I'd encourage you to open a support ticket.

Hi @brad ,

From here, it looks like the database was unavailable or FusionAuth ran out of connections.

@brad said in FusionAuth server completely locked up:

Caused by: java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 155614ms.

This can be caused by lambdas or connectors that are too slow to respond or are blocked from responding. It also can happen if FusionAuth is under extreme load and the database is undersized.

@kasir-barati Makes sense. Thanks for the feedback!

@kasir-barati Can you be more specific about your question?

@whuysentruit

Sure, we welcome feature requests from the community! Members can upvote them and we review the upvotes when considering future development.

Here's the GitHub repo to file the issue in: https://github.com/FusionAuth/fusionauth-issues/issues/

Please feel free to reference this forum post and give as many details as you can. This helps us understand the use case.

More about our roadmap process: https://fusionauth.io/docs/operate/roadmap/roadmap

Hiya @kasir-barati , welcome to the FusionAuth community!

Is there any kind of docker env or java env to pass to the container while creating it to create the api key automatically while creating container.

Unfortunately no. You can create a kickstart.json which has a single key. That's the recommended way to bootstrap FusionAuth if you want to manage everything through Terraform afterwards. Because you are correct, you'll need an API key.

We have a terraform guide we're about to publish, but you can view it here: https://github.com/FusionAuth/fusionauth-site/pull/2323/files . That is not fully reviewed, but should still be helpful to read.

Can you explain why you don't want to use Kickstart at all?

@jswgger007 Hmmm. That's weird.

What happens if you put console.log(process.env.FUSIONAUTH_ISSUER); right a t the top of the file?

Seems like the environment variable isn't being picked up for some reason.

What type of system are you using (windows, mac, linux, etc)?

@lambio hmmm. That code value changing seems to indicate that the authorization code grant isn't completing. This might cause the behavior you are seeing (because the tokens never get stored in the browser).

Are you running both systems on localhost? Are you using docker?

Sharing a bit more about what the system looks like would be helpful.

Another thing you can do is enable debugging in your fusionauth application configuration (go to the admin panel, edit your application, enable debugging) and then viewing the event log (go to system -> event log) as you try a login. That might be helpful info to share as well.

Thanks @daniel-lohse.

This additional info would be helpful:

• Type and version of your database
• Any negative issues you see, unless this is only a worrisome event log entry
• Any behavior you see that triggers these (if you have replication steps)

And I can file an issue.

@mark Awesome!

@j-smutek Hmm. 512 MB should be fine for typical usage.

Do you have a large number of applications or tenants or webhooks or keys or anything else? Or is this a pretty standard config?

I'm glad you were able to get the API key created. That is a weird error I've never seen before.

@jarrod

Do we whitelist a large amount of callback URLs?

This would work. We have tested with a couple of thousand different URLs.

Do we create an Application per custom domain? (Does this mean we have to sync users?)

This would work too. You won't have to sync users, but you would have to add registration for each application a user is supposed to have access to. Then you provide a different client id for each subdomain (using a mapping maintained in your database).

Do we redirect to the main app and perform some kind of sidechannel/backchannel SSO iframe magic?

I'd avoid this if at all possible.

This might be helpful reading for you: https://fusionauth.io/docs/get-started/core-concepts/users#segmenting-users if you haven't seen it yet.

but we can migrate to the concepts in FusionAuth if that's required.

Not required, but may be helpful. The question I always ask when discussing this is "would a user who is going to subdomain.theirdomain.com be unpleasantly surprised if they had the same credentials there as they do at the account at subdomain2.anotherdomain.com"? If so, tenants are a good fit. If not, keep things simpler and use one tenant.

@joseantonio you'd have to re-authenticate with the hosted login pages. Custom login pages don't set the FusionAuth single sign-on cookie.

There is an open github issues about this: https://github.com/FusionAuth/fusionauth-issues/issues/1515

Hmmm. I think this might be related to some internal webhooks FusionAuth uses to sync data between nodes. See for example https://github.com/FusionAuth/fusionauth-issues/issues/2257

Are you running multiple nodes or one node? Any other details you can share about your platform?

@whuysentruit

Hmmm.

One option to explore would be using a custom lambda for each IdP, and setting an custom value (iss_unexpected) on the user/registration if the issuer is not what you expect. Then you could pull the value from the user/registration and set it in the JWT issued by FusionAuth, and have your application check it.

I don't see any way to accomplish this using the standard options.

@j-smutek Hmmm. Can you try it without using your SSL certificates and see if the same issue occurs?

@mjthakur413 Great, let us know how it goes.

@david-gonzalez Yes, you can do all of that. Providing centralized authentication is what FusionAuth offers.

If you want an SLA, you'll need an enterprise plan. You can learn more on our licensing FAQ page about SLAs.

If you'd like to discuss your needs with a technical sales person, you can also contact us.