After upgrade, http site behind load balancer which offloads https, does not work

Problem reported by Dan Johnson - 2/17/2019 at 10:09 PM

Resolved

Hi.

My v12 smarter track worked fine behind an AWS load balancer which handled https traffic. Now upgrading to build 6984 I have the site partially functional with some api endpoints not working and font awesome icons not showing meaning we can't use the system and I can't see tickets. Those requests return 403 responses but most requests work.

Its on a Windows Server 2016 Datacenter server.

I can't imagine why this stuff is not working. Any help would be apprecaited.

Thanks,

Dan.

4 Replies

Reply to Thread

Dan Johnson Replied

2/18/2019 at 1:12 PM

An update, next day it looks like the fonts are loading. That's curious because these were giving a 403 response and it resolved itself. Now, the main issue is that some ajax calls give the 403, most notably /api/tickets/search does anyone have any advice on what may cause a 403 response for these api calls but everything else appears to be working.

The 403 comes with a html page containing basic html and some styles:

<h2>403 - Forbidden: Access is denied.</h2>
<h3>You do not have permission to view this directory or page using the credentials that you supplied.</h3>

Is this somehow coming back from IIS or is that smarter track? My upgrade involved removing everything except App_Data and then adding in the update files. So it is a standard install. Surely someone else has experienced this.

Dan Johnson Replied

2/18/2019 at 1:59 PM

Marked As Resolution

Solving this one myself. The 403 appeared to be intentional and I got a hint from somewhere that this might be a CORS thing, and could possibly be solved using a URL rewrite within IIS but I also noticed in web.config references to a smarter track CORS module so I just commented out those references and that solved this. So if you have the site behind an AWS ELB with HTTPS offload then that's a temporary solution. Longer term the URL rewriting is necessary so the IIS site thinks that it is HTTPS.

Dan Johnson Replied

2/19/2019 at 7:30 PM

Back and replying to myself again. Found that the popup reply window was not rendering properly because it hard coded links based on what IIS thought the site url was, rather than what it actually is to users in front of the load balancer. To help others in the same situation you need to rewrite the outbound page using something like this:

		<rewrite>
			<outboundRules>
                <rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
                    <match filterByTags="A, Form, Img, Script,Link" pattern="^http://your.ticketing.system/(.*)"; />
                    <action type="Rewrite" value="https://your.ticketing.system/{R:1}" />
                </rule>
				<preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="(.*)" />
                    </preCondition>
                </preConditions>  				
            </outboundRules>	
        </rewrite>

Dan Johnson Replied

10/7/2020 at 1:59 PM

In case this is useful, I believe a better approach is to instead tell the site it is secure using these rules. Note that you need to go into IIS, under rewrite, from the menu on the left select server variables and make sure both those server variables below are listed as being allowed to be overwritten. This setting is not stored in web.config so it has to be applied using IIS.

The following can then be added to web.config. Can't be used in conjunction with the previous suggestion.

<rules>

</rules>

Back to Community Threads

Please leave this box unchecked

4 Replies

Reply to Thread

Tags

Related Knowledge Base Articles