@john-spellman can you tell us a little more about your set up and situation? Was it working before? What changed? Can the one user still log into prod? The more detail you give the easier it will be for someone to help. Please do not post any passwords or secrets.

@laurent-bartet awesome! So it sounds like you had things set up right, you just were not logged out, so when you went back the reconcile event never took place cause you were already logged in. Is that right?

@arnel-terblanche Can you tell us a little more about your setup? Is this a first time install? Was it working before? Is this a docker image you are trying to run? Please provide more details.

@mark-robustelli

Hello, sorry for away from this topic for a week due to my other ad hoc job,

I've already solved this topic, it's not about setting on Fusionauth or google credential.

but it's because I used google's client id on Fusionauth callback and
after you told me to set applicationId in my Fusionauth admin then I used ApplicationId on google oauth's callback.

that's why it kept return me client id is invalid.

it was right under my nose, but I couldn't see it.

Thank you for reply me, that's very helpful, It would take more time if you didn't help me.

@joseantonio When you add the response_type=code. That should be literal 'response_type=code' not response_type={code} where {code} is some secret. Other than that, you can add additional parameters to the query string if needed. As long as you are not passing secrets in the query string you should be ok.

@cybermark0707 That is a bit of a loaded question. If you have something more specific in mind, please let me know but the following should be a good start.

Overall:
Getting Started

If you are a developer and want to get hands on with an example, check out:
Quickstarts

@hamza-chouaibi said in FusionAuth setting wrong domain the the cookie io games:

I am using custom local domains.

https://auth.domain.test <= FusionAuth
https://app.domain.test <= Angular app

I also tried FusionAuth at https://auth.app.domain.test but I still get the same issue and chrome block the cookie.

I am getting issue with cookies, the domain on cookies is test.

Example: app.at_exp=1742980022; Domain=test; Max-Age=3599; Path=/; SameSite=Lax; Secure

Any idea why we endup wuth Domain=test ?

The SameSite=Lax attribute restricts the cookie from being sent with cross-site requests. If your application is making requests across subdomains, you may need to adjust this setting to SameSite=None; Secure for cross-origin requests.

Existing Role Limitations in FusionAuth FusionAuth provides predefined Admin UI roles, which are not modifiable. You can review the available roles here:
FusionAuth Admin UI Roles The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available. Requesting Read-Only Roles as a Feature FusionAuth does not currently support read-only access roles for applications or tenants. The likely reason for this is that users who need to view application/tenant properties often also need to update them. However, you can submit a feature request to suggest adding read-only roles:
Submit a Feature Request Workaround: Implement a Custom Read-Only View

If immediate read-only access is required, consider:

Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data. Relevant APIs for this purpose: Application API Tenant API

Summary

No built-in read-only roles exist for applications or tenants. FusionAuth Admin UI roles are not modifiable. You can request read-only roles as a feature via GitHub. A workaround is to build a custom, API-based read-only view.

@yuriy-barvenko Ok, I'm in the same boat, but I think it is most likely the database back-end. Reason being, I migrated our database from the docker instance to a stand alone instance of PostgreSQL and I immediately noticed some performance degradation.

I'm running version 1.55.1 of FusionAuth and PostgreSQL version 14. There are documented performance improvements in both FusionAuth and PostgreSQL. I'll be updating my version of PostgreSQL and will report back.

@dev I am not sure you can set that level of debugging in FusionAuth. You can change logging in the AdminUI for various things like Lambdas, CORS filter, and that sort of thing.

@mark-robustelli Before I move to this activity, I wanted to share an observation that I made just now

So turns out that the error that I posted doesn't turn up every time I open up one of those pages

It occurs when I open those pages consecutively and the CPU spikes to the "requests" range

So to give you an example:

Click on Users -> Takes around 20s to load -> CPU Spike observed but within request range -> No error in container logs

Click on Users -> Immediately click on Reports/Login -> Move to Reports/Registration -> CPU spikes above request range -> Error in Container logs

So could this be a performance tuning issue?

As for your query about the config

Users: 7061
Applications: 6700
Tenants: 8200

Fusionauth is running on GKE on an n2d-standard-8 (8 vCPU, 32 GB RAM) nodepool, I've already mentioned the resources allocated to the deployment via the helmchart in the original thread message^

@mark-robustelli

It's possible, I didn't really keep track of that per se

We eventually moved on from this version and jumped to 1.40.x and surprisingly there were no issues in that version so this post can be closed

That being said, I did face a similar issue in a newer version for which I might post another thread

Hello @cristian
I am kind if facing the same issue here, how did you go about solving it?

@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?

@aditya-badayalya glad you got it working.

@maciej-wisniowski Looks like you are getting some traction on the issue. Thanks for taking the time to work through this and submit the issue to make FusionAuth better.

