Feature: Additional themed error pages

[robotdan]

Additional Themed Error Pages

Problem

If an unexpected exception occurs due to unexpected user input, an internal error, etc, FusionAuth will render a 500 status page that is not part of the theme.

This means it is possible for an end user of a branded login to see this page.

Solution

Add this error page and any other possible error page to the theme.

Internal

We'll have to test to see if the corresponding JSP error templates can properly forward to the themed version. Assuming we can just use ThemedForwardResult instead of ForwardResultin the JSP.

templates/errors
  |__ 404.ftl
  |__ 500.ftl
  |__ default.ftl

Alternatives/workarounds

Manually modify /usr/local/fusionauth/fusionauth-app/web/WEB-INF/templates/errors/404.ftl

Additional context

N/A

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[dmitryzan]

Hi, thank you for the great work!

Is there some safe workaround for this issue now when using a docker version? Like mounting some modified files to the container instead of the packaged ones? In my case mostly interested in 404 pages when users use incorrect URL's.

[mooreds]

This forum post alludes to the fact that you can tweak things inside the fusionauth-app directories at your own risk (both in terms of current functionality and future breakages):

https://fusionauth.io/community/forum/topic/180/is-it-possible-to-set-up-ssl-for-fusionauth-directly

I don't know how many tenants you have, but if you only have one, you could look at changing the default 404 freemarker template (you'll need to look around for 404.ftl). Again, this is unsupported and might break in the future, but it's an option you could do now.

A safer option might be to run a proxy in front of FusionAuth which could catch 404s . You could, for instance, use this directive with nginx: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors

[dmitryzan]

Ok, perfect, thank you!. I can definitely mount an updated file to /usr/local/fusionauth/fusionauth-app/web/WEB-INF/templates/errors/404.ftl in the docker container. It's ok in my environment, no forward compatibility concerns.

I have three tenants/applications. Is the tenant or application ID available as a model attribute while rendering this template to use slightly different formatting (and what is the name)?

[mooreds]

I don't believe there is any customization objects available to this template (I think that's actually the point of this issue, to see if we could enable that).

[robotdan]

Ha.. just realized this issue is #404 - what a funny coincidence.

[robotdan]

There are technical complications with theming pages such as 404 and 500 while we are still running on Apache Tomcat. We are planning to remove Apache Tomcat in the near future and run an embedded Netty server instead.

This should help us in a bunch of ways, but in particular it should make it easier to manage pages such as these using a theme. So stay tuned, but this issue is sort of blocked until we get off of Tomcat.

[wagreniergsoft]

Hi, We have custom errors in our backend that would require an error page other than the ones offered to be adequate for our clients. We were wondering if it could be possible as a feature in FusionAuth to add a new more customizable error page. This would allow us to have more defined and appropriate error messages without polluting other error pages that are used by FusionAuth that have more defined use cases. It would be great if said custom error page could receive arguments from the url.

Thank you