Posts made by elliotdickison

I just upgraded to FusionAuth 1.64.1 and am having a bear of a time with styles. Not quite sure where to provide this feedback so I'm just going to drop it here in the hopes that someone sees it. Given FusionAuth's current theming model (specifically wholesale forking of freemarker templates with manual upgrades based on diffs) I think the move to Tailwind was a mistake and would love to see that reversed.

My reasoning is twofold:

1. Before Tailwind was introduced I could keep my style overrides in a stylesheet separate from my freemarker templates. When it came to upgrading my freemarker templates I could easily see FusionAuth's markup changes, diff those with my templates, and work through the migration without too much pain. Styles almost never came into the picture - they just worked across numerous upgrades. Unfortunately now my upgrade process includes a lot of noise since FusionAuth's Tailwind style changes are all mixed up in the markup. This makes it difficult to pick out the important changes to the markup and logic in freemarker.

2. Tailwind itself is ill-suited for pre-built themeable templates. I can't make changes to the Tailwind classes in FusionAuth templates because the CSS is already built (e.g. I can't reference a Tailwind class unless FusionAuth used it for the default template), so I'm forced to live in an in-between world with Tailwind and vanilla CSS overrides. Additionally the overrides become quite tricky because semantic class names have been removed (nothing to hook into) and Tailwind's generated styles are quite complex (e.g. border-top/right/bottom/left all being set independently for the same border).

My 2c. I'll keep struggling along and will be fine, but I do think Tailwind is a step backwards for FusionAuth themes.

Background

I've integrated a third party OIDC IdP with FusionAuth. This IdP supports a non-standard screen_hint query param on their OAuth authorization endpoint. If the IdP receives screen_hint=register at their authorization endpoint then they will render their registration page by default instead of their sign in page.

End goal

I would like to be able to send a user to FusionAuth with both the idp_hint and screen_hint params set and have the screen_hint parameter be passed on to the IdP's authorization endpoint. This will allow me to render a "Create account" button in my app that will send the user straight to the IdP's registration page.

What I've tried

I've tried digging through FusionAuth docs, poking around our custom freemarker templates, watching the network tab, and searching through this forum but have come up short. An adjustment to our custom freemarker theme templates seemed like the best bet, but it appears the IdP authorization request is constructed on the server so no amount of tinkering with client-side logic can add a custom parameter. I also want to make sure that this parameter is compatible with idp_hint, and I'm not confident any client-side theme logic would be compatible with that since idp_hint is designed to skip the UI.

Any solutions or workarounds would be appreciated!

@mark-robustelli No worries, we do have a working setup now after a slew of theme tweaks. That said there is still an outstanding question and a possible bug (both low priority).

The question: What happened to the ability to complete an oauth authentication flow by POSTing a code to /oauth2/passwordless? That worked in 1.48.3 but not in 1.55.1.

The potential bug: Why does a GET call to /oauth2/passwordless/<invalid code> redirect the user to the browser confirmation page (even when the request is from the same browser) instead of an invalid code page?

@mark-robustelli Correct. I'm aware we're in uncharted territory and can't expect everything to work smoothly across upgrades, but TBH I don't think our solution is quite as bad as it sounds.

The form is a single input that, when a code is entered, triggers the same request that would fire if the user clicked a magic link in an email. Conceptually we are very close to the built-in flow except that we categorically exclude all of the link verifier bugs and cross-browser complications of the built-in flow.

Regarding the passwordless API, unfortunately that would mean we'd lose the FusionAuth SSO session (source) which is a key feature for us.

@mark-robustelli This is great, didn't know it existed. We were on an older version of FusionAuth that didn't support the log. Thanks!

Hi all,

We're currently on 1.48.3 and are attempting to upgrade to 1.55.1. The only sticking point for us seems to be a change to the magic links API.

Background

We use FusionAuth's built-in magic links flow with two exceptions:

1. We have a custom passwordless email template that includes the code in large text for the user to read/copy instead of embedded in a link for them to click.
2. We've updated the OAuth2 passwordless theme file to render a form where the user can enter the code manually. The form is shown after the user requests a passwordless email (in place of the "check your email" message rendered by default).

