This is due to non-ASCII characters in headers causing an issue in the FusionAuth parsing code. Cloudflare sends headers with non-ASCII characters (such as cf-region: São Paulo) which triggers this issue.

This is a java-http bug that was fixed in 2024, and released in FusionAuth version 1.51.2.

So, two options:

upgrade to a version of FusionAuth 1.51.2 or newer. This is the recommended approach, but may require some work. as an interim workaround, you can disable the "Add visitor location headers" option from your CloudFlare console. This should not have any negative impact, since we do not inspect those headers.

@jobclone20 I just took a look at the page for the FusionAuth Visual Studio Templates. It appears they are only for Visual Studio 2022.

@skorupa-pawel I saw this on Firefox in the past but never on Safari.

Does this apply to all applications?

Do you have a logout url configured in the OAuth tab? Does that URL exist?

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.

HTTP clients, not just Axios, may impose their own requirements for building a valid request or have their own quirks to deal with.

In this case the error can be resolved by providing a Content-Length header with the length of the JSON request data when making the API request via Axios.

If you experience issues with a particular HTTP client, it may be helpful to compare the behavior with another client or check whether there are HTTP headers that may be required by the client.

@dan Sorry I didn't get a notification that you'd replied, so my apologies that I didn't see that sooner. I'll try moving to the latest version to see if that helps before reporting back.

Please check that you configured an SMTP server in the default Tenant (and for every other tenant, for that matter).

It defaults to localhost and port 25, and if you don't have an SMTP server running there, any functionality sending emails, like forgot password, won't work.

To work around this, you can set the password for any user using an API key and the User API: https://fusionauth.io/docs/v1/tech/apis/users/#update-a-user

Ensure you are not using a reply address from @fusionauth.io; if you are this will fail our DMARC policy.

You don’t necessarily want to remove this reply address, but it should not be using our email domain. Instead it should be an address that belongs to your organization, such as no-reply@example.com. (Or, even better: customersupport@example.com--I hate when I get an email I can't reply to, myself.)

Each email template also has the option to override that default value with a different value. So you may also want to audit each email template to ensure if it is using a different From address, it is also owned by your domain.

For anybody having this issue, it turned out I had written my URL wrong: http://company.fusionauth.io for example instead of https://company.fusionauth.io. The redirect to https:// caused the error.

And now it works fine with 152 threads connected, so unable to reproduce this.

I'll keep an eye out for this behavior and file an issue if it pops up again.

For the record:

FusionAuth 1.27
installed via zip file
Mysql 8.0.23 installed/managed via homebrew on the mac.

This exception is caused by the fact that your objects in elastic now have two different schemas (one with the number, one with the string). You need to manually fix that; one way to proceed might be to access elastic directly and remove that one user.

Then you'll need to reindex; here's more on that: https://fusionauth.io/docs/v1/tech/core-concepts/users/#reindex

My guess is that this version of MySQL on Digital Ocean is using MySQL Group Replication which is not supported.
https://fusionauth.io/docs/v1/tech/installation-guide/system-requirements/#database

Group Replication performs replication under the requirement that each table have a primary key, which we do not.

You can use a managed database that uses a different strategy for replication, or use PostgreSQL.

We have had a couple of people have this exception in Kubernetes because the nodes can’t talk to each other. Is your setup configured so that each node can talk to each other node?

I would expect that the configuration would need to use the k8s names rather than IP addresses for all of the nodes. This is configurable in the configuration file or through env variables. More here: https://fusionauth.io/docs/v1/tech/reference/configuration/ . Look for the fusionauth-app.url setting.

If this is a new install, this is expected. During startup, FusionAuth goes into maintenance mode and reports back on the state of the system.

If you are in silent mode, the index will be created for you, if you are not in silent mode, FusionAuth will have entered an interactive startup mode and it is sitting on a prompt for you to create the Elasticsearch index.

More on silent mode.

That's great to hear, glad you figured it out!

Double check that you are calling the precise API URL.

http://<hostname>/api/login will work, but http://<hostname>//api/login will not. Though some user agents ignore the double //, FusionAuth treats them as two different URLs, and returns HTML which the API client doesn't know how to parse (hence the error message).

In 1.19.5, we handle most of these cases by configuring tomcat to allow certain characters to be unescaped in the URL.

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

So an upgrade is the most straightforward way to handle this.

If you are proxying FusionAuth (behind something like nginx) you could also capture and hide any 500 errors: https://stackoverflow.com/questions/8715064/nginx-not-serving-my-error-page/8715597#8715597.

@civaxox259
you fix you problem on `https://libroslara.com/libros/
becouse i donde see any problem on tha page

Turns out that I didn't have much disk space.

Saw this in the FA search logs:

{"type": "server", "timestamp": "2020-06-10T14:34:28,378Z", "level": "WARN", "component": "o.e.c.r.a.DiskThresholdMonitor", "cluster.name": "FusionAuth", "node.name": "ubuntu-xenial", "message": "flood stage disk watermark [95%] exceeded on [NE_DhFssRru-H5oIiLwBjA][ubuntu-xenial][/usr/local/fusionauth/data/search/esv6/nodes/0] free: 887.9mb[4.4%], all indices on this node will be marked read-only", "cluster.uuid": "LGdaij30RrS4FZbgsT_6KA", "node.id": "NE_DhFssRru-H5oIiLwBjA" }

Deleting some things from my hard drive lowered my disk usage below 95% and I no longer saw the message.