1. User Linking Issues Between SP & IdP-Initiated Logins

No, this behavior is not expected—you should not need to drop and re-link users every time they switch login methods.

Troubleshooting Steps:

Are these configured as two separate Identity Providers in FusionAuth? If so, ensure they are both linked to the same FusionAuth user. If they are separate, FusionAuth may be treating them as different authentication sources, causing conflicts. Is Azure using the same application for both login flows? If different applications are used in Azure, they may be sending different user identifiers to FusionAuth. Enable Debug Logging in FusionAuth: Go to System > Event Log and enable Debug Mode in the Identity Provider settings. Compare the SAML attributes (claims) being sent in SP vs. IdP-initiated logins. If they differ, you may need to adjust Azure’s claim mappings to ensure consistency.

2. Ensuring Correct Redirect URL in IdP-Initiated Flow

Yes, RelayState works in FusionAuth, but there are specific requirements:

Check Your FusionAuth Version

RelayState support was added in FusionAuth 1.41.0+. If you are on an older version, FusionAuth will default to the first redirect URL in the list.

Correct RelayState Configuration

Ensure the target redirect URL is listed as an "Authorized Redirect URL" in the FusionAuth application settings. URL-encode the redirect URL before appending it to RelayState. Example: https://example.com/welcome → https%3A%2F%2Fexample.com%2Fwelcome Append the encoded URL to the ACS URL in Azure.

Example ACS URL with RelayState:

https://your-fusionauth-instance/samlv2/acs?RelayState=https%3A%2F%2Fexample.com%2Fwelcome Test by logging in via IdP-initiated flow and checking if FusionAuth respects the RelayState.

Additional References:

SAML Redirects in FusionAuth IdP-Initiated SAML Login

Summary:

User linking issues are likely caused by different SAML claims or separate Identity Provider configurations in FusionAuth. Enable debugging to check for mismatched attributes. RelayState should work in IdP-initiated logins if you are on FusionAuth 1.41.0+, URL-encode the redirect URL, and ensure it is allowed in the application's settings.

This behavior is due to FusionAuth’s default settings for email templates. The Magic Link URL is template-driven, and by default, it may reference a local development environment unless explicitly configured.

How to Fix This:

Customize the Magic Link URL in Email Templates

FusionAuth allows you to update the email template directly. You may want to use the FusionAuth CLI and version control to manage email templates. Refer to the note in this documentation for details:
Email Templates & Replacement Variables

Update the Tenant Configuration

If you want to avoid changes to the email templates, you can put the link in the tenant object and have your template pull from there. To ensure Magic Links point to the correct domain (auth.example.com), update your tenant’s data object using the Tenant API:
Update a Tenant API This API allows you to populate the tenant.data object. Then you can use it in your email templates.

Summary

Magic Links use email templates, which may default to localhost:9011. Updating tenant settings allows you to set the correct domain dynamically. Use the Tenant API to configure the Magic Link domain properly.

There is no direct way to determine from the user object whether a password has been set.

1. Tracking Login Method (But Not Password Status)

You can determine how a user logged in by using the authentication_type field in the user.login.success webhook event. This will tell you if they authenticated via Google, Password, or another IdP, but it does not indicate whether a password exists. Webhook Reference: User Login Success Event

2. Allowing Users to Set or Update a Password

If you want IdP users to be able to set a password, you can enable the User Self-Service Form in FusionAuth.

How to Enable Self-Service Password Management:

Navigate to: Application > Registration > Form Settings > User Self Service The default self-service form includes a password field, but you can customize it or create a new form under Customizations > Forms. Once enabled, users can access their account management page to update their password. The Account URL can be found by "Viewing" the FusionAuth Application in the UI.

FusionAuth Account Management

Summary

FusionAuth does not provide a direct flag to check if a user has a password. You can track login methods via webhooks but not password existence. The best approach is to enable self-service password management, allowing users to set a password themselves.

Your request body looks correct for a basic search by email and should return a result if a user with that exact email address exists in your system.

1. Ensure You Are Using POST (or Use GET with Query Parameters)

The /api/user/search endpoint supports both POST and GET, but they expect different input formats.

If using GET, you must provide query parameters, such as:

GET /api/user/search?ids=<user_id>

2. Searching for Partial Matches

If you want to find all users with a certain email domain, try using a wildcard search:

{ "search": { "queryString": "*@email.com" } }

3. Verify API Key Permissions

If you still get empty results, ensure that:

Your API key has sufficient permissions to query user data. The user records exist in the database.

4. Further Reading on User Search

For more details on how to construct search queries, refer to:

Elasticsearch Search in FusionAuth User Search with Elasticsearch