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

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

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

@itai This is what exists today, the team is working on more features for webhooks in upcoming releases.

FusionAuth provides certain guarantees when it comes to the delivery of webhooks. These guarantees are determined by the transaction level that you set for your webhooks. The transaction level can be one of the following:

• "No webhooks are required to succeed": In this case, FusionAuth will "fire and forget" the webhooks. Even if all webhooks fail, the operation (like a user update) will still succeed (source).

• "Any single webhook must succeed": If at least one webhook succeeds, the operation will succeed. If all webhooks fail, the operation will fail. FusionAuth will retry failed webhooks up to three additional times (source).

• "All webhooks must succeed": Every single webhook must succeed for the operation to succeed. If any webhook fails, the operation will fail (source).

In case of failures, FusionAuth will retry sending the payload up to three additional times. If a webhook endpoint times out, this is considered a failure, the same as if a non 2xx status code is returned. If the endpoint does not respond after the retries, the failure will be logged in the system log (source).

It's important to note that if a webhook is transactional and returns a non 2xx status code, the corresponding action will not succeed. For example, if a user login triggers a webhook and the webhook fails, the user won’t be able to log in (source).

JavaMail settings in FusionAuth can be configured under the SMTP settings of a tenant. You can access these settings by navigating to Tenants > Edit > Advanced > SMTP settings. Here, you can add additional properties for JavaMail.

For example, to enable debug mode, you can add mail.debug=true to the additional properties. This will provide more verbose logging for SMTP, which can be helpful for troubleshooting email issues. The debug logs can be viewed under System > Logs and selecting fusionauth-app.log source.

In some cases, you might need to set timeouts for the SMTP connection. This can be done by adding the following properties:

mail.smtp.connectiontimeout=2000
mail.smtp.timeout=2000

These settings will set the read and write timeouts to 2 seconds (2000 ms) source.

If you're experiencing issues with email delivery, it might be helpful to change the SMTP port or switch between TLS and SSL, especially if you're using a cloud service like FusionAuth Cloud, which has certain restrictions on ports source.

Remember to be cautious when enabling debug mode or changing other settings, as it could potentially lead to a large volume of logs or affect the performance of your application.

@evanm Yes you can use the sub inside of the JWT when making any API call to your backend. In your database this will be a unique Id for the user. You can even get more details about the user from FusionAuth by calling the User endpoints.

https://fusionauth.io/docs/apis/users#response-1

@richard-0 do you have a sample repo you could share, or your full config for the SDK?

@ronn316 I believe there was an database change that was required in 1.50 https://fusionauth.io/docs/release-notes/#version-1-50-0

You will need to check the upgrade info
https://fusionauth.io/docs/operate/deploy/upgrade

specifically the database migration in silent mode
https://fusionauth.io/docs/operate/deploy/upgrade#downtime-and-database-migrations

I do this all the time and keep meaning to create a post on codingcat.dev for it instead of hitting Jeff's site for it all the time. In the meantime I would suggest checking this out it always works for me

https://fireship.io/lessons/google-apis-node-tutorial/

@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

@tvdlooy were you able to resolve this?

@zaalbarxx sorry for the delay. I might be missing it (sorry not a PHP person) but I don't see where that confusion comes into play. I know that some of our docs had to get updated because of a change that we made during our 1.50 release that required to request further details in our scopes request.

This release makes significant changes to the default behavior of new Applications with regard to scopes in OAuth workflows. The database migration will update existing Applications to behave in a backwards compatible manner. See the OAuth Scopes documentation for more information, in particular the Relationship, Unknown scope policy, and Scope handling policy configurations.

https://fusionauth.io/docs/release-notes/#version-1-50-0

Let me know if that still isn't making sense, or if there is a spot you were hung up on and I would be happy to update our docs. Or even better feel free to add a PR.