|
|
Issue Type:
|
Bug
|
Affects Versions:
|
4.1, 1.8.2
|
Assignee:
|
Unassigned
|
Components:
|
XMLUI
|
Created:
|
16/Jun/14 11:25 AM
|
Environment:
|
Client: Mac OS X 10.9.3, Safari 7.0.4 Server: DSpace 4.1, XMLUI, Mirage theme, Tomcat 7, Java 7, Connector using org.apache.coyote.http11.Http11NioProtocol, Debian wheezy
|
Priority:
|
Minor
|
Reporter:
|
Christian Völker
|
|
I have configured https://. When going to /password-login, Safari does not show a padlock indicating a secure connection. Firefox and Chrome do, however, they show a shield. This indicates that they have replaced a resource loaded over a insecure connection. The resource turns out to be: <http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js> (Safari) <https://cvoelker.info/static/js/jquery-1.6.2.min.js> (Firefox) Page source shows these lines at the very bottom: <script src="" href="http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js" style="color: #3b73af; text-decoration: none">http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js" type="text/_javascript_"> </script> <script type="text/_javascript_">!window.jQuery && document.write('<script type="text/_javascript_" src="" <\/script>')</script> Related code is found in [dspace-source]/dspace-xmlui/src/main/webapp/themes/Mirage/lib/xsl/core/page-structure.xsl This code has already be revised several times for similar reasons. See
DS-789
or
DS-1011
, both closed. SSL is attacked quite often these days and browsers and server configurations get changed accordingly to mitigate problems. As such, DSpace code obviously has to react as well from time to time. Why do I feel this to be important? The padlock not seen suggests that the page is not transferred over https:// at all. This takes away trust. One could argue that this was a bad design decision on Apples side, but then the Firefox/Chrome solution with the shield is only slightly better, because they dont tell which resource exactly was blocked. You find a wealth of discussions around missing padlock in Safari, so it is not me alone who struggles with that. My proposition for solving the issue is to shorten these two blocks in page-structure.xsl, responsible for the first line cited from the page source: <xsl:variable name="protocol"> <xsl:choose> <xsl:when test="starts-with(confman:getProperty('dspace.baseUrl'), 'https://')"> <xsl:text>https://</xsl:text> </xsl:when> <xsl:otherwise> <xsl:text>http://</xsl:text> </xsl:otherwise> </xsl:choose> </xsl:variable> <script type="text/_javascript_" src="" 'ajax.googleapis.com/ajax/libs/jquery/', $jqueryVersion ,'/jquery.min.js')}"> </script> They might be replaced with something like this: <script type="text/_javascript_" src="" href="https://ajax.googleapis.com/ajax/libs/jquery/'," style="color: #3b73af; text-decoration: none">https://ajax.googleapis.com/ajax/libs/jquery/', $jqueryVersion ,'/jquery.min.js')}"> </script> I have given up on learning XSLT properly. So I dont supply this as a patch. My thoughts about what actually happens and why my suggestion could solve the issue: I guess that jquery already gets loaded by insecure path when hitting the DSpace homepage. When moving on to the login page, thus switching to https:// (dspace.cfg: xmlui.force.ssl=yes), Safari does not bother to load it again from the servers local source as Firefox does, displaying the shield as a result. Instead, Safari uses the version already loaded insecurely, then decides that it displays mixed content while showing the /password-login page which does not qualify as a secure page in its entirety in consequence and hides the padlock. This means that jquery.min.js should be loaded over https:// already on the homepage, even though this page is not loaded over http://. This solution is possible, because the DSpace server does not necessarily need to support https:// for this. Google provides all resources over https:// regardless: <https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js> This means that the whole logic behind the block <xsl:variable name="protocol">…</xsl:variable> is obsolete. I have no idea what side effects such a change might have on other clients. However I cant think of any adverse effects. I just tried my solution on my test server. You can see the result here: <https://cvoelker.info> I just changed it on the fly in my /var/lib/tomcat7/webapps/ROOT/themes/Mirage/lib/xsl/core/page-structure.xsl, so the change will vanish with my next rebuild. See page source or try Safari to find out whether it is still there.
|
|
|
|