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

@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

@mo-mustkem It is a Theme Template Variable. Please check out https://fusionauth.io/docs/customize/look-and-feel/template-variables#oauth-authorize. rememberDevice is in /oauth2/authorize

@slifty Let's start with what your desired workflow is and go from there. How would you like the login to work?

@twilkinson That message is logged when an HTTP client closes a connection before FusionAuth can fully send a response. This could be as innocuous as a user closing their browser before a page has completed loading.

Some thoughts:

Do you see other exceptions in the log? Possibly related to database connections? What does the load look like on the DB? Do you see any issues on Elastic if you are using it?

@lambert-torres there is no queue that is kept, you would either need to look at the logs to specifically find the users during that time. Or follow the below steps.

You can resend the verification emails for newly registered users. FusionAuth provides an API endpoint for resending a user registration verification email.

https://fusionauth.io/docs/v1/tech/apis/users#resend-verification-email

Here are the steps to follow if you want to manually verify:

Use the PUT /api/user/verify-email?email={email} endpoint to request a new verification email. This will return a verificationId in the response. curl --location --request PUT 'http://localhost:9011/api/user/verify-email?email=<my_email@my_email.com>' \ --header 'Authorization: <API KEY>' \ --header 'X-FusionAuth-TenantId: <TENANT_ID>' The response should look like this: { "verificationId": "SOME_REALLY_LONG_ALPHANUMERIC_STRING" } Use the POST /api/user/verify-email?verificationId={verificationId} endpoint to mark the user as email verified via API.

Please note that you need to ensure that you don't have skipVerification set to true when a user registers for an application via API and your application has verifyRegistration set to true. This can be set programmatically via the API or via the admin UI.

For more details, you can refer to the FusionAuth documentation and the FusionAuth community forum.

Please ensure that your connection to SendGrid is restored before attempting to resend the emails.

@mjthakur413 Great, let us know how it goes.

@mark-robustelli I had opened a support ticket (via email) and got this response

If you have external calls in your integration, you will want to ensure a fast response Lambdas - If you are calling FusionAuth APIs in a lambda, ensure a connection over port 9012 (as opposed to port 9011). Any other external HTTP calls (to your own endpoints) using HTTPConnect should return quickly as well to ensure optimal performance. Connectors - If you have a connector, then FusionAuth will hold things in flight (database connections, in-memory information, etc) while we wait for your connector to return an authentication response and log the user in. Ideally, your connector would have a read timeout of 1ms and a connect timeout of 2ms or less. Higher values mean FusionAuth will have fewer resources (database connections, etc) available to service incoming login requests (as older login requests are still in flight waiting for the Connector return). Webhooks - If you have any webhooks, these should also return quickly to optimize performance. Any SocketTimeoutException (read or connect) in the Event Log would indicate a slower webhook integration. Adjust Period Tasks If you have any periodic tasks running against your deployment (perhaps to synchronize user data, application data, etc by calling our APIs), then you will want to write back-off logic if the system shows a heavy load (monitoring documentation). Turn off logging in production This change will be less impactful but will help nevertheless. Logging should be used when there is an issue with SMTP/email, lambdas, connectors, users, etc but turned off in production when not needed. Logs are output to System > Event Log. The debug enabled toggle throughout the UI (and API) indicates whether this logging will occur.

The big ones were that we were making calls to the API in a lambda and switched the port as mentioned. We also had left on debug logging in a lot of places so have disabled that for now. Validated our webhooks are all running pretty fast (median type is 1-2ms) and connector is pretty fast, though slower 20-30ms median.

@dan Please mark this as Solved, I personally got confused at first and didn't click on it when I Googled this issue.

So in the end the final solution for Client calls is the patchRegistration function call with the userId and a RegistrationRequest object.

patchRegistration got fixed here:
https://github.com/FusionAuth/fusionauth-issues/issues/441

@j-smutek Awesome, glad to see you up and running!

A CLI tool for managing configuration can be super handy for those who love working from the terminal. There are definitely some robust APIs and terraform providers you've pointed out.

FusionAuth Cloud does not have a strict user count limit for Medium and Large size plans. The 200k and 750k user limits are recommendations based on the expected login and registration volume. If you need to support more users, you can contact FusionAuth support for assistance.

The document you linked to does not mention a user count limit because there is none. The recommendations are simply a way to help you choose the right plan for your needs.

If you are unsure how many users you will need to support, you can start with a smaller plan and upgrade as needed. You can also contact FusionAuth support for help choosing the right plan.

@epnyc Are you sure the "Client credentials JWT populate" is the type of lambda you want to create and not a "JWT populate" lambda?

If you are looking to assign a "JWT Populate" lambda, you need to go to Applications -> Your Application and select to the JWT tab and then select the lambda under the Lambda settings. (You will need to create a lambda of this type in Customizations -> Lambdas)

If you are looking to assign a "Client credentials JWT populate" lambda (sounds like this is what you created), you need to **Tenants -> Your Tenant ** and then select the OAuth tab and choose the Client Credentials populate lambda.

Client Credentials JWT Populate lambda documentation

JWT Populate lambda documentation

OpenSearch version 2.x will function properly with FusionAuth version >= 1.42.0.

Related GH Issue: https://github.com/FusionAuth/fusionauth-issues/issues/1558

If you run into issues please let us know or file an issue so we can take a look.

You have a couple of options:

you can update webhook so it always returns 200, regardless of the message it receives. This won't work if the webhook URL is incorrect. For example, if you set up the webhook to live at https://exmple.com when it really lives at https://example.com and you don't have access to https://exmple.com. if you have an API key, you can update the webhook to be non-transactional. Setting up such an API key is a critical part of common configuration. if someone has an active session in the admin UI, they can also modify the configuration to make the webhook non-transactional.

We have the exact same issue. If this was solved (hopefully) could you please provide a brief description on the fix?
Thanks!