Without understanding your setup completely, is the callback happening in a server-to-server call? If so, localhost doesn't work.

For example when I wanna call the elastic search container from fusion auth, I cannot call it as http://localhost:9200. For instance if the setup is

fusionauth-search: image: docker.elastic.co/elasticsearch/elasticsearch:8.5.0 container_name: fusionauth-search environment: cluster.name: fusionauth networks: - data-layer restart: unless-stopped ports: - '9011:9011'

I will need to call it via http://fusionauth-search:9200. You can also see such a setup in Fusion Auth's documentation on setting up Fusion Auth in docker-compose at https://fusionauth.io/docs/v1/tech/installation-guide/docker. You notice that the URLs will refer to the container names.

I hope this helps.

Hiya @chris-2,

So you'd like to have the claim that is not linked be set if present in the response? Would that solve your problem? Or is there some other solution that would solve your needs?

The reason we don't allow those claims to be changed in the lambda is that it's an escalation possibility.

One option (for a subset of your use cases) would be to store the value that is delivered from the identity provider in the user.data.email claim which is used for email specific functionality when no email address is available on the user.

Hiya @bhavin-panchal !

I'm not sure I understand your question.

Can you rephrase it?

Thanks.

@billyudi We are working on a update to the upgrade guide which will discuss how to map the new theme files and changes.

You can follow along with it here:

https://github.com/FusionAuth/fusionauth-site/pull/2166

I get your larger question though, which is, if I customize my theme, and then I upgrade from 1.45 to 1.46 and 1.46 introduces a new themed page, what does that new themed page look like?

Have you tried testing this out?

@ctorres Awesome, thanks for sharing your process!

Hiya @egli !

Thanks for posting it on GitHub issues. Please share the link so others discovering this issue can upvote it or see the progress on it.

Currently there's no way to limit the inputs on the default select box.

Two options.

Since you are using a custom form, you could create your own select list with just the languages you want to support.

Store this to a different value (user.data.custom_preferred_languages). You could then set up a user.create.complete webhook to copy the value of user.data.custom_preferred_languages to user.preferredLanguages`. That way this language will be used in the future. (The initial email won't have that info, however).

Another option would be to have a javascript function that would run whenever the user.preferredLanguage select box is displayed, and would trim the values down to what you desire.

I realize this isn't the smoothest, but it should get you the control you want.

@alex-2 Hmmm, curious.

What is the redirect URI or redirect URIs of the application configuration?

Is there any additional debug information when you run this in the iOS simulator?

Where are you running FusionAuth? Is the SSL certificate self-signed?

Are you using a webview? That's not typically recommended, as using safari (ASWebAuthenticationSession, to be precise) is the better path. One possible solution would be to use AppAuth, an iOS library, and see if the issue is present there.

Hiya @anirudh-vekariya!

There is no way to do this.

Since tenants are designed to be logically separate, FusionAuth has no concept of a user that spans tenants. I would not expect this to be something to be built into FusionAuth because of that.

Hope this helps.

@bradley-kite said in OIDC and Azure AD Groups:

Is there a way I can get an access token from within the Lambda?

👋 hiya @bradley-kite !

I haven't tested this, but there should be a refresh token stored in the identity provider link (since you are using OIDC). If you can retrieve that, you should be able to get a new access token, and then present that to azure ad.

https://fusionauth.io/docs/v1/tech/apis/identity-providers/links#retrieve-a-link

Look for identityProviderLink.token.

@egli This is not currently possible, but will be released in 1.47: https://github.com/FusionAuth/fusionauth-issues/issues/1738

@matthieu , that is understandable. Keep in mind if you are adding a lot of products often, you can use the APIs to help create and manage those permissions.

I.E. Create an Application Role, Create an Entity, Update a User Registration (for updating roles)

Managed domains are only available with the SAML and OIDC providers, not other kinds of identity providers (like Apple, etc)

If you are interested in which features of FusionAuth are premium, please see FusionAuth Premium Features.

You can achieve it by configuring an IdP with a managed domain.

For example, you can configure an OpenID Connect IdP (it doesn't have to have real values) and configure a managed domain for something that won't match anything practical such as no-match-domain.com. If this IdP is enabled it will cause FusionAuth to ask for the email separate from the email address.

*This will only work for SAML and OIDC Idps, not other kinds like Apple, etc. as managed domains are not supported.

Depending upon your use case, there are a few ways to get at that data.

You can use a JWT Populate lambda to add additional claims to the JWT from values stored inside user.data. You can then access these claims in the JWT after you validated it decode it yourself. Or, if you use the FusionAuth UserInfo endpoint, we will return the claims in a JSON response after we validate the token.

*Keep in the JWT Populate lamda you can add whateve you want. Any custom claims added to the JWT will then be returned by the UserInfo endpoint. In most cases it is better to keep the JWT small.

You can use the OAuth2 access token (JWT) to retrieve the user with the User API. This will return the entire user object include anything stored in user.data. This is done by making a GET request to the User API and providing the token in the Authorization header Authorization: Bearer <encoded JWT>

Make sure you these 4 headers in your proxy

Forwarded-Proto: typically this will be https. This ensures any redirects are sent with the appropriate scheme. Forwarded-Host: The original host requested by the client in the Host HTTP request header. Forwarded-For: The originating IP address of the client. Forwarded-Server: The hostname of the proxy server.

@eric-vigiani please open a support ticket: https://account.fusionauth.io/account/support/

One option would be to use Events & Webhooks. Depeneding on what you want to track, you may be interested in the following events:
-[user.registration.create]
-[user.registration.complete]
-[user.registration.verified]

You could also enable the email verification gate. Then you could call your tracking event on this themed page which would only be fired when the user exits the Email Verification gate as the result of completing their email verification during registration.

Another option may be to add an UTM code to the redirect_uri used for self-service registration and consume that in your application as the result of a user completing registration.

It depends on how you setup the database. FusionAuth only needs compute nodes (easy to have in multiple regions) and a postgresql or mysql database (which supports foreign keys, so things like planetscale are out). If you set up an active-active db, it should work. Be sure to load test it and validate.

Yes, if you have API access. Please find the documentation here: Passwordless APIs

The process would go like this:

Call Start /api/passwordless/start, capture the code code. Call Login /api/passwordless/login with code Get a JWT and do with it what you normally would

For a Two Factor setup you would:

Call Start /api/two-factor/start consume code Call Login /api/two-factor/login with code Get a JWT

If the end user never needs to log themselves in, you may also consider:

Assign a random application password to a user. Use that known password to call the Login API Get a JWT! Optionally remove the application password if you want it to be a one time use password.

This does have the issue of not creating an SSO session for the user, but that may not be a problem. (If someone logs in this way, and then goes to another application which has a login page managed by the 'hosted login pages' of FusionAuth, they won't be automatically logged in.)

This should work, though this is not a common config.

Here are the suggested startup and liveness probes which worked for a community member:

I have configured the startup and liveness probes as follows, and they are working well: Startup probe http /api/status periodSeconds: 2s initialDelaySeconds: 0s timeoutSeconds: 1s failureThreshold: 10 Liveness probe http /api/status periodSeconds: 10s initialDelaySeconds: 0s timeoutSeconds: 1s failureThreshold: 3

More details and discussion on the GH issue: https://github.com/FusionAuth/fusionauth-issues/issues/1980