force SSL for requests coming from chrome (that is, local xul, not Google's browser:)

[Jason Etheridge]

There's an Evergreen site that would like to be able to force SSL for the entire staff client. I can almost do this entirely with Apache using something like:

RewriteCond %{SERVER_PORT} !443
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R,L]

Some improvements would be to restrict this to the /xul directory, and/or make it optional based on some condition like cookies or user agent strings so that the client itself could decide whether to toggle it on or off from the login window. Their main use-case is not actually security, but getting through a transparent proxy that neuters the "dangerous" staff client Javascript.

Assuming I tighten that down, my other problem is that such rewrites break remote requests from local XUL, which aren't being sent with SSL. There are two things I'd like to do here if there are no objections, even for people who opt not to enable SSL for everything through Apache (because it defeats caching, performance suffers, etc):

* Modify RemoteRequest.js so that it converts a request URL to https:// if the location of the request is chrome:// It already does this if the location is https://
* Modify util/network.js such that secure is assumed if older invocations of .request are used instead of .simple_request. simple_request actually looks for a secure flag for a given API call in constants.js, but request does not.

Justification is that there are very few calls coming from local XUL, it makes those calls more secure, and it helps me do the Apache thing. :-)

Branch coming in a moment....

[Jason Etheridge (phasefx)]

collab/phasefx/ssl_login @ working/Evergreen.git

[Dan Wells (dbw2)]

Hello Jason,

I'd be very happy to commit this, as I have been testing already some very similar changes locally as they relate to the AuthProxy branch. Just one question: can you let me know a quick test case where the changes to RemoteRequest.js are necessary? I am familiar with the redirect problems which are fixed by your change to network.js, but haven't run into cases where the other fix is needed yet. I'll also admit I haven't looked really hard at this point, but I am betting you had a case in mind when you made the change.

Thanks,
Dan

[Jason Etheridge (phasefx)]

> I'd be very happy to commit this, as I have been testing already some
> very similar changes locally as they relate to the AuthProxy branch.
> Just one question:  can you let me know a quick test case where the
> changes to RemoteRequest.js are necessary?  I am familiar with the
> redirect problems which are fixed by your change to network.js, but
> haven't run into cases where the other fix is needed yet.  I'll also
> admit I haven't looked really hard at this point, but I am betting you
> had a case in mind when you made the change.

It is a bit of a sledgehammer. An alternative would be to tweak the
secure flags for the simple_request calls that appear in menu.js,
though that would affect their use in remote xul as well, or make an
alternate entries in constants.js for menu.js to use, or perhaps send
an explicit secure flag through the simple_request invocations.

Some examples of affected actions include Search -> Search for Record
by TCN and Circulation -> Replace Barcode. The non-SSL POST requests
from them would break if Apache was doing aggressive rewriting.

[Dan Wells (dbw2)]

Ah, right, thanks. I can see some merit to the other approaches you mention, but since your current code is so well confined, I think there isn't much risk going with it since we can easily change course (or perhaps option-ize it) later on.

Barring any further testing issues, I'll get this in.

Thanks again,
Dan

[Dan Wells (dbw2)]

Testing looks good, no problems code-wise. I do have a few suggestions for the Apache redirect sample. Also, I recognize that I am scrutinizing what amounts to "suggested" code, but bear in mind that I just struggled through this when testing AuthProxy, so I feel a disproportionate stake how this might play out.

First, I think it is better to use the %{HTTPS} "magic" variable rather than looking at the port, since in some cases Apache may be using different ports. Something like:

RewriteCond %{HTTPS} off

Second, in doing some random manual testing of the gateway, I found that data was getting double encoded on redirect. For example, try something like:

http://myserver.mydomain.com/osrf-gateway-v1?locale=en-US&method=open-ils.auth.authenticate.init&param="test"&service=open-ils.auth

The quotes end up double encoded (and you get a OSRF 404 error):

https://myserver.mydomain.com/osrf-gateway-v1?locale=en-US&method=open-ils.auth.authenticate.init&param=%2522test%2522&service=open-ils.auth

You can get around this double-encoding with an 'NE' flag:

RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [NE,R,L]

Also note, should you decide to test this, that Firefox (in this case, unhelpfully) caches redirects, so I usually change the param to do a true test.

Finally, if we are just capturing everything, I think we can save ourselves some trouble and just pass through the original URI:

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [NE,R,L]

So, for clarity, the end result would be:

RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [NE,R,L]

Jason, please feel free to force push whichever of these changes are agreeable to you and I'll sign off on the branch.

Thanks!
Dan

[Jason Etheridge (phasefx)]

Looks good! Force-pushed the change

[Dan Wells (dbw2)]

Committed and backported through rel_2_0. Thanks, Jason!