@david-cuen This is really weird. I was not able to replicate it. There is one more thing I may try later if I get some time. That is to make one template that big and try that.

In the mean time, I went back to look at the error message. "Premature EOF" and the fact that it was working on a windows box has be back to believing that a funky character or something is causing the error on the linux box. I wish we could narrow it down. Have you tried to install into another linux environment, EC2 for example, and see if you get the same issue? (That may tell us if it is a linux thing or if it is your one specific environment.) Also, someone mentioned to ask if you have any proxies running in front of FusionAuth?

@dalamenona We had the same error with Prometheus.
The following opened FusionAuth issue contains information about the topic

https://github.com/FusionAuth/fusionauth-issues/issues/3082

Best regards.

@dalamenona I see your point about the Database_primary_pool_MaxConnections being set to 20 on the value for usage being reported above that. Browsing around the web, I came across something that said Database_primary_pool_Usage is over the lifetime of the application, but can't seem to find the source now. You also make a valid point about around the other data defenitions. It may make sense to do a deeper dive into HikariCP sources in general. There may be some answers there.

Anyone here familiar with these numbers?

It may also make sense for you to open an issue with FusionAuth as it is not clear to me if these numbers are coming from FusionAuth or HikariCP.

Hi there, I'm working on the same project. And since this forum post, the error did not occur again for about a month and has recently occurred 3 times in the last week.
The instance is a fusionauth instance.
(auth.*.ch is a CNAME (alias) for bnjmvfriojf0pzpzhtmmz6xf2sgl6b.durable.fusionauth.io)

The access where the error occurs was via browser (firefox to be exact if sentry is to be believed).

There are no recent changes to the CORS config.

For most of our users this does not seem to be an issue. It happens very isolated for a handful of users.

@Alex-Patterson said in Node Version Compatibility:

@max-0 our SDK package.json can be found here https://github.com/FusionAuth/fusionauth-typescript-client/blob/master/package.json

In reality, we don't impose any limitations on a client, if something doesn't work well with your setup you can always exit from the SDK strategy and call the API's directly.

Thanks for the clarification! Good to know we can always call the APIs directly if needed.

@dftz3966 said in Is there away to provide error message data from a webhook via either Webhook or Event logs?:

@mark-robustelli said in Is there away to provide error message data from a webhook via either Webhook or Event logs?:

@edschlough If you take a look at the example code from the webhook documentation, it shows how to return errors. Is this what you are after?

Thank you so much
Wow! This is what I need, thank you for sharing

@vijaysingh1784 Looks like you have done a bit of research your self and made a pretty good analysis. I am not very familiar with MojoAuth, but just to confirm a few things:

FusionAuth is very customizable. You should check out things like Lambdas, Webhooks and other various options.

FusionAuth can be self-hosted or can be hosted for you.

FusionAuth handles SAML, SCIM and other various integrations.

FusionAuth is very scalable and gives you great control with api acess and other mechanisms.

Depending on your needs, FusionAuth can be as easy to self host as spinning up a docker image to a full blown complex K8s deployment. It should fit your needs there.

While there is no direct migration guide for the product you are talking about, there are several other migration guides for you to look over that should give you an idea on how to do it.

@michaelginn529 What do you have your "Logout behavior" set to for the application? Any other specific configuration you can share would help as well.

I see your point about using a proxy, but I’m not fully convinced it’s the best long-term solution.

The problem with putting all the responsibility on the proxy is that it creates another layer of complexity and a single point of failure. If FusionAuth is going to support enterprise-level security use cases, shouldn’t mTLS be handled natively instead of relying on external workarounds?

Upvoting the issue is fine, but depending on a proxy feels more like a patch than a real fix. Curious to hear if others think this approach is sustainable, or if we should be pushing harder for first-class support directly in FusionAuth.

@benlabbe2007 What version of FusionAuth are you running?

@sergey_smirnov, it is awesome that you are able to follow and create steps to replicate the issue. To be 100% I'm not sure if this is a bug or a feature request. If FusionAuth is not behaving as you would like it, I would suggest opening an issue on Github. Be sure to include the details and repeatable steps.

Thanks for your answer. I got it.

@mark-robustelli Thanks for your reply, Mark. If I manage to make it, I’d love to show you how I made it and what it looks like.

Thanks for your answer. I got it.

@njanaskie You are correct in that magic links are designed to be a one time use. I do not know of any work around for your situation.

It will be interesting to see if others chime in.

@mark-robustelli hi Mark! thanks for sharing the link. Yes, I've seen that and in general it should fit. I'm just looking for more details as my use-case is quite specific.

execute a step-up auth flow before a sensitive operation (e.g. transfer of funds), use that specific step-up auth flow to validate and then execute an specific operation (like a step-up ID binding to the operation the user started)

I need a way of validating that a specific step-up auth is bound to a specific operation. I have seen the description of a use case of using trustChallenge and trustToken to validate a FusionAuth change password request. This is kind of what I need to do, but on my API endpoints. I'm wondering if it's possible to validate trustToken using a trustChallenge on my own API.

e.g.
a. call a sensitive request triggering step-up with trustChallenge=1234
b. bind operation with trustChallenge
c. complete step up and receive trustToken
d. validate trustToken using the trustChallenge (this is what I would need to know) and confirm/finalize sensitive operation.

FusionAuth is expecting a timely response. If any part of your code reads the body slowly or delays responding, it might exceed FusionAuth's internal timeout (usually around 5–10 seconds).

@mark-robustelli thanks

@eakpan Awesome, thanks for posting. This may end up helping others. Glad you are able to configure FusionAuth to work for you.