Posts made by mark.shapiro

@mark-robustelli I had opened a support ticket (via email) and got this response

If you have external calls in your integration, you will want to ensure a fast response  

Lambdas - If you are calling FusionAuth APIs in a lambda, ensure a connection over port 9012 (as opposed to port 9011).  Any other external HTTP calls (to your own endpoints) using HTTPConnect should return quickly as well to ensure optimal performance. 

Connectors - If you have a connector, then FusionAuth will hold things in flight (database connections, in-memory information, etc) while we wait for your connector to return an authentication response and log the user in.    

Ideally, your connector would have a read timeout of 1ms and a connect timeout of 2ms or less.   

Higher values mean FusionAuth will have fewer resources (database connections, etc) available to service incoming login requests (as older login requests are still in flight waiting for the Connector return). 

Webhooks -  

If you have any webhooks, these should also return quickly to optimize performance.  Any SocketTimeoutException (read or connect) in the Event Log would indicate a slower webhook integration. 

Adjust Period Tasks  

If you have any periodic tasks running against your deployment (perhaps to synchronize user data, application data, etc by calling our APIs), then you will want to write back-off logic if the system shows a heavy load (monitoring documentation). 

Turn off logging in production  

This change will be less impactful but will help nevertheless.  Logging should be used when there is an issue with SMTP/email, lambdas, connectors, users, etc but turned off in production when not needed.  Logs are output to System > Event Log.  The debug enabled toggle throughout the UI (and API) indicates whether this logging will occur.  

The big ones were that we were making calls to the API in a lambda and switched the port as mentioned. We also had left on debug logging in a lot of places so have disabled that for now. Validated our webhooks are all running pretty fast (median type is 1-2ms) and connector is pretty fast, though slower 20-30ms median.

@mark-robustelli I verified with the domain name itself.

nslookup login.mycompany.com

Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
login.mycompany.com       canonical name = mycompany-prod.fusionauth.io.

So should confirm we're using hosted (and had been what I thought).

@mark-robustelli It's not today critical, though I logged into the console and I don't have a support option (I might have to bug our admin to go that route).

Though I also see Essentials is under Self-Hosted, so now I'm questioning life. I'll have to check with our DevOps team as well. So will do that (Monday) if there's there anything to look at on our side, let me know.

We've been seeing this error pop up and cause some failures to our API calls recently. We're on an Essentials Hosted plan currently on v1.46.0.

2023-10-20 08:07:06.942 PM ERROR io.fusionauth.api.service.system.DefaultAsyncTaskManager - An exception occurred while managing an async task.
org.apache.ibatis.exceptions.PersistenceException: 
### Error querying database.  Cause: java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 2000ms.
### The error may exist in io/fusionauth/api/domain/LockMapper.java (best guess)
### The error may involve io.fusionauth.api.domain.LockMapper.lock
### The error occurred while executing a query
### Cause: java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 2000ms.
	at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:30)

I saw this related issue and mentioned about IOPS limit, but I haven't seen that metric anywhere. Is this something about how we're using FusionAuth or just a system issue? We've been ramping up more users onto the system recently, along with API calls so not sure if it's something we're doing, but wanted to make sure this doesn't become a larger issue as we continue to scale.

Found it for reference https://github.com/FusionAuth/fusionauth-issues/issues/615

Think I may have gotten this sorted out (closed the other post I found on this)

1. use /api/passwordless/start to get a code
   -- Send Code externally --
2. call /api/passwordless/login after user enters code to get JWT
   -- Do stuff in app --

seems like it should work

Basically I want the functionality of using MFA with SMS, but not actually have them enter a password. Steps would look like:

1. User enters Username
2. They are texted a code
3. They enter code on new page
4. Get a JWT and enter the application.

We would build the UI for this but trying to figure out which APIs would be involved.
This exists, but it requires a password on the request. I think I need to make a call that generates a changePasswordId request, is that the Start Reset Flow and then I pass that to the above generation?

As mentioned, we can handle:

1. Capture the username
2. Do things to generate a code
3. Send code via SMS on our end
4. Capture the code (as entered by the user)
5. Make a Login call back to FA for token
6. Use app

I'm just not 100% which to use on step 2.

@dan Yah this is for Cloud hosted (unfortunately?) sounds like we'll just need to stick with the existing auth/security options for now then.

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.

In reading https://fusionauth.io/docs/v1/tech/events-webhooks/securing it mentions locking down your webhook via various firewall settings to only allow requests coming from a FusionAuth IP address.

Where can I find that CIDR range(s) to implement? How often do those values change?