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

[Mike Rylander]

On Tue, Jun 2, 2009 at 6:39 AM, Dan Scott <denials at gmail.com> wrote:
> 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.
>

That /is/ interesting, and definitely worth looking into (setting
aside my reactionary fear of proxies with EG) for large installations,
but I think it's more deserving of a "here's how to /really/ trick out
your EG install" article.

Maybe that goes into main-line once we see it in production at Conifer
and all fears are put to rest?

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com