Solution:

https://github.com/FusionAuth/go-client/issues/48

We have the exact same issue. If this was solved (hopefully) could you please provide a brief description on the fix?
Thanks!

@fred-fred said in Custom theme deployment between environments:

It looks like we can transport with the API using Theme Update Endpoints and sharing environment API keys so one environment can see the next environment to copy the themes over.

Yes, that's what I'd recommend. You could have different API keys for each environment and have the script that promotes the theme pull the API key from a secrets store. Make sure you limit the API key to the themes endpoint.

You also might be interested in this post: https://fusionauth.io/community/forum/topic/1306/parameterizing-themes which indicates how you can have the same theme files point to different resources in staging/prod/dev/etc.

Yes, you can disable one or more applications.

This operation can be reversed, and while an application is disabled, login requests to fail with a 400 error for all users.

Navigate to "Applications -> Deactivate (gray button)" to disable/deactivate an application.

To re-enable it from the admin UI, you'll need to 'view inactive', which is the button next to the green '+' sign on the list applications page.

@dan This was delivered in 1.27.0

Yes, it's the fusionauth application id, defined here: https://github.com/FusionAuth/fusionauth-java-client/blob/master/src/main/java/io/fusionauth/domain/Application.java

You should be able to go the user's tab and then expand the 'advanced' section and select a given application.

See this screenshot:

user search with 'advanced' section expanded

Ah, yes, thanks for explaining.

Yes

You have two options

use the API to integrate with the current login/reg flow with FusionAuth. This lets you keep your existing html pretty much untouched, you're just calling out to FusionAuth instead of the database. remove them and use the FusionAuth provided pages with OIDC. This lets you use the theming and localization capabilities of FusionAuth, including super simple social signon.

It's your choice based on what your needs are, either way will work.

I'd only recommend using SAML if you have an application which only supports SAML, not OIDC.

You'll also want to make sure that when someone registers with one of your applications in FusionAuth, they register with all three. I'd probably use a webhook to ensure that.

Not with a FusionAuth policy, but you could enforce it just by checking the user during login, as twoFactorEnabled is an attribute of the user.

There's also this github issue which you may want to vote up: https://github.com/FusionAuth/fusionauth-issues/issues/763

@fred-fred

Hiya,

In addition to what @maciej-wisniowski suggested, if you have a paid license you can now have application specific themes (one theme per application; if no application theme is specified, it defaults to the tenant).

You can see how that works in the sandbox environment (sandbox.fusionauth.io). I believe that feature landed in 1.27.0.

You can buy a licensed edition here.