Roles are associated with applications and users, whereas grants are associated with users and entities.

To find all users with role X or grant Y, you'd need to make two different search calls like this:

By Entity

GET/api/entity/grant/search?entityId={uuid}

By User

GET/api/entity/grant/search?userId={uuid}

You don't need to maintain a separate database.

Here's an example of a grant search for a user: https://fusionauth.io/docs/apis/entities/grants#search-for-grants

If you search for the string Example JSON in the page you will also see the link to Entity APIs

I am setting up account lockout and I would like to setup a custom message. Is it possible to customize the Account Lockout Message? If so, how?

As of July 25, 2023 we now support Unlimited Custom Domains for FusionAuth Cloud! You can read more in this post, on how to add a custom domain.

As of July 25, 2023 we now support Unlimited Custom Domains for FusionAuth Cloud! You can read more in this post, on how to add a custom domain.

@alexiussamson83 With a single FusionAuth Application you can use this with multiple SDK's or API's.

https://fusionauth.io/docs/v1/tech/client-libraries/

@evanm I would recommend using a JWT in your API and storing the user id to associate the user to your stripe user account.

You can find more about this in our tokens docs, here you will want the sub.

https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/tokens

On point two it is a classic it depends scenario. This could be handled by logic that you build, or if it makes sense you could use FusionAuth's groups or entities

@ronn316 if you want to use silent mode during the upgrade

https://fusionauth.io/docs/get-started/download-and-install/silent-mode

@aman-c FusionAuth is completely running outside of Next.js. So it all depends on what you are using to make the call to FusionAuth.

My suggestion would be to implement a version of our React SDK
https://fusionauth.io/docs/sdks/react-sdk

Then anything clientside that needs details you can use the built in hooks, anything serverside you can use the cookie that sits at app.at or for identity app.idt.

If you have been using our quickstart you are most likely using next-auth which could be causing issues with the implementation. We have had a lot of internal discussion about removing this methodology moving forward to simplify our Next.js suggested implementation.

You can find out more about our cookies that are set in our Hosted Backend details.
https://fusionauth.io/docs/apis/hosted-backend

I believe what you are seeing is the consent mode, you can find more details on this

https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/scopes#form-fields

The /oauth2/consent endpoint in FusionAuth is used for handling user consent during the OAuth process. It provides several variables that can be used to customize the consent prompt:
action: The action the user selected on the consent prompt. The value should be allow if the user made consent selections and wants to continue or cancel if they have decided not to continue.
optionalScopes: The list of OAuth scopes on the request with optional user consent.
requiredScopes: The list of OAuth scopes on the request that require user consent.
scopeConsents: A map of OAuth scope consent choices made by the user. The key into the map is the OAuth scope name. The value should be true if the user has consented to the scope or false if they have declined.
unknownScopes: The list of unknown OAuth scope names on the request if the application is configured to Allow unknown scopes.
These variables are available since version 1.50.0 of FusionAuth.

This can also be used in theming.

https://fusionauth.io/docs/customize/look-and-feel/template-variables#oauth-consent-prompt

@aman-c do you have a repo available for this?

Also what are you trying to use next-client-cookies for in the app? Is it in a client-side only app?

Are you trying to access app.at to get the Auth cookie?

@bubblez there was also a change in 1.50 (so I am surprised if you were on 1.51 if this would happen) where we stopped sending email to the app.id JWT and only provide this within app.idt.

I would recommend updating the code accordingly if you are still using this method.

An alternative but not suggested is to change your scope handling policy to Compatibility which will send this again in your app.id.

@bubblez do you have the scope correctly set within your Identiy provider?

I am testing this now locally to see if there is a difference on the versions.

@aswetnatex

docker pull fusionauth/fusionauth-app:latest

@milton-jesus awesome glad you solved it!!

@milton-jesus is there a requirement leaving you on 1.15.8?

Have you tried with latest?

https://fusionauth.io/docs/release-notes/

@tschlegel thank you for reporting! This appears to be a bug. I have created the same issue within our GitHub issues page to follow up with, feel free to follow over there for status. I have prompted the engineering team as well so it gets on our "short" list.

https://github.com/FusionAuth/fusionauth-issues/issues/2863

Hey, are you interested in learning more about JSON Web Tokens and how to protect your APIs with them?

Join my talk hosted by the great peeps at Gun.io!

https://www.meetup.com/gundotio/events/302264818/