[OPEN-ILS-DEV] Fixing the mixed-content warnings in My Account

[Dan Scott]

2009/5/29 Mike Rylander <mrylander at gmail.com>:
> On Fri, May 29, 2009 at 12:38 AM, Dan Scott <denials at gmail.com> wrote:
>> If I understand correctly, some browsers (hello IE!) throw up warnings
>> when patrons enter "My Account" in the OPAC because there are some
>> hard-coded HTTP requests mixed in with the HTTPS session. When patrons
>> opt to not allow the browser to load mixed content, hilarity (or some
>> miserable facsimile thereof) ensues. This is bad. Apaprently things
>> are even worse in IE8.
>>
>> It looks like the mixed content is due to
>> Open-ILS/var/web/opac/skin/default/xml/setenv.xml:
>>
>> setenv.xml:<!--#set var="OILS_BASE"
>> value="http://${SERVER_NAME}/${OILS_OPAC_BASE}"-->
>> setenv.xml:    <!--#set var="OILS_OPAC_JS_HOST"
>> value="http://${OILS_OPAC_JS_HOST}"-->
>> setenv.xml:    <!--#set var="OILS_OPAC_CSS_HOST"
>> value="http://${OILS_OPAC_CSS_HOST}"-->
>>
>> Setting these to the following alleviates the problem:
>>
>> setenv.xml:<!--#set var="OILS_BASE" value="${OILS_OPAC_BASE}"-->
>> setenv.xml:    <!--#set var="OILS_OPAC_JS_HOST" value=""-->
>> setenv.xml:    <!--#set var="OILS_OPAC_CSS_HOST" value=""-->
>>
>> The win from having a non-scary default configuration seems to, in my
>> mind, outweigh the possible balancing of JS and CSS across different
>> hosts. Would there be any objection to my merging a commit that resets
>> each offending var to a non-scary default value, along with a comment
>> that explains what in the wide world of sports is going on?
>
> How about we do that /AND/ supply https: versions of those three,
> having the code that deals with  (and makes up) the My OPAC stuff use
> those.  Perhaps even make that explicit in the name by putting MYOPAC
> in there:
>
> setenv.xml:<!--#set var="OILS_MYOPAC_BASE"
> value="https://${SERVER_NAME}/${OILS_OPAC_BASE}"-->
> setenv.xml:<!--#set var="OILS_MYOPAC_JS_HOST"
> value="https://${OILS_OPAC_JS_HOST}"-->
> setenv.xml:<!--#set var="OILS_MYOPAC_CSS_HOST"
> value="https://${OILS_OPAC_CSS_HOST}"-->
>
> Then My OPAC is happy in tin-foil browsers, and those sites that need
> a separate content server (at least the 2 largest production sites,
> that I recall OTTOMH) don't have to jump through any more hoops than
> anyone else at upgrade time -- it stays as config settings.  Do you
> see any issues with that modification to your plan?

Other than being more work and perhaps more susceptible to slipping in
an error somewhere for the simple case, no, I think it will maintain
the current approach for serving up static content in more complex
configurations. For now, we have adopted the simplistic "serve
everything up from a single host" approach (recognizing that that's
eating up our Apache backends like crazy, but hey, it's summer and
slow time for the academics).

Rather than trying to solve the problem in the Evergreen application
code, another approach would be to use something like nginx as a proxy
to serve up all known static types (*.js, *.png, *.gif, and the like)
/ locations and to hand off the dynamic requests to Apache. nginx is
apparently able to serve up static content at higher concurrency and
using far less CPU & RAM than Apache requires. This would add one more
moving part to a production configuration, but it would have the
advantage of simplifying the application code (one less set of SSI to
deal with). Each server in a load-balanced cluster could be
responsible for serving up its own static content; or all static
content could be served up from a designated host; or in a simple
non-nginx environment, Apache could still serve up all static +
dynamic content.

There's a good intro to nginx at
http://www.linuxjournal.com/article/10108 for those interested in
pursuing this direction.

-- 
Dan Scott
Laurentian University