If you need to keep everything in sync between your dev, staging and production systems, I believe the best way to accomplish that is to create the key-pair outside of FusionAuth and use the “Import RSA key pair” functionality.

If you are using the UI, you can find that under "Settings -> Key master". The button in the upper right hand corner lets you select between the different options:

Screen Shot 2020-09-24 at 1.48.38 PM.png

You can of course also use the API to import the keys: https://fusionauth.io/docs/v1/tech/apis/keys

Thanks @sjswami , this duplicate ids issue is now resolved in 1.19.7. Appreciate you letting us know about it: https://github.com/FusionAuth/fusionauth-issues/issues/890

@tom-hynard if you update to 1.19.7, this bug should be fixed: https://github.com/FusionAuth/fusionauth-issues/issues/880

We don't have any IIS guides for a proxy, but this guide looks like it would work: https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing

The key is that version 1.19.x of FusionAuth is completely stateless so the proxy can round-robin and no session pinning is required. If you are using a version of FusionAuth before 1.19, you'll need to pin your session to ensure that you can log into the administrative interface.

@dan Thanks for your reply

What version of mysql are you running?

You might want to check the section on mysql and unicode here as that has caused problems for others: https://fusionauth.io/community/forum/topic/243/installation-problem/15

Hiya,

This JWT is valid because the JWT is not expired. You can't revoke a JWT by logging out because they are stateless. Here's more information about how revoking JWTs: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts

This is one of the reasons why we recommend storing a JWT in a server side session, so that removing the session (on logout) removes the JWT. More here: https://fusionauth.io/learn/expert-advice/authentication/webapp/oauth-authorization-code-grant-sessions

Does that help?

There is not any way to push events from FusionAuth to a system like pagerduty, except those outlined by the webhook docs which are less system level and more app level.

If you are monitoring using systems like opsgenie, you can pull data from several different sources:

There's the system status endpoint, which can be polled. Before 1.19, it was binary (200 is good, anything else is bad) but now with 1.19 there are defined status codes: https://fusionauth.io/docs/v1/tech/apis/system#system-status This is the single best endpoint for a healthcheck. If you want to ingest system logs so they can be searched/scanned, you could set up a job to export the system logs: https://fusionauth.io/docs/v1/tech/apis/system#export-system-logs and process them (that that doesn't work for container based systems, see the docs for more). These logs are what you'd see if you were running fusionauth in docker and looking at STDOUT (so system level stuff). You can write your own scripts against the API to test for certain use cases ("Can this user login?", "Can this user register?") There's an event log which captures, well, system events, which can be accessed via the API: https://fusionauth.io/docs/v1/tech/apis/event-logs There is also the audit log, which is probably not what you are looking for, because that is less system level and more 'in app' events, with admin level actions being written (see also this issue). But it can be read via API: https://fusionauth.io/docs/v1/tech/apis/audit-logs

If you are running in Fargate, k8s or another container based system, your best option is to write something to pump the logs through a stream which you can then process for interesting/problematic events.

If you use the request body you should be fine. You can do a lot more than 500 if you like.

I would start with 5-10k and see how performance is.

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