Support for wildcards in redirect URIs just landed in 1.43.

We don't recommend using these because they are against the OAuth specification (you could look at using the state parameter instead).

But we listened to the community feedback on this issue: https://github.com/FusionAuth/fusionauth-issues/issues/437 and implemented it.

It is still being documented, but you can read about it here: https://fusionauth.io/blog/2023/02/16/announcing-fusionauth-1-43#support-for-wildcards-in-redirect-urls

Hope that helps, @davidmw !

@maitrey0388 Just to make sure I understand what you are asking, you want to see on the user details page anything that has been done by another user?

This is currently not possible. Two things that might help:

Creating a user action whenever anyone modifies a user. This can have a record of the user who took the action and what the action was; it shows up under the 'User actions' section on the details screen. Make sure you create a time based user action. Here's more on that: https://fusionauth.io/docs/v1/tech/apis/user-actions and https://fusionauth.io/docs/v1/tech/apis/actioning-users Use the audit logs. These already are created for any action taken inside the admin UI, but not for APIs (open issue) but you can create an audit log entry every time an API is called using another API. Audit logs are not accessible in the user details screen, but you can export them and/or view them in the admin UI.

Hope that helps.

@aminjabari242 That is correct. Thanks for posting.

Yes, this does trigger an MAU increase.

Here's a list of what makes a user active during a month: https://fusionauth.io/docs/v1/tech/core-concepts/users#what-makes-a-user-active

Hello
It depends on the specific system or platform you are using. You may need to consult its documentation or support resources.

@bryanlandia I don't quite understand what you are trying to do. Can you send the user to the SAML IdP on registration with a normal login hint and have them register there? As long as FusionAuth gets back the signed assertion, it doesn't care if the user logged in or registered at the IdP.

So you could actually replace the FusionAuth registration link with a link to the SAML IdP with a login_hint.

Or am I missing something?

@dan Last week ago I am facing that issue and I am still not got any solution.

Hmmm. Haven't run into this before. You are right, it sure looks like you have enough memory.

This GH issue indicates you might need to update your docker.

https://github.com/adoptium/temurin-build/issues/2976#issuecomment-1152142311

But I'm not quite sure what is going on. Did you find a solution?

@khairul We recommend running FusionAuth behind a proxy. More docs on that here: https://fusionauth.io/docs/v1/tech/admin-guide/proxy-setup

If you are running in docker-compose, you should be able to add an nginx or other proxy image and connect that to FusionAuth.

The proxy can then terminate TLS and run on port 443.

That is correct. For security reasons, we do not provide feedback if the user exists but the password is incorrect, vs the situation where user does not exist.

This is true both in the hosted login pages and the login API response codes. That's what we recommend if you build your own pages as well.

Select Start > Settings > Time & language > Language & region. Under Preferred languages, select the language you want to remove, and then select Remove.

A refresh token is opaque; you cannot validate it yourself.

The general pattern for validating a refresh token is to use it to refresh the JWT, and if the refresh attempt fails, that indicates the refresh token is no longer valid.

You could also retrieve a user’s refresh tokens and compare it to the ones returned by FusionAuth.

More details:

https://fusionauth.io/docs/v1/tech/apis/jwt#refresh-a-jwt
https://fusionauth.io/docs/v1/tech/apis/jwt#retrieve-refresh-tokens

I value the insights and guidance you provide, I will try to figure it out for more.

The easiest way to do so is to listen for the jwt.refresh-token.revoke event.

It's documented here: https://fusionauth.io/docs/v1/tech/events-webhooks/events/jwt-refresh-token-revoke

In particular, you have the date of the revocation (the end of the session). If it is an individual session revocation, you have the start date, which is the startInstant inside the events refreshToken field.

If your webhook processor does the subtraction of these two values, you'll be able to find and record the duration of the session length.

@dan And how do you add a button? Do you have an example? if I want to delete the token and make a forward redirect the user to another page (the login, for example).

No error in registering existing users.

@jbtruffault Thanks! The admin UI has minimal customization, but appreciate you raising the issue. It's on the list.