Options:

You can drop the database. This will work if you want to start with a clean slate every time. You may want to look into kickstart or terraform to set default applications, accounts, and other items up every time. You can load all the users into a tenant (not the default one). Then, when you are done with loading up the users and want to clean up, you can delete the tenant, which will remove all users associated with that tenant. This option maintains all the other non tenant settings (IdPs, emails templates, themes, etc). You can use the bulk delete API. You can start deleting blocks of 5-10k users and increase the number deleted with each API call. This will be slower, but has the benefit of leaving the rest of the system untouched.

Added a feature request for this issue: https://github.com/FusionAuth/fusionauth-issues/issues/904

The rules apply only when they change their password in the future.

We don't have any way of knowing the user's current password.

You can, of course, force the user to change their password, and then the new password rules would apply. You can do this in the admin ui or via updating the passwordChangeRequired field in the user object via the API.

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.

Ok, thanks @dan and @robotdan ! I think a combination of both your responses gets me what I need. Much appreciated!

I would do one of two things:

consult the google docs about what is returned create a lambda to write the idToken json object provided by google to the event log, then login and view the event log to see what is provided.

More on the google reconcile lambda here: https://fusionauth.io/docs/v1/tech/lambdas/google-reconcile

We use logback.

As of version 1.19.0, here is the logging pattern: <pattern>%d{"yyyy-MM-dd h:mm:ss.SSS a"} %-5level %logger{75} - %msg%n</pattern>

Older versions, prior to 1.19.0, use this pattern <pattern>%d{"MMM dd, yyyy h:mm:ss.SSS a"} %-5level %logger{75} - %msg%n</pattern>.

Head over to the admin, and click tenants.

There you will find your default tenant. edit that to change your password strength etc.

(You can also do that for multiple tenants if you have them or via the Tenants API.)

Seems like the library I used is opinionated. Thanks for the hints.

@vrademacher ah, great, that wasn't clear to me!

Then while the forum and community support might be able to help, I'd recommend filing a support ticket by logging into account.fusionauth.io and going to the support tab.

Feel free to reference this forum post if you'd like.

If you'd like to continue to debug this issue here, can you please give me a bit more info?

It'd be great to know:

the version of fusionauth where you are encountering the issue the login flow (login api, oauth authorization code grant, etc) the browser the customer is using anything unique about the customer as opposed to other customers that are not having this issue

Yes. While OAuth2 access tokens aren't guaranteed by the spec to be JSON web tokens, in FusionAuth access tokens are always JWTs.

@robotdan Also, it was actually me who opened the mentioned issue. 😅

yeah, pretty simple really, if you want to try it yourself before my tutorial is out, try using the hasura cloud + Auth0 tutorial on Hasura's site, and use the lessons from that to use it with fusionauth.

Yes, it's the fusionauth application id, defined here: https://github.com/FusionAuth/fusionauth-java-client/blob/master/src/main/java/io/fusionauth/domain/Application.java

Awesome. Just wanted to make sure you weren't expecting to be able to encrypt anything in the browser and keep it secret 🙂 .

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.