search

ventaur / securityswitch

Security Switch enables various ASP.NET applications to automatically switch requests for pages/resources between the HTTP and HTTPS protocols without the need to write absolute URLs in HTML markup.
Other
2 stars 0 forks source link

Stylesheet fails to load on secure page when "bypassSecurityWarning" is set to true in web.config #10

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Have master page with relative URL for stylesheet 
<link href="Styles/screen.css" rel="stylesheet" type="text/css" />

2. Add secure web page path
<add path="~/Contact-Us" />

3.Add bypassSecurityWarning="true" to Web.Config

4. Navigate to www.mywebsite/Contact-US

What is the expected output? What do you see instead?
Contact-Us loads as expected without IE security warning
Contact-Us Page loads without stylesheet 

Removing bypassSecurityWarning="true" resolves the style sheet loading issue.

(The IE8 Security warning is resolved)

What version of the product are you using? On what operating system?
4.0.4138, Windows 2008 Server

Original issue reported on code.google.com by rick...@gmail.com on 25 May 2011 at 1:46

GoogleCodeExporter commented 9 years ago 
There is an easy solution to this one, but the issue itself is a bit trickier 
to swallow.

First, the solution. You have to add a path to ignore in your web.config for 
the securitySwitch section. This path entry should be set to ignore your Styles 
directory.

<add path="~/Styles" security="Ignore" />

As for the issue itself. What's happening is the module is emitting JavaScript 
to change the window.location when bypassSecurityWarning is set to true. In 
your case, the screen.css file was being intercepted by the module, it was not 
found in your web.config and assumed to be accessed only insecurely, and the JS 
was emitted for it to change the location. By ignoring all files in your Styles 
directory, the module doesn't interfere.

"Fixing" this "issue" is another story. It's not entirely possible to know if a 
request for a resource is text/html or not. You know, but this module can't 
know (even looking for certain extensions isn't foolproof if a handler .axd is 
used to return CSS, etc.).

So, for now, my solution will be to just inform this module to ignore your 
basic resources to avoid these issues. In fact, you should ignore such 
resources regardless to prevent unnecessary evaluation and redirects.

Original comment by vent...@gmail.com on 25 May 2011 at 7:03

GoogleCodeExporter commented 9 years ago 
Thanks!

Original comment by rick...@gmail.com on 25 May 2011 at 7:22

GoogleCodeExporter commented 9 years ago 
Just an FYI that this worked for our website. Thanks again.

Original comment by rick...@gmail.com on 26 May 2011 at 12:13

GoogleCodeExporter commented 9 years ago 
Excellent! Thanks for the update.

Original comment by vent...@gmail.com on 26 May 2011 at 9:43