| Time |
Nick |
Message |
| 01:55 |
|
niko0 joined #evergreen |
| 05:24 |
|
TehNut29 joined #evergreen |
| 05:42 |
|
MJ9414 joined #evergreen |
| 07:48 |
|
foobarrel joined #evergreen |
| 07:48 |
|
dluch joined #evergreen |
| 07:48 |
|
Bmagic joined #evergreen |
| 08:01 |
|
rlefaive joined #evergreen |
| 08:36 |
|
Guest9283 joined #evergreen |
| 08:37 |
|
Guest9283 was kicked by jeff: Guest9283 |
| 09:04 |
|
rlefaive joined #evergreen |
| 09:59 |
|
rlefaive joined #evergreen |
| 12:14 |
|
klx``22 joined #evergreen |
| 13:37 |
|
buriedalive2 joined #evergreen |
| 15:11 |
|
zyley joined #evergreen |
| 16:27 |
|
asjoyner joined #evergreen |
| 16:37 |
asjoyner |
Happy labor day weekend (at least to those in the US :) ) ! |
| 16:37 |
asjoyner |
I'm still bumbling around with an install of Evergreen, and I'm now a lot closer to having a working setup... |
| 16:39 |
asjoyner |
after a bit of initial trouble (https://github.com/evergreen-library-system/OpenSRF/pull/4) caused by running the main webserver on a non-standard port (:4443), I can now login and add patrons, import books from LOC records, etc. |
| 16:40 |
asjoyner |
unfortunately, a couple pages under Administration > Server Administration result in infinite redirects which make Chrome sad. :-( |
| 16:41 |
asjoyner |
In particular, Organization Types and Organizational Units |
| 16:42 |
asjoyner |
By contrast, Organizational Unit Setting Types seems to work fine. Thus, I've been digging through the Perl, reading the template expansion code, trying to divine how the first two differ from the latter. |
| 16:44 |
asjoyner |
In the JS console, there's a suspicious error message, but I'm not succeeding at parsing it: |
| 16:45 |
asjoyner |
Uncaught DOMException: Blocked a frame with origin "https://<hostname>:4443" from accessing a cross-origin frame. |
| 16:45 |
asjoyner |
at h.$scope.egEmbedFrameLoader (https://<hostname>:4443//js/ui/default/staff/services/eframe.js:107:69) |
| 16:45 |
asjoyner |
at HTMLIFrameElement.<anonymous> (https://<hostname>:4443//js/ui/default/staff/services/eframe.js:46:27) |
| 16:45 |
asjoyner |
at HTMLIFrameElement.dispatch (https://<hostname>:4443//js/ui/default/common/build/js/jquery.min.js:2:41772) |
| 16:45 |
asjoyner |
at HTMLIFrameElement.y.handle (https://<hostname>:4443//js/ui/default/common/build/js/jquery.min.js:2:39791) |
| 16:47 |
asjoyner |
as before (http://irc.evergreen-ils.org/evergreen/2018-08-19) I suspect everyone's away on the weekend, but I figure I'll narrate my progress here. |
| 16:47 |
asjoyner |
if I get to the bottom of it by the weekend, it'll serve as a nice record for the future. |
| 16:47 |
asjoyner |
if not, maybe someone next week will have some ideas. :) |
| 16:52 |
asjoyner |
the redirect loop and console error are visible in the Chrome debug window in this screenshot: https://photos.app.goo.gl/u5KRvTptUkJCfBMy5 |
| 16:52 |
|
and joined #evergreen |
| 16:54 |
* asjoyner |
waves. |
| 17:12 |
asjoyner |
As best as I can tell, when I load :4443/eg/staff/admin/server/legacy/actor/org_unit_type the javascript is trying to load :4443/conify/global/actor/org_unit_type.html ... which exists at a very reasonable path as a plain html file which Apache should serve... hm.... |
| 17:16 |
asjoyner |
hmm... that's matched by the <Location /conify> stanza in eg_vhost.conf, which requires "AuthType Basic" and sets "PerlAuthenHandler OpenILS::WWW::Proxy::Authen" ... |
| 17:22 |
asjoyner |
if I drop the auth sections of that stanza (and forcibly reload the page in Chrome), the page loads as (I assume) it should... Hmm... |
| 17:23 |
asjoyner |
I'm going to guess that some aspect of cookie plumbing is at play, somehow the login is happening against a different origin, although all the traffic seems to be against :4443, so I'm not sure that makes sense... |
| 17:38 |
asjoyner |
some cookies (in particular, ses) seem to be passed to the Authen module, which it looks like it should use to verify_login($auth_ses)... |
| 17:38 |
* asjoyner |
adds some debug logging to Authen.pm |
| 18:06 |
asjoyner |
okay, so it seems that the method Authen.pm uses to detect if you're using https is flawed. |
| 18:07 |
asjoyner |
specifically, the check on line 49 of $url =~ /^http:/o here: https://github.com/evergreen-library-system/Evergreen/blob/master/Open-ILS/src/perlmods/lib/OpenILS/WWW/Proxy/Authen.pm |
| 18:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:54 |
asjoyner |
despite my best efforts, there doesn't seem to be a reliable way for that code path to determine if the session is happening over HTTPS (or more precisely, TLS these days...) |
| 18:59 |
asjoyner |
hopefully someone more adept at mod_perl and/or the CGI perl module than me can take a stab at it. For now, I'm going to just comment out that block and go on my merry way. |
| 19:04 |
asjoyner |
to clarify for whomever might read this later, as best as I can tell, if your traffic doesn't arrive on port 443, by the time it gets to line 49 in the code it gets prepended with http://, regardless of the actual protocol Apache is speaking |
| 19:04 |
asjoyner |
I can't quite figure out if Apache, mod_perl, or the CGI module is to blame |
| 19:06 |
asjoyner |
regardless, the remainder of that code where it swaps out http:// for https:// also makes a flawed assumption: if you arrived on an alternate port (eg. 8080) it will preserve that and prepend it with https://, which is very unlikely to be successful |
| 19:07 |
asjoyner |
happy trails! |
| 19:41 |
|
rlefaive joined #evergreen |
| 20:31 |
|
Madbrad20021 joined #evergreen |
| 21:37 |
|
mrkirby1539 joined #evergreen |
