My ASP.NET MVC Page (using Forms Authentication) is not Rendering CSS and Javascript on the Login View - All Requests Show as Redirects to the Login Controller Action in Fiddler

I recently tried to deploy an ASP.NET MVC 4 mobile application (using jQuery Mobile 1.0) to one of the Oakton Amazon Web Services (AWS) web servers. This application used Forms Authentication.

I span up a completely new instance of Windows Server 2008 R2, restored a backup database and xcopy deployed the new application to a newly created Virtual Directory. I ran the Microsoft Web Platform Installer to get the latest MVC framework and supporting components.  I enabled Forms And Anonymous Authentication on that IIS 7 Site and made sure that All users can access the CSS files even before logging in with the following entries in the web.config file:

<location path="Content">
            <system.web>
                  <authorization>
                        <allow users="*" />
                  </authorization>
            </system.web>
      </location>
      <location path="Styles">
            <system.web>
                  <authorization>
                        <allow users="*" />
                  </authorization>
            </system.web>
      </location>
      <location path="Scripts">
            <system.web>
                  <authorization>
                        <allow users="*" />
                  </authorization>
            </system.web>
      </location>

However, when hitting this server, the login screen just wouldn't render correctly. Looking at the requests showing up in Fiddler - it seemed that even the CSS and javascript files were being redirected to the login page. Some of my colleagues had a look - but were also stumped. All the permissions looked right!

While the application pool user had the correct permissions, the problem was that Anonymous users (i.e. everyone before login) were not running as the Application pool user - they were still running as the default which is IUSR. I simply edited the Anonymous authentication credentials setting in IIS 7 to use the Application Pool Credentials rather than IUSR. Alternatively, I could have given the IUSR_MachineName user permissions on the required supporting directories to fix the problem.

This resolved the problem - and CSS and jQuery were again accessible for all users (including anonymous ones). As usual this seems pretty obvious in hindsight - but the mad rush to get the whole environment running and to deploy the application meant that this critical link was missed.

Let this be a reminder.
DDK

CSS Positioning Refresher - Relative vs Absolute vs Static vs Fixed - SharePoint 2010 Branding

My current client is a media company who wanted branding done as part of a SharePoint 2010 Portal implementation project. One problem arose because their standard operating environment uses Internet Explorer 7. Our IE 7 specific issues arose because of IE7's position behaviour and it's interaction with a dynamic pop-down DIV that we were injecting with jQuery.

In IE7 (not in IE8+ or Firefox), our whole content div in SharePoint was getting pushed down by our hidden div used as part of the pop-down menu. Turns out our resolution to fix this IE 7 was to make our hidden div to use position:absolute rather than relative/static.

The critical difference between relative and absolute in particular is not how it changes the behaviour of the div - but rather how it affects the flow of OTHER elements on the page. This is particularly important when you are injecting elements into SharePoint with jQuery. The best explanation of CSS positioning (and how it affects other html elements) I've found is here:

http://www.w3schools.com/css/css_positioning.asp


RELATIVE: The content of relatively positioned elements can be moved and overlap other elements, but the reserved space for the element is still preserved in the normal flow.
ABSOLUTE:
Absolutely positioned elements are removed from the normal flow. The document and other elements behave like the absolutely positioned element does not exist (Yes! this is what we really want)

This still doesn't explain the rendering difference in IE7 vs IE8 vs Firefox apart from the fact that other browsers seem to be more forgiving when specifying your CSS positioning compared to IE7 (in Standards mode).

DDK