Forms appear corrupted after upgrade from version 7.x -> 10- > 7803
Question asked by Steven P - 6/18/2021 at 1:07 PM

I have just upgraded from Smartertrack 7.4.4338 to version 10 then to 7803 and it looks like all the forms are displayed corrupted - tried in Chrome and FF and same results.
You can see the attached screenshot here.

Any idea what could cause this?

7 Replies

Reply to Thread
Steven P Replied
After further investigation it appear that the issue only happens when running Smartetrack behind a reverse proxy.
I have Smartertrack running on IIS on port 9996 HTTP only and and on the same host I have NGINX acting as reverse proxy with SSL ON and redirecting HTTPS requests for the particular host name to localhost:9996.

The FQDN for the hostname is added into the local Windows HOSTS file and in the Smartertrack configuration I have configured the FQDN of the host.

Do I need to specify HTTPS somewhere in the Smartertrack configuration?
Employee Replied
Employee Post
Hi Steven,

There is a setting in SmarterTrack for forcing traffic over HTTPS, but I couldn't say if this would resolve your issue or not. This can be found when you login as the system administrator and go to Settings > Security > Options tab. BEFORE making this change be sure you have SSL implemented for your SmarterTrack installation ( Properly Implementing SSL for SmarterTrack). 

If you continue to have problems, and you have a license with current Maintenance and Support, I suggest opening a technical support ticket.
Steven P Replied
I found the issue is caused by the CSP feature blocking CSS files..
The logs show the following files  froala_style.min.css froala_editor.pkgd.min.css  and codeMirror.min.css are being blocked by SmarterTrack itself.

    Source URI: https://mysupportsite.com/Main/frmNewTicket.aspx?InstanceID=943ae930-12d4-43ff-9b73-31dbac950597
    Blocked URI: http://mysupportsite.com:9996/Common/Controls/froala/css/froala_editor.pkgd.min.css?v=v3_2_6
    Violated Directive: style-src-elem
    Effective Directive: style-src-elem
Any suggestions on how to get around this?
Employee Replied
Employee Post

Thank you for the additional information. In SmarterTrack go to Settings > Security > CSP tab and make sure the URL you are connecting to is listed. There's more on this in our help here: Security
Steven P Replied
Thank you for your continued support Emily.

I tried adding entries in the CSP lists but that did not make a difference.

To clarify:
The pages are requested from the client browser via HTTPS :

The request is received by the reverse proxy on port 443 which then sends the request to the upstream server via HTTP on port 9996 where SmarterTrack is running (It happens that both the reverse proxy and SmarterTrack are running on the same host.):

After further digging I found the issue is rooted in C:\Program Files (x86)\SmarterTools\SmarterTrack\MRS\dist\js\common.min.js\
in the lines containing
'<link type="text/css" rel="stylesheet" href="'+options.st.baseUrl+"

The above script contains the href="'+options.st.baseUrl+" which doesn't seem to be replaced to the base site URL that I have configured to be https://mysupportsite.com
and served to the browser as such and so it fails.

I checked that <HttpAbsolutePath> in SmarterTrack\MRS\App_Data\Config\SystemSettings.xml is set to
I tried deleting the SystemSettings.xml and re-run the setup wiizard but the <HttpAbsolutePath> is being reset to <HttpAbsolutePath> after running the wizard.
So I suspect the issue is due to to this setting.

Any suggestions on how to fix this?

Kyle Kerst Replied
Employee Post
@Steven - I think this might be either a Base URL issue or a problem involving CSP as Emily has pointed out. If this is an issue with CSP, I believe it might be stemming from the redirect from HTTPS to HTTP and redirect from port 443 to port 9996. Do you have all of the possible hostname configurations added to your CSP lists? Absent that, I believe the base URL might in fact be the issue. This is set within Settings>Management Interface and you may have better results setting that to your HTTP hostname on port 9996, though I recommend completing a backup beforehand just to be safe! If you end up needing some deeper review done on this please don't hesitate to submit a ticket with us. Have a good one!
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
Steven P Replied
Thanks again for all the suggestions.
The hostnames in CSP did not seem to help.

I found the solution by adding the following in my nginx reverse proxy config:
location / {
sub_filter_once off;
sub_filter_types text/html;
sub_filter "http://smartertrackserver:9996"; "https://publicserver";


Reply to Thread