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.

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.

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.

If a user is not registered for the Application they are logging into FusionAuth makes a login record when a user is created since FA makes a JWT upon user creation 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.

@batmysta Going to link to this issue.

@batmysta I know this is a bit of a "trick" answer, but the reality is the right answer depends on what exactly you want the user to have access for. I understand that the roles in FusionAuth may give more access than you may like (I.E. MFA is a tenant level settings, but there is no role just for MFA edit.), but there are some other options.

Again, depending on what you want to do and what version you are running, there is the idea of the Tenant Manager applicaiton. This will still not help you with MFA settings thought.

The other option is using the APIs. Since everything in The FusionAuth admin UI is API first, you could create your own application that would allow users you choose to edit them.

Hope this is useful.

It's so easy to mix up those IDs when you're moving between FusionAuth and the Google console! It’s definitely one of those things that’s right under your nose but impossible to see until someone points it out. Glad to hear you got the callback working - that 'invalid_client' error can be a real headache when everything else looks correct.

I've found that setting the mobile number as the loginId is the most reliable way to handle this right now. You can just tweak the theme labels to say 'Mobile Number' instead of 'Username' so it's clear to the users. It’s a bit of a manual setup for the SMS verification part via the API, but it gets the job done without waiting for a native feature update.

@mark-robustelli cheers, that was a useful post. The IAMShowcase tools did help me filter out what was correct and what was not. Eventually I found that the compression config settings on the passed request were not correct.

Managing users in bulk can definitely be a bit nerve-wracking when you're doing it for the first time.
If you’re looking for a quick way to handle this, the FusionAuth Search API is probably your best friend here. You can run a query to get the IDs of the users you want to target, and then loop through them with a simple script using the Delete User API.
If you just want to "deactivate" them instead of a hard delete, you can toggle the active flag to false in the User object. This is usually a safer bet if you think you might need to reactivate them later without losing all their historical data or linked identities. Just a heads-up: make sure you have a good backup of your database before running any bulk scripts—it's saved my skin more than once!

Webhook errors can be a real pain to debug since they often fail silently or with very generic messages. I’ve found that most of the time it comes down to either a TLS/SSL handshake issue or the endpoint expecting a specific header that FusionAuth isn't sending.
One thing that really helps is using a tool like Webhook.site or RequestBin just to see if the event is actually firing and what the payload looks like. If it works there but not on your server, it’s almost certainly a firewall or certificate trust issue on your end. Also, double-check that your secret is matching up perfectly - it’s easy for a stray whitespace to throw the whole signature validation off!

I ran into a similar issue recently while trying to upgrade my stack. It seems like FusionAuth is generally pretty stable on the LTS versions, but things can get a bit 'interesting' if you're jumping to the absolute latest bleeding-edge Node release before they've officially validated it.
I've found that sticking to the even-numbered LTS releases usually saves a lot of headache with the client libraries. Are you seeing specific crash logs, or is it just a dependency resolution error during the build?

@mark-robustelli I just upgraded to 1.64, still happens, exact same behavior

@hvfa Apologies for being a bit AWOL. I hope for things to slow down and be able to take a look at this a little more closely next week.