@dan Any support for wildcards? We've got a query parameter (subscription key) needed by our backend and it would be great to not touch all the redirects for this
D
Posts made by davidmw
-
RE: Restrictions on redirect URIs?posted in Q&A
-
RE: Magic Link failing for org using Mimecast and ADposted in Q&A
I just had another customer experience problems from behind a Trend Micro security solution. He was able to add our domain to an approved origin list, which seems to allow redirection to the full passwordless URL. However login is still failing and I'll note that & has been replaced by amp; in the URL in his arrived magic link email:
href=3D"https://ident.become.me/oauth2/passwordless/4a7dLluFli__SQbno3MEXeRn6vnCKP3k2QI-kt1ySxI?tenantId=3D8d22a1b9-e709-443c-8147-f8796ddec84e&client_id=3D356ad7a7-224e-4ecf-be52-414d23a00fb2&metaData.device.name=3DWindows%20Chrome&metaData.device.type=3DBROWSER&redirect_uri=3Dhttps%3A%2F%2Fapi.proxy.become.me%2Fcommon-production%2FOAuthLoginFlowHandler%2F356ad7a7-224e-4ecf-be52-414d23a00fb2&response_type=3Dcode&scope=3Doffline_access&timezone=3DAmerica%2FDenver" -
Magic Link failing for org using Mimecast and ADposted in Q&A
Users requesting magic link login or password reset are viewing the inbound email just fine but when they click on the link in email they are seeing a FusionAuth error screen complaining about missing_redirect_uri.
Immediately when clicking on the button in the FA email the browser is flashing a Mimecast URL, then redirecting to https://ident.<mydomain>/oauth2/passwordless/4YbVFuAsLZ2EKaL31dL3ACBYAmzG5q_Ark70S743a_g?tenantId=8d22a1b9-e709-443c-8147-f8796ddec84e which looks both damaged and truncated (missing redirect_uri and more).
I'm hoping we can get past this via whitelisting but I'm wondering if there are other solutions so we can play nice with Mimecast or make configuration recommendations to the client.
In case it isn't clear, these emails work fine for most of our users. We are working with a new client that has Mimecast configured on their network.
-
RE: Force Google Account Selection on every loginposted in Q&A
Thanks Dan - the manual endpoint configuration did the trick. I put the parameter on the authorization URL.
David
-
RE: Force Google Account Selection on every loginposted in Q&A
Afraid not. This isn't an issue of selecting the right IdP for the user or an issue of wanting to skip FusionAuth login screen .
Once control is passed to Google - I need to ensure that Google prompts the user for Google Account selection. I can't have Google assuming that the user wants to authenticate using the active Google Account - it needs to ask.
-
Force Google Account Selection on every loginposted in Q&A
We have users with multiple google accounts (private and school accounts, for example).
Some users will mistakenly connect on a private account, which isn't registered with us. FusionAuth automatically creates the account, but user doesn't get registered for our apps that way. So we bounce them out, returning them to our splash page.
Then they try to login again and this time they fall into our app, by-passing the Google account selection screen. The wrong Google account is still active and they get bounced. No easy way to get out of this mess, short of going to a Google site in the browser and logging out.
I'm thinking that perhaps we need to always show the Google account selection screen. For the record we aren't using the canned Google IdP but we've created two (managed and unmanaged) using OpenID. Google docs suggest that prompt=select_account can be passed on the OAuth2 authorization URL. Is there a way to specify options that should be used for each IdP? https://developers.google.com/identity/protocols/oauth2/openid-connect#prompt
-
RE: Multiple nodes sharing IP address?posted in Q&A
Okay so if we refocus on the apparent instability of the nodes - how can we check on node startup times to see if the data reported in the About UI is accurate?
-
RE: Multiple nodes sharing IP address?posted in Q&A
@dan do you have any ideas on next step to help figure out what is happening here?
-
RE: Multiple nodes sharing IP address?posted in Q&A
Ugh, somehow I wasn't watching my own thread.
Yes this is deployed on Kubernetes.
-
Multiple nodes sharing IP address?posted in Q&A
On the About screen we have indications that all our nodes are sharing the same IP address. The nodes seem to be restarting at odd times too, unrelated to system load. The start times shown here are Saturday evening and we had zero login activity until my 9:30pm login to generate the screen capture.
Is any of this expected?
-
Cloud q'sposted in General Discussion
Can you share any specific details about the basic cloud option with Sydney as the selected region?
What class / size VM is it on, which database and where is the db hosted? Basic is a single node only? Does 'cloud' create any restrictions in addition to Community edition when self hosted?
We need the custom domain. Our MAU is very low and we are pinching pennies but the basic tier is starting to look attractive.
-
RE: How to tune configurationposted in General Discussion
Hi Dan,
Running single node of 1.18.5 on Kubernetes with postgresql on the same VM. We don't see the problem very often so let me get some load testing configured.
David
-
How to tune configurationposted in General Discussion
Is there any documentation suggesting the best way to tune configuration settings?
We are getting some very long authentication response times (approaching 60 seconds) when we are hit with a several dozen login attempts within a small window.
Our status report has these interesting bits. I'm wondering if we should start by increasing the HikariPool Connections:
"prime-mvc.[/oauth2/authorize].requests": { "count": 19859, "fifteenMinuteRate": 0.005875671297513242, "fiveMinuteRate": 0.0070476817956699606, "maximum": 118.563591, "mean": 11.500318605939524, "meanRate": 0.012490419029108284, "median": 5.936341, "minimum": 1.114009, "ninetyEighthPercentile": 17.961522, "ninetyFifthPercentile": 17.961522, "ninetyNinePointNinthPercentile": 17.961522, "ninetyNinthPercentile": 17.961522, "oneMinuteRate": 0.011810555622388075, "seventyFifthPercentile": 17.961522, "standardDeviation": 5.994036255601853, "unit": "MILLIS" }, "prime-mvc.[/oauth2/callback].requests": { "count": 1417, "fifteenMinuteRate": 3.227927462601526E-4, "fiveMinuteRate": 8.17287897914934E-5, "maximum": 651.606361, "mean": 503.295733, "meanRate": 8.966385934082114E-4, "median": 503.295733, "minimum": 201.273076, "ninetyEighthPercentile": 503.295733, "ninetyFifthPercentile": 503.295733, "ninetyNinePointNinthPercentile": 503.295733, "ninetyNinthPercentile": 503.295733, "oneMinuteRate": 1.4771713901100558E-10, "seventyFifthPercentile": 503.295733, "standardDeviation": 5.3339365024206594E-36, "unit": "MILLIS" }, "prime-mvc.[/oauth2/logout].requests": { "count": 373, "fifteenMinuteRate": 4.909154955918395E-11, "fiveMinuteRate": 1.6296978413163162E-26, "maximum": 13.484992, "mean": 3.474753371153825, "meanRate": 2.34803423303815E-4, "median": 3.476825, "minimum": 1.39451, "ninetyEighthPercentile": 3.476825, "ninetyFifthPercentile": 3.476825, "ninetyNinePointNinthPercentile": 3.476825, "ninetyNinthPercentile": 3.476825, "oneMinuteRate": 5.3386313991085494E-120, "seventyFifthPercentile": 3.476825, "standardDeviation": 0.06355696818827848, "unit": "MILLIS" }, "prime-mvc.[/oauth2/passwordless].requests": { "count": 1005, "fifteenMinuteRate": 7.764998593245433E-6, "fiveMinuteRate": 1.1363578388340437E-9, "maximum": 98.271936, "mean": 27.053868, "meanRate": 6.368075801152446E-4, "median": 27.053868, "minimum": 0.159001, "ninetyEighthPercentile": 27.053868, "ninetyFifthPercentile": 27.053868, "ninetyNinePointNinthPercentile": 27.053868, "ninetyNinthPercentile": 27.053868, "oneMinuteRate": 7.67593180825067E-35, "seventyFifthPercentile": 27.053868, "standardDeviation": 1.3510365962356798E-38, "unit": "MILLIS" }, "prime-mvc.[/oauth2/redirect].requests": { "count": 1054, "fifteenMinuteRate": 3.1745750077687547E-4, "fiveMinuteRate": 7.77428296785021E-5, "maximum": 2.695219, "mean": 2.695219, "meanRate": 6.669408482311662E-4, "median": 2.695219, "minimum": 0.680205, "ninetyEighthPercentile": 2.695219, "ninetyFifthPercentile": 2.695219, "ninetyNinePointNinthPercentile": 2.695219, "ninetyNinthPercentile": 2.695219, "oneMinuteRate": 1.1504222353483872E-10, "seventyFifthPercentile": 2.695219, "standardDeviation": 1.4570802492890024E-37, "unit": "MILLIS" }, "prime-mvc.[/oauth2/token].requests": { "count": 1763, "fifteenMinuteRate": 3.2639949382991793E-4, "fiveMinuteRate": 8.44989963988031E-5, "maximum": 32.340534, "mean": 14.275601, "meanRate": 0.0011088520740279038, "median": 14.275601, "minimum": 8.287361, "ninetyEighthPercentile": 14.275601, "ninetyFifthPercentile": 14.275601, "ninetyNinePointNinthPercentile": 14.275601, "ninetyNinthPercentile": 14.275601, "oneMinuteRate": 1.7450718032937355E-10, "seventyFifthPercentile": 14.275601, "standardDeviation": 8.947911432912947E-38, "unit": "MILLIS" }, "prime-mvc.[/oauth2/userinfo].requests": { "count": 1481, "fifteenMinuteRate": 3.26399770665232E-4, "fiveMinuteRate": 8.44989963988031E-5, "maximum": 39.8489, "mean": 6.378245, "meanRate": 9.384833641716966E-4, "median": 6.378245, "minimum": 0.342103, "ninetyEighthPercentile": 6.378245, "ninetyFifthPercentile": 6.378245, "ninetyNinePointNinthPercentile": 6.378245, "ninetyNinthPercentile": 6.378245, "oneMinuteRate": 1.7450718032937355E-10, "seventyFifthPercentile": 6.378245, "standardDeviation": 5.701224265924856E-38, "unit": "MILLIS" },and
"gauges": { "HikariPool-1.pool.ActiveConnections": { "value": 0 }, "HikariPool-1.pool.IdleConnections": { "value": 10 }, "HikariPool-1.pool.MaxConnections": { "value": 10 }, "HikariPool-1.pool.MinConnections": { "value": 10 }, "HikariPool-1.pool.PendingConnections": { "value": 0 }, "HikariPool-1.pool.TotalConnections": { "value": 10 } }, "histograms": { "HikariPool-1.pool.ConnectionCreation": { "count": 67088, "maximum": 15, "mean": 5.0349683921225585, "median": 6.0, "minimum": 2, "ninetyEighthPercentile": 7.0, "ninetyFifthPercentile": 7.0, "ninetyNinePointNinthPercentile": 7.0, "ninetyNinthPercentile": 7.0, "seventyFifthPercentile": 7.0, "standardDeviation": 1.786761425473517 }, "HikariPool-1.pool.Usage": { "count": 840922, "maximum": 48, "mean": 1.583941103789779, "median": 1.0, "minimum": 0, "ninetyEighthPercentile": 8.0, "ninetyFifthPercentile": 6.0, "ninetyNinePointNinthPercentile": 8.0, "ninetyNinthPercentile": 8.0, "seventyFifthPercentile": 3.0, "standardDeviation": 1.8982617023833674 } }, -
/api/status response too big exponentsposted in Comments & Feedback
I'm taking a look at /api/status response and it should be very useful for insights into the system, error rates, configuration bottlenecks, and for scaling.
The json this generates is a real challenge to view. Postman handles it fine but tree viewers are struggling with it. One problem is due to excessively large exponents.
Example document:
"prime-mvc.[/admin/lambda/edit].requests": { "count": 10, "fifteenMinuteRate": 4.44659081257E-313, "fiveMinuteRate": 1.4821969375E-313, "maximum": 48.150635, "mean": 39.182320035497995, "meanRate": 6.46708454297529E-6, "median": 45.958017, "minimum": 23.08056, "ninetyEighthPercentile": 45.958017, "ninetyFifthPercentile": 45.958017, "ninetyNinePointNinthPercentile": 45.958017, "ninetyNinthPercentile": 45.958017, "oneMinuteRate": 2.964393875E-314, "seventyFifthPercentile": 45.958017, "standardDeviation": 8.809600064895186, "unit": "MILLIS" },Is there any value in floats computed with such precision? Maybe they could all be truncated or rounded to 4 or 5 digits?
-
RE: Logging in with a google account with the same email as a previously registered user?posted in Q&A
I wish SSO accounts could be linked to the FusionAuth account without the perfect email match requirement. If we think of the FusionAuth account as the main user containing the UserID GUID, registrations, and roles. Then add support for multiple SSO login alternatives that are connected to the main account much like an alias would be.
Currently if I create an account for a user with the provided email address (creating registrations, roles and matching account on our backend) and they connect via SSO on a different email account - FusionAuth creates a second account for them even when we have auto registration turned off. That account doesn't have the access we promised even when they can authenticate with it. To fix the problem I can't go in and fix the original account since there will now be an email address collision on the system. Requires deleting the system generated account first, then the email can be changed. This hassle trickles up into our admin screens as well since accounts are really created there and not directly in FusionAuth. When the email address update runs into a collision with an existing account we need to query FusionAuth for app registration counts - if zero it might be safe to delete the conflicting account then proceed with the renaming. But this feels unnecessarily complex.
-
RE: Can I customize the passwordless link email subject with the time the link expires?posted in Q&A
@dan FusionAuth seems to determine the user's timezone during account creation, registration, and login but doesn't update the user.timezone value with this new info.
Using the FusionAuth login screens the passwordless form calls /oauth2/passwordless?client_id=3....&timezone=Australia%2FSydney but doesn't result in an update to the user.timezone and isn't available to the email template.
Are there any good solutions to this? The user's current actual tz is probably more useful than a potentially stale or null timezone in the profile - certainly in this use case of providing an accurate expiration time for the passwordless link. I don't see an event that can alert us to passwordless requests.