@dan Yes, I am using the login API and the Identity Provided API. More specifically, the following routes: /api/login & /api/identity-provider/login. They both have similar response cookie functionality. Your explanation makes sense, however I do agree with the GitHub issue about this functionality being optional (or at least allow the developer to choose which response cookies they want to set). For the meantime, I suppose I'll just use the provided functionality as-is and look more into the mentioned alternatives if necessary.
Also, thanks for linking to the SameSite configuration. I'll take a look at it to see if it fits my needs.

Thank you for your reply!

Well, I'd just call the 'create registration' API from the server three times after a user had successfully registered on your custom page: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-registration-for-an-existing-user

Does that make sense, or do I misunderstand your question?

Are you using javascript in the browser to register the user? Or a server running node (or some other language). If the latter, you could send down an HttpOnly cookie based on the response of the registration.

You can also view some of the back and forth between @robotdan and I on the issue I filed: https://github.com/FusionAuth/fusionauth-issues/issues/878 🙂

Try adding mode: 'no-cors' to your request to see if that changes your result.

Also, make sure that application/json is the Content-Type header for all requests to the FusionAuth API, unless otherwise specified in the documentation.

Narrator: This resolved the issue.

Here's an example using flask: https://github.com/FusionAuth/fusionauth-example-flask-portal

You can see all the example apps here: https://fusionauth.io/docs/v1/tech/example-apps/

Officially we don’t require anyone to upgrade. However, generally speaking we don’t back port patches, this means if you need a fix you’ll have to upgrade to get it. There are a lot of good reasons to keep a security product up to date.

But when you pay for an edition of FusionAuth that includes support, you can run whatever version you want (more or less).

We only publish keys that we can use for signing, so a public key all by itself will not be published via JWKS. If you import the entire key pair, it will be published on the JWKS endpoint.

You can also generate a keypair too.

You can use the database.maximum-pool-size value in the fusionauth.properties file prior to 1.19.x ( it was just not documented) , but if you want to use the environment variable version is not available until 1.19.x.

Is this what you are looking for?: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-and-registration-combined

That API does return a token as of v1.17.0.

Please feel free to vote for the issue @mehr-prs , if it is important to you. Here's the general FusionAuth roadmap guidance: https://fusionauth.io/community/forum/topic/172/the-fusionauth-roadmap

No worries.

Please upvote it if you are interested in this moving toward the front of the work queue.

Not really, at least not through FusionAuth interfaces.

If you have particular queries that aren’t working well, you can open an issue in GitHub or a support ticket: https://github.com/FusionAuth/fusionauth-issues/issues

I do not believe so. I just added a github issue for a similar issue: https://github.com/FusionAuth/fusionauth-issues/issues/874

Please feel free to upvote this if the issue describes your goals.

If not, please explain in more detail what you are trying to accomplish.

Not currently.

You could create a single user called anonymous and auth that user to get a generic token.

There is an open issue for a more elegant solution; feel free to upvote it: https://github.com/FusionAuth/fusionauth-issues/issues/525

No, the users must have a password. In this scenario, where you know the users do not have a password, you can just set a secure random password. A UUID, or other securely generated high entropy value.

You can provide the password value, but this will cause FusionAuth to hash it inline, so it will be costly in terms of time and CPU if you are importing a large number of users.

If you don’t want to take this hit at import time, you can provide these users just random hashed values, as long as you provide the factor, encryptionScheme, salt and password FusionAuth will assume this is a hash, and it will not re-hash it.

It means the user won't be able to login.

You should be able to go the user's tab and then expand the 'advanced' section and select a given application.

See this screenshot:

user search with 'advanced' section expanded

Also, see database.maximum-pool-size here https://fusionauth.io/docs/v1/tech/reference/configuration