@vatsal We did not
Posts made by elliotdickison
-
Can event logs be sent to stdout?
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?
-
RE: Sporadic redirects to /maintenance-mode in production
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.
-
Sporadic redirects to /maintenance-mode in production
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!
-
Pricing feedback
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!
-
RE: Deploying FusionAuth on fly.io
We've been running FusionAuth on Fly for a couple years now. Great experience all around.
-
RE: Specify default value for form field?
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.
-
Specify default value for form field?
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.
-
Reasonable connection limits?
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!
-
RE: Awkward OAuth logout in mobile app
@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.
-
Awkward OAuth logout in mobile app
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!
-
RE: What can I use connectors for?
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)?
-
Localization message file format
TL;DR - What is the actual language/format for the message content that can be found under Themes / Messages?
I'm creating a local file for the default messages in a custom theme that I plan to feed into kickstart. I'd like to tell my IDE what language the file is using so I can have syntax formatting (like FusionAuth's UI has), but I can't seem to figure out what it is. I poked around the markup of the CodeMirror instance in the FusionAuth UI looking for hints but came up short
Thanks!
-
RE: Http-Only Cookies w/ OAuth Authorization Grant
Ok so it sounds like once the tokens have been sent to the client via the
/oauth2/token
response body they've technically been exposed - if malicious JS was on the page it could intercept them regardless of whether I store them in non-http-only cookies or local storage. So it seems like the only option is to do the code-for-token exchange on my backend server. Then I can send the http-only cookies down the pipe myself. Can anyone validate my thinking? -
Http-Only Cookies w/ OAuth Authorization Grant
I recently setup FusionAuth and I've been loving it. I'm having trouble figuring out the best way to store my OAuth access and refresh tokens though.
Background
I've setup my client-side JavaScript app to log users in using OAuth's authorization code grant. I've turned off authentication on FusionAuth's
/oauth2/authorize
endpoint so that I can call it from my client-side app without a secret. I'm using PKCE to prevent auth code interception. When I receive an authorization code via the redirect from FusionAuth, I POST it to the/oauth2/token
endpoint to exchange it for an access and refresh token. The tokens come back as in a JSON object in the response body. So far so good.Problem
The problem is that I don't want to store the tokens in JavaScript, but that's my only option if FusionAuth sends them to me in a response body. I would rather have the tokens be send as HTTP Only cookies so that they get sent along with requests to my backend (which can validate them) but they're not vulnerable to JS on the client. Is there any way to get FusionAuth's
/oauth2/token
endpoint to pass the tokens back as cookies? And if so, is there any way to get the same endpoint to accept a refresh token via cookies (since I won't have access to it in JS and won't be able to provide it via a request parameter)?Half-baked solution
The best thing I can think of so far is to add an endpoint on my backend that will reflect the tokens back as HTTP Only cookies (I send the tokens via POST request parameters and it sends cookies back). Is that as secure as I think it is? If so that solves the issue with
/oauth2/authorize
redirect not sending cookies (although it would be nice to solve auth purely with requests between my client-side app and FusionAuth). The remaining problem is how to use my refresh token to get a new access token - the/oauth2/token
endpoint requires the refresh token be passed as a parameter, but I'll only be able to send it as a cookie. Are there any solutions to this?