We have documentation that describes how you can monitor FusionAuth.

Each of the logs that you mention has an API exposed that can be used to consume FusionAuth data into an external system.

At this time, you'll need to write scripts, using the client libraries, to scrape and ingest these logs.

If you are looking to get webhooks into a system, we have an example AWS lambda which pushes webhook events to S3.

@muhammadfatihmaulana434 Ah, if you run both services in docker, you need to use their docker hostnames if they are all in the same network (perhaps using docker-compose). Or you can use host.docker.internal to refer to the host machine, which has ports mapped to each docker image.

https://docs.docker.com/desktop/networking/ has more details.

Alternatively, run the Laravel application outside of docker.

@alickabrook1
I was not setting origin URL in mobile app.

I was setting it in fusionauth config.

Shared screenshot in https://github.com/FusionAuth/fusionauth-issues/issues/1443

Hi Martin, we updated the feature matrix here: https://fusionauth.io/pricing?step=plan&hosting=self-hosting to make it clear that application specific MFA configuration is an enterprise only feature.

Cheers!

Yes. There are two ways to accomplish this.

If you know the factor ahead of time (it is recorded in a database), then you can set it on import. Use the Import Users API. (You can also use the Create User API if you are creating one user at a time.) With the Import User API, set the factor for each user; they don't have to be the same across all users.

If you don't know the factor ahead of time, you need to create a plugin. Here's a sample plugin.

In the encrypt method, which has this signature: public String encrypt(String password, String salt, int factor), you can ignore the provided factor and use the algorithm you mention to calculate it. You are passed the plaintext password and can examine it for length, characters, etc.

Test and install the custom password hashing plugin into your FusionAuth instance as documented. (If you are running in FusionAuth Cloud, you'll need to open a support ticket with the jar file.)

When importing the user, the factor won't matter, but make sure to set the encryptionScheme to your custom password hashing plugin.

After importing, configure your tenant to rehash users' passwords on login to a more standard factor and hashing scheme. Learn more about that here.

@mark-shapiro Thanks for sharing with the community.

So, to call the user registration form, one just needs to:

Remove any calls to prefetchConfiguration() Pass every needed URL (authorize, token and logout endpoints) to a serviceConfiguration object Call the authorize() method but use the custom /oauth2/register endpoint
Here's a sample code: // Configuring FusionAuth const fusionAuthConfig = { issuer: "your.fusionauth.url", clientId: "Your application's Client Id", redirectUrl: "com.your.app://oauthredirect", scopes: ["openid", "offline_access"], serviceConfiguration: { authorizationEndpoint: "https://your.fusionauth.url/oauth2/authorize", userRegisterEndpoint: "https://your.fusionauth.url/oauth2/register", // This will be used down below tokenEndpoint: "https://your.fusionauth.url/oauth2/token", endSessionEndpoint: "https://your.fusionauth.url/oauth2/logout", }, }; // And then, in your component, replace the URL in authorizationEndpoint // with the one in userRegisterEndpoint and call authorize() const config = {...fusionAuthConfig, ...{ serviceConfiguration: { ...fusionAuthConfig.serviceConfiguration, authorizationEndpoint: fusionAuthConfig.serviceConfiguration.userRegisterEndpoint, }, }}; const authState = await authorize(config);

More detail can be found here: https://github.com/FusionAuth/fusionauth-issues/issues/2435

@erocihihape , can you please provide me the SMTP config you have used and any Additional properties you have configured for fusionauth and smtp.office365.com integration

I'm not exactly sure what the question is here. What are you trying to accomplish or looking for?

@mark-robustelli Thank you Mark..! I will keep in mind.

@joshua said in Fusion auth is creating 2 sessions when a single user logs in? Is this correct?:

Depending on how you are using FusionAuth, this is normal. One of the sessions is going to be the SSO session. And the other is going to be an Application level refresh token. There could be possibly other refresh tokens present as well, depending on your use case and integration.

Thank you for your response. However I have another question, backend is calling logout api of fusion auth by passing refresh token, now it only deletes 1 session. The other session remains and on client side user is logged in on fusion auth. Now to logout from client side I am redirecting user to fusion auth logout url to delete that remaining session. Is this intentional, if yes, then is there some other alternative?

@sandesh Thanks for sharing her on the forum. Hope you are able to accomplish your end goal with the APIs.

@dan I would love for this to be included in the themes documentation since it's something that every theme developer needs to figure out, and of course the default theme's assets (favicon etc.) are hosted locally and served by the FusionAuth server itself - so the answer that this can't be done for your own theme assets is non-obvious!

You have a few options, none of them great.

You could look at using universal links and android app links to make sure the redirect URL for both mobile and web apps has the same format. You could, on the Change Password Template, put in a message making it clear to users that if they started the change password flow on a mobile device, they should finish it on a mobile device (and same with web apps). You could, on the Change Password Template, write javascript to examine the user-agent and the redirect URL. If they are incompatible, you could redirect the user to a device-compatible change password URL (basically by rebuilding the change password link they clicked on to start the flow and then doing a window.location=... call).

We actually just launched a feature using the Vend API to do impersonation. Seems to be work well so far.

Basically just pass in a UserId with the ApplicationId you wanted to impersonate (for us), call the GetUser API, and then build a claims map from User (roles, entity grants, etc) into the right structure and pass that JWT back to the calling app to leverage.

Options:

Hints will direct a user to a specific IDP (but not forcibly - the user can still change the URL). https://fusionauth.io/docs/v1/tech/identity-providers/#hints You could look at issued token at the application level and verify the claim of authenticationType and ensure that it’s GOOGLE when the claim is user.data: admin and if not kick the user back to login with a helpful message on the way out. However, any refresh grants won't retain the initial login type: https://github.com/FusionAuth/fusionauth-issues/issues/1483 Another option might be to key off of user.login.success webhook and fail the login (send a non-200) if the user is an admin and the authenticationType is not GOOGLE: https://fusionauth.io/docs/v1/tech/events-webhooks/events/user-login-success

Webhooks will send the data documented below. What is sent will vary according to the webhook event

https://fusionauth.io/docs/v1/tech/events-webhooks/
https://fusionauth.io/docs/v1/tech/events-webhooks/events/

Cookies are usually stored in a browser, but you can send custom data to a webhook by including an eventInfo.data object:

{ //.. "eventInfo": { "data": { "myCustomData": "FooBar" } }, //... }

So you could read from a cookie and set a form value, for example on a login event.

More details here: https://github.com/FusionAuth/fusionauth-issues/issues/2263

We do not have a current mechanism to check how big the headers will be from FusionAuth. Out of the box, FusionAuth will not set more than 1024K in headers.

Therefore, if you are seeing a 502, this suggests a proxy configuration issue or another integration issue with how you have set up your infrastructure. You could try tuning your values and proxy settings (as you have suggested).

We also have a community-contributed proxy configurations that you might find helpful: https://github.com/FusionAuth/fusionauth-contrib/tree/master/Reverse Proxy Configurations

Yup, this is expected.

The data returned by the IdP may have changed, so FusionAuth will update existing links on each login and sends the event each time in case the data has changed.