Topics created by dan

You have a couple of options:

you can update webhook so it always returns 200, regardless of the message it receives. This won't work if the webhook URL is incorrect. For example, if you set up the webhook to live at https://exmple.com when it really lives at https://example.com and you don't have access to https://exmple.com. if you have an API key, you can update the webhook to be non-transactional. Setting up such an API key is a critical part of common configuration. if someone has an active session in the admin UI, they can also modify the configuration to make the webhook non-transactional.

FUSIONAUTH_APP_HTTPS_CERTIFICATE would be the variable name to use.

However, properly escaping a multi-line certificate can be tricky.

If you can write the cert out to a file, you could set FUSIONAUTH_HTTPS_CERTIFICATE_FILE instead, which doesn't have the escaping complexity.

Make sure you are running 1.47.1. If you are using docker, you might need to run docker pull to get the latest version.

There's also information in the release notes about how to modify a customized theme:

Due to the necessary change related to adding a CSRF token when performing a federated login, a manual change may be required to your themed login pages. Please read through these details to understand if you will be affected.

If you are using any 3rd party IdP configurations such as OpenID Connect, SAML v2, Google, Facebook with a custom theme, you will need to make a modification to your template in order for federated login to continue to work correctly.

If you are not using any 3rd party IdP configurations, or you are not using a custom theme, no change will be necessary.

If you will be affected by this change, please review the following details and then make the update to your theme as part of your upgrade process.
...

There is no official way to do this but you can overload one of the custom fields as outlined here.

Here's sample code to do this, assuming that the parameter you want to track is registrationCode.

<script> const queryString = window.location.search; let urlParams = new URLSearchParams(queryString); const registrationCode = urlParams.get('registrationCode'); if (registrationCode) { console.log('New query string found of '+ registrationCode); let input = document.querySelector('.customParam'); input.setAttribute('value', 'registrationCode = ' + registrationCode); console.log(input.type, input.name, input.value); } </script>

Then, in the login form, you want to make sure you have this input field:

<input class="customParam" type="hidden" name="metaData.device.description"/>

The value of metaData.device.description in the webhook event will be the value of the registrationCode parameter.

As of right now, you can grab all your users via this script:

https://github.com/FusionAuth/fusionauth-example-scripts/blob/master/full-user-search/fulluserdownload.sh

And then run this script to give you stats on the links each user has:

https://github.com/FusionAuth/fusionauth-example-scripts/blob/master/full-user-search/ssostats.sh

You may need to edit the latter script if you want to get insight into different identity providers. Look up each identity provide Id via the API or admin UI and update the if clauses to increment the appropriate variable.

Here's a more full featured implementation:

import jwt from '@tsndr/cloudflare-worker-jwt'; import dev_jwks from './jwks/dev.json'; function authenticate(handler) { return async function (request, response) { let headers = request.headers; if (!headers.has("Authorization")) { return json_error(401, "No Auth header present"); } let auth_header = headers.get("Authorization"); if (auth_header.indexOf("Bearer ") !== 0) { return json_error(403, "Bad auth header"); } let token = auth_header.slice(7); let verified = await jwt.verify(token, dev_jwks.keys[0], {algorithm: "RS256"}); if (!verified) { return json_error(403, "Bad auth token"); } try { token = jwt.decode(token); } catch (e) { return json_error(403, "Unable to decode token"); } let { header: meta, payload } = token; // TODO: inspect the payload of the jwt return await handler(request, response); }; }

where json_error is an error handler function outside the scope of this example and the JWKS file is downloaded and put into './jwks/dev.json' and the key is known to exist in the first entry in that array.

A more sophisticated version would examine the key id from the token header and find the corresponding public key in the the JWKS array.

The User Support Guide outlines actions customer support reps will need to take w/r/t customers and users managed by FusionAuth.

Unfortunately, this lambda will only fire on user registration or complete registration event, not on account page updates.

If you are looking to control how a user can update their profile, another option would be to use our events and webhooks (making them transactional - All webhooks must succeed) to do additional data processing to determine if a user update can succeed.

See the list of events here: https://fusionauth.io/docs/v1/tech/events-webhooks/events/

user.update or user.registration.update might be good events to use.

Currently FusionAuth does not provide additional logging or events for a failed 2FA login.

There are two reasons that a 2FA code would be considered invalid (assuming the code was valid at one point in time):

Expiration. You can control the duration of these codes in the Advanced tab of the edit tenant page by adjusting the external identifier duration for Two-Factor login Another code requested. A user is only allowed one active 2FA code at a time, so if there is a situation where another 2FA code is requested, the other code would be invalidated.

It'd be good to see if you can narrow down the situation where the invalid code method is received to one of those, which may help troubleshoot the root cause.

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.

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.

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).

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.

When you are month to month (MtM), it is a series of 30 day commitments, perfect for small and non production deployments that aren't needed longterm.

Contract customers typically commit for 12-36 months. For that longer commitment, FusionAuth offers discounts and a voice in product roadmap in exchange.

If, instead, customers value flexibility, they can always pay list price with no more than a 30 day obligation.