DSpace XSS shock terror in IE 7
IE 7 is paranoid. Yup, but judging by how long IE 6 lasted there is going to be another few years before we can safely forget about IE 7. Recently I had a mysterious security error while looking at a DSpace installation with an IE 7 browser.
Apparently IE 7 thinks that the Google Analytics script included into the DSpace page is an attempt at XSS. Troubleshooting this little nugget was not a lot of fun. In fact running IE 8 in IE 7 mode with quirks mode enabled was still not enough to replicate the error. Fortunately there is a quick way to fix the problem that can clear up other Security/Mixed Content messages that you maybe getting in IE. Keep in mind I'm talking about the XMLUI with the Kubrick theme as my example.
The Step
- The DSpace manual has the basics on how to enable Google Analytics. Basically you change dspace.cfg to include your UA-XXXXXX-X account code that Google gave you.
- Manually download http://google-analytics.com/urchin.js and plop it in the lib directory of the DSpace theme you are using. So it will be something like: /usr/local/tomcat/webapps/xmlui/themes/Kubrick (This will vary greatly depending on how your DSpace site is setup)
- Make a quick change to the Kubrick.xsl file:
<!-- Add a google analytics script if the key is present -->
<xsl:if test="/dri:document/dri:meta/dri:pageMeta/dri:metadata[@element='google'][@qualifier='analytics']">
<script src="http://google-analytics.com/urchin.js" type="text/javascript"><xsl:text> </xsl:text></script>
<script type="text/javascript">
<xsl:text>_uacct = "</xsl:text><xsl:value-of select="/dri:document/dri:meta/dri:pageMeta/dri:metadata[@element='google'][@qualifier='analytics']"/><xsl:text>";</xsl:text>
<xsl:text>urchinTracker();</xsl:text>
</script>
</xsl:if>
To
<!-- Add a google analytics script if the key is present -->
<xsl:if test="/dri:document/dri:meta/dri:pageMeta/dri:metadata[@element='google'][@qualifier='analytics']">
<script src="/themes/Kubrick/lib/urchin.js" type="text/javascript"><xsl:text> </xsl:text></script>
<script type="text/javascript">
<xsl:text>_uacct = "</xsl:text><xsl:value-of select="/dri:document/dri:meta/dri:pageMeta/dri:metadata[@element='google'][@qualifier='analytics']"/><xsl:text>";</xsl:text>
<xsl:text>urchinTracker();</xsl:text>
</script>
</xsl:if>
Reload and off you go. You get the added benefit of having the script locally loaded so you don't have wait on Google's servers to respond. That should help with loading speed and plus it'll create one less Mixed Content Nag in IE.
This little bugger has made so many websites slower because people have been https-in' everything.
Comments
2 comments postedI'm guessing that your DSpace page was accessed via https, and the browser was complaining about a non-https request on an http page?
The other way to fix that is just to make sure you access the google analytics script via https -- the latest Google Analytics instructions (if not the latest Dspace instructions) tell you how to include the script so it will be automatically be accessed via the correct protocol for the page (including a page that can sometimes be http and sometimes be https): http://www.google.com/support/googleanalytics/bin/answer.py?answer=55488...
Or better yet, the new asynchronous version will give you better page performance: http://www.google.com/support/googleanalytics/bin/answer.py?answer=174090
Following either of those instructions should eliminate the "http in an https page" warning. DSpace instructions are possibly based on very old Google instructions, or are DSpace developers own 'innovation' that doesn't work right.
The downside of the way you've done it instead is if Google's script changes, you'll still be using the old cached version you've got, which may cause Analytics to stop working or work incorrectly until you notice and update your cached version.
Personally, I'd follow Google's instructions instead.
All these alternatives sound great. My solution was more along the lines of satisfying 'good' versus 'good enough' Sure using the newest tracker code would be good but it is tough to overlook the solution that needs one wget and two seconds with vim.