Providing Empty Strings for Text Templates:
While it is technically possible to provide empty strings for the text version of the templates, this is not recommended. FusionAuth sends both the text and HTML versions of the email, with each MIME encoded. The email client decides which version to render. If a user’s email client renders the text version, the email will appear blank if the text template is empty.
Recommendation:
Create a simple text version of the email by stripping out the HTML formatting (e.g., removing <p></p>, <a></a>, etc.). You can refer to FusionAuth's default email templates for examples of how to format text-only emails. Criteria for Sending Text vs. HTML Emails:
The choice of rendering text or HTML emails is determined by the recipient's email client. Most modern email clients prioritize HTML, but some may fall back to text if they do not support HTML or if the user has configured their preferences for plain text emails. Forcing HTML Emails:
FusionAuth does not provide a way to force emails to always render in HTML, as the decision ultimately lies with the recipient’s email client. However, providing well-constructed HTML templates ensures that most users will receive the intended design, as HTML rendering is the default behavior for the majority of email clients.

By creating both text and HTML versions of your templates, you ensure compatibility with all email clients while maintaining your preferred HTML formatting for most users.

The best way to see this is to visit the theme history github repo.

It is mentioned in the theme upgrade documentation.

I was able to do this by:

copying the advanced theme editing it navigating to the Helpers file inside that, going to the head freemarker macro

I removed these lines:

<link rel="stylesheet" href="/css/font-awesome-4.7.0.min.css"/> <link rel="stylesheet" href="/css/fusionauth-style.css?version=${version}"/> [#-- Theme Stylesheet, only Authorize defines this boolean. Using the ?no_esc on the stylesheet to allow selectors that contain a > symbols. Once insde of a style tag we are safe and the stylesheet is validated not to contain an end style tag --] [#if !(bypassTheme!false)] <style> ${theme.stylesheet()?no_esc} </style> [/#if]

If you want to use the CSS field in the theme to store your CSs, leave in

[#if !(bypassTheme!false)] <style> ${theme.stylesheet()?no_esc} </style> [/#if]

which pulls in the CSS associated with the theme. Doing so allows you to add all your custom CSS to the CSS field in the theme and have it automatically included. If you don't do this, make sure you add your CSS to this macro (either directly or via a link). You'll want to make sure you keep it in as you upgrade.

Removing all the CSS will result in a page that looks like the one below.

unstyled login page

@dan Thank you for the prompt response I will give this a try soon.

@billyudi We are working on a update to the upgrade guide which will discuss how to map the new theme files and changes.

You can follow along with it here:

https://github.com/FusionAuth/fusionauth-site/pull/2166

I get your larger question though, which is, if I customize my theme, and then I upgrade from 1.45 to 1.46 and 1.46 introduces a new themed page, what does that new themed page look like?

Have you tried testing this out?

@fusionauth007 yo! I filed a Github report on this, check out Trim whitespace from user input on backend (username/emails) #1779

I’ve detailed a workaround we’ve got running in prod 👍

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

The best way to do this is to put a value on the tenant.data object. From there you can access it in each theme.

So, for the tenant in the dev environment, set tenant.data.assethost to dev.example.com. For the prod environment, set tenant.data.assethost to dev.example.com.

Then, in your theme, you'd have something like this:

<link rel="stylesheet" href="${tenant.data.assethost}/styles.css"/>

The reason to use the tenant object is that it is available on every theme template.

This does mean that your tenant configuration will differ slightly between environments. You can also replicate this field value between tenants if you are using multiple tenants.

We don’t currently resolve any environment variables in the themes, or anything other than what is documented here: https://fusionauth.io/docs/v1/tech/themes/template-variables/

But you can set variables in the Helpers template using assign that can be used in other templates. You could use a templating language like jinja to build the Helpers template at build time and then a script to load it during deploy. (Or even sed.)

You can also create different themes (a dev theme, a qa theme) and assign them via scripts to the different environments (unsure if you are using different tenants to represent environments or different FusionAuth instances, but the concept is the same).

The only two grants that are relevant to an interactive flow are the authorization grant, and the implicit grant.

I don’t recommend you use the implicit grant at all, so that leaves only the authorization grant.

If the authorization grant is happening, response_type will be code.

If the authorization grant is occurring due to a device grant, the user_code variable will be set.

@dan This was delivered in 1.27.0

You can put whatever you want in the theme pages, but it's a good idea to keep them lean so the user has a quick login experience. After all, most folks don't care about auth except when it doesn't work!

You can optionally pass info in the state parameter, that will come back to the caller. This can be encoded JSON, as long as it is url safe. You will want to make sure that you don't put too much stuff in there, as there are URL length limits for browsers (though I learned that chrome has a URL size limit of 2MB!). Here's an example of using the state parameter for application state.

Or if you have different applications and redirect URLs, then just gathering metrics on the URLs may give you insight into who is using login, and from where.

Sort of depends upon what type of analytics you need.

This link is probably what you are looking for:

https://fusionauth.io/docs/v1/tech/themes/#handling-failures

In order to use a custom font within a publicly accessible FusionAuth template for a hosted deployment, pull the font from a CDN or other server hosting the font.

FusionAuth doesn't have any persistent storage for custom theme assets. You can use any font you like as long as it can be included via a tag.

@dan I would love for this to be included in the themes documentation since it's something that every theme developer needs to figure out, and of course the default theme's assets (favicon etc.) are hosted locally and served by the FusionAuth server itself - so the answer that this can't be done for your own theme assets is non-obvious!

Hiya,

The issue is that the identityProviders map needs to be populated for that login script to work, and the class behind this page doesn't provide that map. So for now I don't see a way to do this.

There is an open github issue to allow identity providers to be displayed on the registration page. I'd suggest adding your use case to that issue: https://github.com/FusionAuth/fusionauth-issues/issues/554 and I'm happy to rename it to something more general. Alternatively you can file a new issue if you feel the use case is distinct enough.

@dan Last week ago I am facing that issue and I am still not got any solution.

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