Hello,

I was looking at the fusionauth.sso cookie and its value seems to be encoded, as I used the "jwt/refresh?userId" API endpoint to retrieve all currently active refresh tokens, and none of the tokens' ids matched with the value of the fusionauth.sso cookie. However, when I look at the value of the fusionauth.session cookie, it corresponds perfectly with the id of the refresh token for the FusionAuth session.

I am wondering why one of the session cookies corresponds to the id of a refresh token (fusionauth.session), whereas the other (fusionauth.sso) does not, perhaps one is encoded and the other is not? Thanks!

Hello, I was wondering if it would be possible for FusionAuth to save a user's registration information after they have logged in via LDAP?

The issue we are currently facing is that our customer's LDAP does not contain any information pertinent to a user's registration, rather, LDAP is used in this scenario for authentication only. As such, the reconcile lambda code does not modify the "registrations" attribute of the user, this field is left blank each time the user logs in via LDAP and the resulting user is created inside of FusionAuth without any registrations.

After the user account has been created inside of FusionAuth, they can be assigned roles using the UI. While these roles are saved inside of FusionAuth, it seems that the next time the user attempts to log in via LDAP, their account inside of FusionAuth gets recreated according to the reconcile lambda, as such, they have no registrations again.

Is it possible to designate the LDAP connector to perform authentication only? Or to mark a user account to not get recreated each time it uses LDAP to sign in?

I do know we can migrate the user to FusionAuth, but this will not address issues if the user's account changes within LDAP. I am also aware that there is currently an open issue to allow for the reconcile lambda to communicate with the API (https://github.com/FusionAuth/fusionauth-issues/issues/267), which would solve this issue entirely. Furthermore, it may be possible to implement our own authentication API using the generic connector, although this approach will take longer to implement.

Hello,

I am currently trying to modify the "Authorized Redirect Urls" of the FusionAuth application so that another application's post_logout_redirect_uri works as intended. Modifying the default FusionAuth application does not seem possible from the UI but it does seem possible by using the API and a PATCH command, according to documentation and this github issue: https://github.com/FusionAuth/fusionauth-issues/issues/1110.

I tried using the api call documented here: https://fusionauth.io/docs/v1/tech/apis/applications/#update-an-application, and while the response returned a 200 OK, the FusionAuth application wasn't actually updated. I then tried using the same endpoint but specified a different application, and that was updated correctly.

Does anyone know if there's any special variable I have to set inorder to enable modifications of the default FusionAuth application? I believe I am using the API correctly, since I am able to update my other Oauth 2.0 applications using PATCH, just not FusionAuth. I am also on version 1.28.1 right now. Thanks!

@pleymor yeah, it is slightly tricky, you can try decoding it here: https://www.base64decode.org/, you will get some gibberish, but the refresh token will be a substring of the decoded token. The length of the decoded token may also vary depending on your browser.

@yb98 I just figured this out, the cookie value is encoded in base 64, you can simply decode it to retrieve the actual token id.

Hello,

I was looking at the fusionauth.sso cookie and its value seems to be encoded, as I used the "jwt/refresh?userId" API endpoint to retrieve all currently active refresh tokens, and none of the tokens' ids matched with the value of the fusionauth.sso cookie. However, when I look at the value of the fusionauth.session cookie, it corresponds perfectly with the id of the refresh token for the FusionAuth session.

I am wondering why one of the session cookies corresponds to the id of a refresh token (fusionauth.session), whereas the other (fusionauth.sso) does not, perhaps one is encoded and the other is not? Thanks!

Hello,

I was wondering if it was possible for FusionAuth to provide LDAP authentication without giving FusionAuth read permissions to the directory? Ideally, a user would attempt to log in with their LDAP credentials into FusionAuth, and then FusionAuth would forward these credentials to LDAP for authentication. There would be no need to gain read access to the directory in this scenario.

It seems that the current LDAP authentication process will also pull the user data from LDAP and save them into FusionAuth, hence why read permissions for the directory are given to FusionAuth.

Thanks!

Hello, I am having an issue where I have two applications registered within FusionAuth. Both applications have an OAuth 2.0 connection set up properly, and I have included a picture of both apps' configurations at the very bottom.

The issue arises when a user logs into one of the applications using OAuth, as expected they do not need to supply their credentials when logging into the other application via OAuth. However, when a user signs out of one of the applications, they are not signed out of the other automatically (their sessions is still active and they can interact with the app). I am pretty sure that by setting the logout behaviour to "All applications", the logout endpoint of all applications should be called and the user should be effectively signed out everywhere.

I have also tested this approach, with the user logging out of FusionAuth to trigger the other apps' logout endpoints, this works as intended, this leads me to believe that my "Logout URL" is correct. Does anyone know if my understanding of the "logout behaviour" is correct? Thanks!

Thanks for the reply Dan, the final outcome I was hoping to achieve using those two settings is to Kickstart with some already existing accounts, each using the same, default password. When a user attempts to log in with one of those accounts, they will be allowed to create a new password.

Hello,

I have a use case where I am launching Grafana using Kickstart, the issue is that the accounts created by Kickstart are made with a default password, I have also set passwordChangeRequired = true for each user.

For the Tenant (also modified within Kickstart), I have specified a minimum password lifetime of 1 day. The issue arises when I launch Kickstart and try to log into an account immediately, this triggers the required password change as intended, but the minimum password lifetime causes a rejection of the change, as the password was set only moments ago, during the Kickstart phase.

Effectively, I am unable to use a FusionAuth user account until 1 day after the Kickstart has completed. Is there any solution to this issue, such as not enforcing the password minimum lifetime if the user was forced to change their password?

Thanks!

Hi,

I know that we are able to log out all idle users of an application, regardless of their role, based on the "Session timeout" parameter of the Tenant. Is it possible to instead define an idle session timeout that is based on the role of the user, rather than the tenant?

ie. I have userA and userB, both of which are registered in application A. However, userA is an admin whereas userB is an editor. Inside of application A, idle admins will get logged out in 10 minutes and idle editors will get logged out in 5. Therefore, if userA idles for 10 minutes, they will get logged out, whereas userB will get logged out in 5 minutes. Is that possible?

Thanks!