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.

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

@johnmiller I'm not 100% sure but that may be by design. You don't want to give away too much information. If it returned a specific error code, then you would know if the user exists or not.

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.

@aponski said in How to get JWT token in Angular app:

Hi, in my Angular application I need to get auth user JWT token to use it in authorization header when sending request to Hasura graphQL server. I don't have that option to access JWT token in @fusionauth/angular-sdk. I see that token is stored in "app.at" cookie but it is httponly cookie so I don't have access to it with javascript.

What you’re running into isn’t a limitation of Angular—it’s an intentional security design of FusionAuth Angular SDK and modern auth flows. You’re not supposed to read the JWT from an HttpOnly cookie in the browser. That’s exactly what HttpOnly is meant to prevent.

@mark-robustelli you can stop thinking.. We decided to give up on sub-tenants and manage it all via applications now for a single tenant.

I’ve been looking into similar passwordless setups for a few projects lately, and it's always a bit of a juggle getting everything to talk to WordPress correctly without breaking the user experience. This definitely helps clear up a few of the steps I was stuck on.

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!