Did you register the new user with the application?

This doc talks about the two different concepts of authentication and authorization in the context of FusionAuth: https://fusionauth.io/docs/v1/tech/core-concepts/authentication-authorization/

At this point, you may also consider creating a KickStart script that loads the basic configuration with mentioned API keys, groups etc. into a fresh FA installation. You've mentioned that you are working on a test installation, so during the further tests you will probably fill it again with new test data entities. If so, it will most likely be easier to recreate the FA with basic configuration via KickStart, rather than to pick unnecessary entities and delete them one by one. Such script also stands as a good documentation on what configurations has been made to meet your environment requirements.

This post may be a bit off the topic, but from my experience such approach quickly pays off, so you can at once solve your issue and boost up your testing environment ergonomics.

Looks like this was a regression and based on the github issue a fix should be released in 1.23.4. Sorry about that!

I think @mgetka makes some good points. I'm afraid I don't have enough detail to provide an authoritative answer. From what you've said, I think you could do this with roles, application registrations, groups or even user actions. You could for example, have three different groups of roles (they are just strings, and you can add more than one to a user):

... team1_member team2_member ... position1_holder position2_holder ... access_perm_1 access_perm_2 ...

I guess it also depends on how you want to consume these. Are you going to be looking up the user via FusionAuth API calls? Or will you want this embedded in a JWT for portable claims?

In the former case (API calls) you can make multiple calls and learn a lot about the user.

In the latter case, even though you have the JWT populate lambda, it is limited to what is on the user and registration objects.

So you couldn't, for example, know the group name (though I believe you have the group id) in the lambda, so you couldn't put it in the JWT. More on this issue.

While FusionAuth supports both well, if you have the option to use SAMl v2 or OIDC, I would always recommend OIDC.

In general, it is much much simpler to use, debug, configure, etc.

I see patchUser here:

https://github.com/FusionAuth/fusionauth-java-client/blob/1.19.0/src/main/java/io/fusionauth/client/FusionAuthClient.java#L1664

I think that's what you want.

You can, however, always full retrieval and a put as a workaround. That is recommended if you are changing an array, unless you want the behavior documented here: https://github.com/FusionAuth/fusionauth-issues/issues/441

we use asciidoctor + jekyll.

Our website config is open source, please steal^H^H^H^H^H borrow it: https://github.com/fusionauth/fusionauth-site/ here's our css too: https://github.com/fusionauth/fusionauth-style

Version 1.12 is quite an old version. I would recommend upgrading and see if you can recreate the issue.

Sounds like the database is struggling.

Ensure your db is available, and sized reasonably.

If you are using a free tier of a managed database service ensure you have not exceed your IOPs.

You can use https://yourservername.fusionauth.io/api/status if you like.

That endpoint will optionally return JSON you can parse if you provide an API key, otherwise just an http status code.

More details here: https://fusionauth.io/docs/v1/tech/apis/system/#retrieve-system-status

Actually, as of when I write this post, we have two license keys available for anyone with a paid edition. One is a prod license and the other is a non prod license. The latter is a good fit for testing, CI, etc.

Yes, you could connect one FusionAuth to another using an OpenID Connect Identity Provider or SAML v2.

You are correct. The verified flag exists on the corresponding user and the registration. You could optionally use the "verify registration" templatefor this purpose.

If you then ignored the verified: false flag on the registration in your code, it should not impact you.

Another option would be to listen for the user.registration.create event and then fire off an email on your end, or call the Email Send API to send a pre-made FusionAuth email template as a welcome event: https://fusionauth.io/docs/v1/tech/apis/emails/#send-an-email

Will this one work for you?

https://fusionauth.io/docs/v1/tech/client-libraries/netcore/
https://github.com/FusionAuth/fusionauth-netcore-client
https://www.nuget.org/packages/FusionAuth.Client/

I thought that might be a possibility and later tried a t3a.small (vs. t3a.micro) in a new install. So far that's has been working. (As far as anything else on the box - nothing. I like to dedicate at least one VM per major system.)

There's no way to create such a super admin account that can't be modified in FusionAuth.

Options I can think of to achieve something similar:

make sure you have database backups (a good idea anyway) and recover from your last backup if an admin deletes/locks the primary admin account. Or just investigate the FusionAuth database such that you can flip the bit in there if anyone ever locks the primary admin account. create a second tenant and create a tenant scoped API key. Then build whatever user management tooling you need using that API key. The super user will remain untouched and inaccessible in the default tenant. limit people to the roles that they need and never provide anyone with the user_deleter or user_manager role. The user_support_manager role may be helpful to you: https://fusionauth.io/docs/v1/tech/core-concepts/roles/

Only the last one allows users other than the superadmin to access the FusionAuth admin UI.

Feel free to file a feature request explaining your desired functionality in more detail if you'd like.

You can customize the forgot password page by modifying the theme. More details here: https://fusionauth.io/docs/v1/tech/themes/

The template you are looking to modify is the Forgot password template.

There is currently no Forgot username functionality. Please feel free to file a feature request for this functionality.

Is there a way to get the actual error via the FusionAuth admin dashboard?

You can check the event logs and the system output if you have access to the logs, but I don't believe there's a lot of debugging info available for that particular path.

This troubleshooting doc may be worth reading: https://fusionauth.io/docs/v1/tech/troubleshooting/

Also, if you are interested in building a more secure JWT, this article may be of interest: https://fusionauth.io/learn/expert-advice/tokens/building-a-secure-jwt/

So, this appears to be a limitation of Facebook. Here are the API docs from Facebook which have no mention of how long the image URL returned if you pass redirect=0 is good for.

Looks like some Auth0 users also encountered this.

So I think you are on the right path with downloading the user's Facebook images and updating them on your side every time a user logs in.