User ids need to be globally unique. You can either provide your own unique uuid or you can let FusionAuth provide them for you. But these values are not tenant scoped.

Ah, that's great! I've definitely made my share of mistakes, no worries!

Great. I've updated the documentation to reflect that google and facebook aren't supported; that'll be published next week. Sorry about that.

More details on the bug I filed above (and the doc change linked in the bug). If you try this with SAML/OIDC and it fails, please let me know.

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

There's not really a supported way to modify the FusionAuth logging format.

In theory you could do it manually but dropping in your own version of logback.xml and adding the necessary jars to the classpath.

Here is an example of JSON with logback. https://github.com/larose/logback-json-example

I think you’d have to add in the JSON logback jar since we do not ship with it.

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