When a user enters a code in the form we send a POST request to /oauth2/passwordless containing a "code" field set to the code, a "postMethod" field set to "true", and all the standard oauth fields via the "@oauthHiddenFields" helper.

This worked perfectly in 1.48.3. A valid code would authenticate the user and redirect them back to our app. An invalid code would re-render the page with an error message.

This provides users with a nice Slack-like OTP auth flow and sidesteps all the issues with one-time links taking users to the wrong browser or getting invalided by link verifiers.

The problem

This flow doesn't work in 1.55.1. Specifically our custom form that POSTs the code to /oauth2/passwordless results in the page just reloading without authenticating the user.

In an attempt to fix the problem I updated the custom form to redirect the user to /oauth2/passwordless/<code> per this post. That does actually fix the sign in flow if the code is valid! However if the code is invalid then the user is redirected to the new confirmation page meant to protect against email client link verifiers*. When the user clicks the "Confirm" button they are redirected back to the app without an error message (and obviously without being signed in as the code was invalid).

*My guess is that this feature is the reason that the behavior of the /oauth2/passwordless endpoint changed.

We could potentially "fix" the invalid code flow by updating the theme file for the new confirmation page to redirect the user back to the passwordless page, probably with a query param indicating that an error message should be shown. Because we use manual code entry instead of links the user is forced to complete sign in where they started. The confirmation page should never be shown in this case, so updating it to redirect should be safe. This feels like a hack that we'll regret though.

The question

What changed with the /oauth2/passwordless API, and what is the best way to continue supporting Slack-like OTP sign in codes (without hacking our FusionAuth theme to bits if possible)?

Thanks!

We realized that a webhook of ours, listening to user.create.complete events, has been logging failures for some time. We can see errors in the System Event Log in the form "Webhook [<url>] returned response code [500] when sending [UserCreateComplete] event with Id [<uuid>]". The url is the endpoint listening to events and the uuid appears to be a random ID for the event.

The problem we are facing is not that the original webhook failed (we think we may know what the issue was with our endpoint), but that we have no idea which users it failed for and can't rectify the situation. The error logs don't contain any actionable information and we can't find any webhook event history in the FusionAuth dashboard or the database.

Is there any way to get the id of the user that triggered the webhook that failed? Or is there any way for us to replay a failed webhook after the 3 retries are up? Or can we configure more retries over a longer period?

@vatsal We did not

We're self-hosting FusionAuth's Docker image on the Starter plan. We'd love to pipe event logs to stdout so that our log infrastructure picks them up and sends them to Grafana without the need for us to write a custom ingester. Is this possible? Or is there a reason we shouldn't do this?

We've resolved this issue. Turns out our CDN had cached FusionAuth's redirects to /maintenance-mode-failed that were triggered during a previous db outage. We're investigating why our CDN cached these redirects as it's configured to respect the headers sent by FusionAuth.

Hi all,

We're seeing sporadic redirects to /maintenance-mode in production. Many users are able to sign in and register just fine and our admin dashboards are working, but many users are reporting an inability to login and are getting redirected to /maintenance-mode. The actual maintenance mode form is not returned (just the error text) as we are in production mode. To help us troubleshoot it would be helpful to know if redirects to /maintenance-mode can happen sporadically on a single node, or if that redirect is a game-over state that a node will return consistently until fixed.

Thanks!

A couple thoughts on pricing:

