Ah, makes sense.

You should be able to export the email templates via the retrieve email template API and them re-import them using the same API. It may take a bit of fiddling, but it should be possible. In fact, you may want to capture the email templates as a kickstart file for future deployment/dev envt setup ease: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

I think we already have some issues about configuration migration, so you may want to check them out and vote for them if they convey what you'd like (please upvote them if so):

https://github.com/FusionAuth/fusionauth-issues/issues/576 https://github.com/FusionAuth/fusionauth-issues/issues/560

Hmmm. What version of FusionAuth are you running?

If you have set the refresh token usage policy to be OneTime in the tenant settings, then the old refresh token shouldn't give you access tokens after the first call.

Nope.

However, you can write some code to do this. You could write two scripts:

one to add a user, which should register them to all applications one to add an application, which should register all users

Further reading:

This post is probably worth a read, to clarify how FusionAuth handles users without an application registration: https://fusionauth.io/community/forum/topic/5/can-you-limit-a-user-s-login-authentication-access-to-applications-within-a-single-tenant/2?_=1597070984952

You also might be interested in voting up this issue: https://github.com/FusionAuth/fusionauth-issues/issues/772

You could also file a github issue explaining what you are trying to accomplish, perhaps there's a feature to be written to allow this.

@peter-netbal

I would like to know whats the best / recommended practice in this case...

I'm a former consultant, so the answer is "it depends". It depends on how many applications you have and what you are using the verified attribute for.

There is no way to register the user and the registration in one step unless you send the emails outside of FusionAuth. You can of course update the user via the API to have verified true when someone verifies their registration, perhaps by listening to a webhook: https://fusionauth.io/docs/v1/tech/events-webhooks/events#user-registration-verified and with skipVerification set to true.

I also wonder why you need to have both the user object and the register object set the value of verified to true. Can you have your application read just one of those values? Or are you looking to have things consistent between the two objects?

Yes and no. Since OAuth 2.1 isn't released yet (though the working group seems to be getting pretty close) no one can "support" it yet. This is the draft specification right now: https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00

This blog post examines some of the changes and how FusionAuth is set up to handle them: https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1#can-you-use-oauth-21-right-now

Ah, I just tested this out and if you don't need it in the JWT, you should be able to see it in the registrations object returned after login.

Here's a response I get after logging in:

{ "token": "ey...", "user": { "active": true, "connectorId": "e3306678-a53a-4964-9040-1c96f36dda72", "email": "email@example.com", "id": "2df13f18-01cc-48a4-b97a-2ab04f98d006", "insertInstant": 1592857899119, "lastLoginInstant": 1596819645662, "lastUpdateInstant": 0, "passwordChangeRequired": false, "passwordLastUpdateInstant": 1592857899145, "registrations": [ { "applicationId": "78bd26e9-51de-4af8-baf4-914ea5825355", "id": "73d2317b-d196-4315-aba2-3c205ed3ccae", "insertInstant": 1592857899151, "lastLoginInstant": 1592857899153, "lastUpdateInstant": 1596813810104, "roles": [ "Role1" ], "usernameStatus": "ACTIVE", "verified": true } ], "tenantId": "1de156c2-2daa-a285-0c59-b52f9106d4e4", "twoFactorDelivery": "None", "twoFactorEnabled": false, "usernameStatus": "ACTIVE", "verified": true } }

So user.applicationId.roles is what you want. Note that roles are applied on an application by application basis. If a user is in a group which has a role 'roleA' which is created in 'applicationA', but is not registered for 'applicationA', they won't receive that role. More on that here: https://fusionauth.io/docs/v1/tech/core-concepts/groups

The JWT (id_token or access_token) will contain the email_verified claim with a value of true or false, so if you wish to limit privilege based upon this state, that would be a good way to do it.

Not through a FusionAuth policy, but you can do that in the login template if you want to filter it by email domain or something like that.

If you have not let the user set their password, then passwordless will implicitly be the only path that will work for them (assuming you don’t offer them social login buttons).

If you pass the user’s email on the redirect to FusionAuth as &loginId=test@example.com, that value will be available to you in the template and you can then key off, parse the domain, or whatever - and use that to hide or show whatever you like.

I don't see any way to customize the redirect URL on completion of password setup.

One option could be adding a link to the 'Change Password Complete' template to the login page: "Return to example.com".

You could also inject some javascript to do a redirect.

8GB is way plenty. 1 or 2GB is generally adequate, it can depend a bit, but FusionAuth doesn't keep much in RAM. Scaling out horizontallly is likely more effective than more ram per instance. This way you can handle more logins per second--these are going to be cpu bound.

Hiya,

Yup, you've encountered a known limit of the lambda functionality. The two options you outline are the ones I'd consider. You could update the user data with the tenant name on create using a webhook, so maybe not as messy as you might think.

The only other option would be to file a github issue requesting the tenant information be made available in the lambda: https://github.com/fusionauth/fusionauth-issues/issues

There are some similar issues I'd suggest voting up if this is important to you:

https://github.com/FusionAuth/fusionauth-issues/issues/571
https://github.com/FusionAuth/fusionauth-issues/issues/267
https://github.com/FusionAuth/fusionauth-issues/issues/229

Generally this is a dev time message. Although depending upon your integration, it may be possible that an end user would see that message.

You could try adding a message to your theme:

[MultiTenantSSONotSupported]=n/a

In general, any user facing message can be overridden by your theme.

You can use the admin ui to build the query string.

Definitely test it out with the search first, and then use the bulk delete api.

Here's a shell script that searches for all users except one:

curl -vvv -XGET -H "Authorization: $API_KEY" 'http://localhost:9011/api/user/search/?queryString=NOT%20email:test%40example.com'

Note that I had to escape the space and the @ sign, but here's the elasticsearch query without the escaping: NOT email:test@example.com.

Also, if you are using the database search engine, the syntax will be entirely different, as this example relies on the Elasticsearch syntax.

I'd use the import users API.

Helpful links:

https://fusionauth.io/docs/v1/tech/tutorials/migrate-users https://fusionauth.io/docs/v1/tech/apis/users#import-users

what are you looking for in particular? This blog post has a node session which is used to manage the access_token:

https://fusionauth.io/blog/2020/03/10/securely-implement-oauth-in-react

Is this what you are looking for? https://fusionauth.io/docs/v1/tech/events-webhooks/events#jwt-refresh

Make sure you enable the webhook in the tenant as well as in the webhook definition.

Not with a FusionAuth policy, but you could enforce it just by checking the user during login, as twoFactorEnabled is an attribute of the user.

There's also this github issue which you may want to vote up: https://github.com/FusionAuth/fusionauth-issues/issues/763

No. A lot of our clients use Google analytics (or other similar page analytics tools) to gather those type of metrics.

This is a unique Id field per event, we do not currently persist this event for later retrieval.

If you want any persistent storage of the events, you would need to capture and store the event.