@tschlegel

Yes, there's currently no support for using a certificate.

Here's an open tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/3083

Please comment and/or upvote this with any other details that would help the product team prioritize this.

Thanks for taking the time to chat with me.

I'm sharing the feedback internally, but for future folks there were multiple issues.

• The theme was built on tweaks to the standard UI, and was moving from pre 1.62 to post 1.62. Due to the massive changes in the default theme, this was problematic.
• The way the tailwind CSS is set up and built, it's more difficult to override the default styles wholesale now.
• Additionally, it is hard to create CSS selectors to target just certain elements.

@elliotdickison please keep me honest and let me know if I missed something.

@elliotdickison I'd probably try with two Identity Providers configurations in FusionAuth both pointing to the same remote IDP.

One can have screen_hint=abc on the authorization URL and the other can have screen_hint=def, but both will have all the other parameters the same.

Then you can use an idp_hint on your create or login buttons.

I think that will work, but please let us know.

@elliotdickison Thanks for the feedback.

I'd love to chat a bit more to understand the problem.

Will send you an email.

Because advanced themes are so customizable, they can be hard to upgrade. Here's some ways to make it easier.

• When you create a new theme, start from the default version. Commit it to git before you change anything.
• Use the FusionAuth CLI to download/upload your theme during development and CI/CD.
• When a new theme comes out, clone or pull the latest from the theme history repo.
• Run this command to see what has changed: git format-patch 1.61.0..1.64.1 --stdout > update-themes.patch (this shows the changes between 1.61.0 and 1.64.1; adjust as needed for your installed version and the target version).
• Go to your theme git repo and apply the changes: git am --3way update-themes.patch which will attempt to automatically merge the changes. If there are conflicts, you can resolve them manually and then run git am --continue.

You can also use a 3 way diffing tool like diff3 or kdiff3 to visualize the changes.

These upgrade notes also provide detailed human friendly instructions on the changes.

I am using advanced themes and wanted to know how to find out what had changed in the themed pages when a new release happens.

I've read the instructions here.

There are a couple different scenarios where a login record could have a blank application Id. Usually it is #1 or #2. It occurs in scenarios where the user can have a JWT/access token that does not have the application Id in it.

1. If a user is not registered for the Application they are logging into
2. FusionAuth makes a login record when a user is created since FA makes a JWT upon user creation
3. If you use the Login API, you can log in without an App ID because you don't have to provide an application on the API call.

We have a user who has logged in repeatedly, but the application is blank.

https://fusionauth.io/docs/apis/login#search-login-records doesn't mention anything about this.

What gives?

I think the way I'd approach this is:

• import all users into FusionAuth

At cutover time:

• look at local database to see which password hashes had changed
• pull the user data from FusionAuth for each of these users
• delete the user
• re-import the user with the new password hash and the FusionAuth data, maintaining the same userId (if you provide the UUID, we'll use that)

I get that is an additional complexity, but hopefully that helps.