• It would be helpful if the pricing page posted the cost-per-MAU formula for each plan. The MAU slider on the pricing page gives me the exact cost for a specific number of MAUs, but if I want a general formula I have to reverse engineer it. For example with the self-hosted Starter plan I can see that the MAU fee goes up by $75 for every 10k MAU at low volumes, but at high volumes that appears to drop down to $25 for every 10k MAU (cool! but also totally unclear). This gets particularly confusing when comparing plans. For example at first I assumed that the self-hosted Essentials plan ($825/mo) would be 6.8x more expensive than the Starter plan ($125/mo). After playing with the slider though that does not appear to be the case - it's still much more expensive but not 6.8x. It's very hard to tell what the actual difference in cost would be as we scale.
• I would love to see basic security features (particularly passkeys) available in the Starter plan. The significant price jump to the Essentials plan currently puts those features out of our reach. I would expect to pay through the nose for enterprise-y things like LDAP, SAML, and priority support (and hope to be at that level someday!), but it's a bummer to lose out on what are becoming table-stakes auth features without significant price increases. It seems that there is a gap in the pricing model for the budget-conscious startup that doesn't need true enterprise features, is already self-hosting, is not putting a burden on support, and is contributing back via PRs, detailed bug reports, etc. Just a suggestion - we are happy FusionAuth customers and love the product!

We've been running FusionAuth on Fly for a couple years now. Great experience all around.

Thanks for the tips! I do love that customizing FusionAuth's theme templates allows you to accomplish pretty much anything. For our use-case - lots of custom forms for lots of tenants - I would prefer to be able to use the advanced registration form feature instead of polluting theme files with JS snippets. At that point I think I might as well hardcode the HTML for the fields instead of adding JS.

Is there any way to specify the default value for a form field, either at the field level or the form level? I can't seem to find documentation regarding this, but it would be a helpful feature for advanced registration forms.

Hi,

I'm setting up FusionAuth in a multi-node cluster and am trying to determine a good connection limit for each node. If I give each node the recommended 512MB ram, how many connections could FusionAuth handle? Or is the number of connections CPU-bound? The majority of traffic will likely be to POST /api/jwt/refresh to refresh access tokens.

Thanks!

@maciej-wisniowski We ended up going with your solution and it's working alright, thanks for that!

@robotdan One suggestion for you all: I found the naming of the "AllApplications" value for the application.oauthConfiguration.logoutBehavior setting a bit confusing. As far as I can tell all the "AllApplications" value it really means is "show the OAuth2 logout page". That page can be used to log out of all apps (that's the default template behavior), but it doesn't have to be used that way. Per the suggestion from @maciej-wisniowski we are using the page to log the user out of only one app and show a "successfully logged out" message. Maybe to avoid a breaking API change the value "OneApplication" could be added in addition to "AllApplications" and "RedirectOnly". That value could use the same OAuth 2 logout template but maybe set a variable that could be used to conditionally turn off the logout-of-all-apps behavior. Just a thought.

Hi all,

We're trying to figure out a nice logout experience for our mobile app users and we're struggling a bit.

Where we're at

We've got a mobile app setup to auth users with FusionAuth + OAuth + JWTs. When the users log in we pop open the /oauth/authorize URL in an in-app-browser which closes/redirects back to the app after login. So far so good.

For logout we send a DELETE /api/jwt/refresh request to revoke the user's refresh token and clear tokens from the local keychain.

The problem

We also want to kill the user's FusionAuth SSO session on logout, but not all application sessions. The only way we've figured out how to do this is to set the app's OAuth "Logout behavior" to "Redirect only" and then open /oauth2/logout in our in-app-browser when the user logs out. The problem is that this results in the browser popping open and then immediately closing after the session is revoked. This will look unnecessary/confusing/broken to the user.

Questions

• Are we doing something really wrong, or is this a reasonable issue to be facing?
• Is there a way to revoke the SSO session with an API call, or is the GET request essential for clearing cookies?
• If the GET request is essential, is there a way we can get FusionAuth to show some sort of "Logout successful" message before redirecting so opening the browser doesn't feel pointless from a UX perspective?

Thanks!

@joshua That actually helps very much, thanks!

We're considering upgrading for Connectors. One use-case we have is to allow our customers to maintain existing subscription/user stores while using our service, which seems like it falls squarely in the documented use-cases. Another use-case we have is a little less standard though: we'd like to allow users from one of our FusionAuth tenants to login to an application from another of our FusionAuth tenants. Would it be possible to use a connector to point FusionAuth back at itself in order to bridge tenants like this? Or is there some alternative for us to allow Company A's users to access Company B's app with their existing Company A logins (all stored in the same FusionAuth instance)?