Serving Intranet from a subpath
Hi! (I'm sending this to koha-devel because I guess it's too technical for the general list?) We are running running the "Intranet" inside an actual intranet (i.e. inside a VPN). But this Koha instance is also hosting a related Library whose staff cannot access the VPN. For various reasons it is not possible to mount Koha at it's own domain, so we must make it available at a sub-path (something like "https://www.example.com/foo/koha") For the OPAC, I already implemented a hacky Plack Middleware that does some rather ugly rewriting or URLs and HTML (ughh..). While we could do the same for Intranet, I first wanted to check if it is maybe already possible to mount it under a subpath, i.e. have an Apache use something like ProxyPass /foo/koha/index.html ... ProxyPass /foo/koha/cgi-bin/koha ... Now, while this actually works, the pages returned do not, as all the links they contain point to /cgi-bin/koha (i.e., they loose the mount point and generate bad links). The usual way to solve this is via something like https://metacpan.org/pod/Plack::Middleware::ReverseProxyPath But for this work, two things (one small, one not) have to be changed: * the plack app (i.e. Koha) needs to honor some HTTP Header ENV vars (X_FORWARDED_SCRIPT_NAME, X_TRAVERSAL_PATH) * and all links generated by the app need to also honor those vars. The usual way for the latter is to *not* generate links by concatenating path fragments or hardcoded them in templates (which seems to be what Koha is doing), but to use a function/method to generate all links (to html pages, static assets and endpoints) So for example in a template like prog/en/modules/cataloguing/addbooks.tt we find: <a href="/cgi-bin/koha/mainpage.pl">Home</a> This would need to be changed to <a href=uri_for("/cgi-bin/koha/mainpage.pl")>Home</a> and uri_for needs to take a look at the ENV and fix the link accordingly. (The ugly workaround I am using in an OPAC is to use a Middleware to change the HTML after it's generated by Koha but before it is send to the client. shudder...) So on the one hand this seems to be a small change, but to work it needs to touch ALL templates. (and it will be hard to automatically identify all link-ish text in the templates (href, src, maybe sometimes the url is generated in a template, ...) Another approach would be to set the mount-point into <base href="/foo/koha"> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base But we would still need to change all the links to relative links, as `base` will ignore absolute links, which is what Koha is using now. though maybe the regex to replace the code is a bit easier (s{/cgi-bin}{cgi-bin}) as it does have to fiddle with quotes etc. Our customer is willing to do the work to implement this (probably also in OPAC), but only if the change will be accepted upstream and be usable by the end of this year (i.e. 22.11). Shall we try to tackle this? Or will this massive change never be accepted? If there is interest, I guess the next step is to open a bug... Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
I feel like we've had this conversation before but now I can't find a record of it... I was intrigued by that "base" suggestion, but there's a few issues with it: 1. You've made a mistake regarding relative vs absolute links. The link "/cgi-bin/koha/mainpage.pl" is a relative link with an absolute path reference. So you can use <base href="https://koha-community.org"> to tell the browser to use that base URL to construct an absolute URL. That is, the browser will take you to "https://koha-community.org/cgi-bin/koha/mainpage.pl" with the above. However, it will only ever use the scheme and the server/host. It will ignore any path that you provide. 2. If you did change all the links from absolute-path to relative-path (ie "cgi-bin/koha/mainpage.pl"), you could use something like <base href="/foo"> but you couldn't use <base href="/foo/koha">. The browser will only use the first path element. I suppose that would get you further than you are now, but it seems inelegant... Personally, I'm in favour of using "uri_for()" template methods, which are common in pretty much every web framework around today, but it would probably be a prohibitive amount of work. I also wonder how it might affect some of the latest Vue.js work that Jonathan has been doing. I'd love to get rid of "/cgi-bin/koha" one day in any case, since it's a holdover from decades past... Ultimately, I think only the RM can answer this one. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Thomas Klausner Sent: Friday, 12 August 2022 8:55 PM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] Serving Intranet from a subpath Hi! (I'm sending this to koha-devel because I guess it's too technical for the general list?) We are running running the "Intranet" inside an actual intranet (i.e. inside a VPN). But this Koha instance is also hosting a related Library whose staff cannot access the VPN. For various reasons it is not possible to mount Koha at it's own domain, so we must make it available at a sub-path (something like "https://www.example.com/foo/koha") For the OPAC, I already implemented a hacky Plack Middleware that does some rather ugly rewriting or URLs and HTML (ughh..). While we could do the same for Intranet, I first wanted to check if it is maybe already possible to mount it under a subpath, i.e. have an Apache use something like ProxyPass /foo/koha/index.html ... ProxyPass /foo/koha/cgi-bin/koha ... Now, while this actually works, the pages returned do not, as all the links they contain point to /cgi-bin/koha (i.e., they loose the mount point and generate bad links). The usual way to solve this is via something like https://metacpan.org/pod/Plack::Middleware::ReverseProxyPath But for this work, two things (one small, one not) have to be changed: * the plack app (i.e. Koha) needs to honor some HTTP Header ENV vars (X_FORWARDED_SCRIPT_NAME, X_TRAVERSAL_PATH) * and all links generated by the app need to also honor those vars. The usual way for the latter is to *not* generate links by concatenating path fragments or hardcoded them in templates (which seems to be what Koha is doing), but to use a function/method to generate all links (to html pages, static assets and endpoints) So for example in a template like prog/en/modules/cataloguing/addbooks.tt we find: <a href="/cgi-bin/koha/mainpage.pl">Home</a> This would need to be changed to <a href=uri_for("/cgi-bin/koha/mainpage.pl")>Home</a> and uri_for needs to take a look at the ENV and fix the link accordingly. (The ugly workaround I am using in an OPAC is to use a Middleware to change the HTML after it's generated by Koha but before it is send to the client. shudder...) So on the one hand this seems to be a small change, but to work it needs to touch ALL templates. (and it will be hard to automatically identify all link-ish text in the templates (href, src, maybe sometimes the url is generated in a template, ...) Another approach would be to set the mount-point into <base href="/foo/koha"> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base But we would still need to change all the links to relative links, as `base` will ignore absolute links, which is what Koha is using now. though maybe the regex to replace the code is a bit easier (s{/cgi-bin}{cgi-bin}) as it does have to fiddle with quotes etc. Our customer is willing to do the work to implement this (probably also in OPAC), but only if the change will be accepted upstream and be usable by the end of this year (i.e. 22.11). Shall we try to tackle this? Or will this massive change never be accepted? If there is interest, I guess the next step is to open a bug... Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Hi! On Mon, Aug 15, 2022 at 10:02:18AM +1000, dcook@prosentient.com.au wrote:
I feel like we've had this conversation before but now I can't find a record of it...
Yes, we had the same problem with OPAC, and "solved" it there with a HTML-Rewriting middleware (not very stable, but good enough for now)
I was intrigued by that "base" suggestion, but there's a few issues with it:
`base` is indeed very tricky had can have weird corner cases. But if it would have been an easy fix, I'd go with it. But as `base` is not working for our uses cases (without having to touch all links/templates) I think it's not the best option.
Personally, I'm in favour of using "uri_for()" template methods, which are common in pretty much every web framework around today, but it would probably be a prohibitive amount of work.
A lot work, yes (though I guess that 99% can be done with a few regex, but the hard part will be finding the corner cases that did not work). But the Steiermärkische Landesbibliothek is willing to do that work.
I also wonder how it might affect some of the latest Vue.js work that Jonathan has been doing.
I don't know a lot about how that app is implemented, but usually the Vue.js app will have its own internal routing and will "only" need to know two things: * where is the API the app should be talking to? * where are the vue.js source files and other assets located I also did not take a look how the Mojo API is connected with the rest and if / which paths need to be adapted there (though as Mojo provides `uri_for` I assume it will be simple)
I'd love to get rid of "/cgi-bin/koha" one day in any case, since it's a holdover from decades past...
Yes, if we generate links via a function, we could easily get rid of `/cgi-bin/koha` in the same go :-)
Ultimately, I think only the RM can answer this one.
And how can I get the RM to think about this issue, so we might get an answer (sorry, I'm still not that integrated into the Koha community..) Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
When I say it's a lot of work, I mean more so in terms of testing and QA than the writing/authoring of the patch. If you did a huge patch with a bunch of link changes via regex, no one would probably test it, because it would be too hard to thoroughly test. (And then it would be difficult for you to keep rebasing to keep up with Koha as it changed.) If I were you... I'd probably do a patch for the core uri_for() mechanism, and then propose adding a Coding Guideline that requires using it instead of hard-coded links like "/cgi-bin/koha/..." going forward. And then once that is part of Koha, then I'd open up targeted reports that look at updating the templates for say a particular module (e.g. Circulation, Cataloguing, Reports, etc) and go one by one. You could also try to recruit people to your cause for testing and QA. While I don't have a particular need for serving Koha via a subpath, I do find it interesting, so I'd be willing to do some testing/QA. I don't know that I have stamina to do the entire staff interface though... as that's over 400 templates. Another thought would be to first target the OPAC, since it has far fewer templates to update. Once it's been proven in the OPAC, it might be easier to convince people for the staff interface too, and maybe QA/RM would be willing to make changes with less rigorous testing, since it was already a proven change. As for bringing it to the attention of the RM, I've been around the Koha community for 10.5 years, and I still don't have an answer for that one 😉. You're in a good time zone, so if I were you I'd try bringing it up at a Koha developer meeting on IRC. I think there's one in the next day or so: https://wiki.koha-community.org/wiki/Development_IRC_meeting_17_August_2022 Anyway, don't take anything I say as too authoritative. It's just my 2 cents (ie opinion) as someone who has been around a while. I don't think that anyone can really guarantee that a change will be accepted, and I know that can make some developments (especially architectural ones) really hard to get off the ground. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Thomas Klausner Sent: Monday, 15 August 2022 9:57 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Serving Intranet from a subpath Hi! On Mon, Aug 15, 2022 at 10:02:18AM +1000, dcook@prosentient.com.au wrote:
I feel like we've had this conversation before but now I can't find a record of it...
Yes, we had the same problem with OPAC, and "solved" it there with a HTML-Rewriting middleware (not very stable, but good enough for now)
I was intrigued by that "base" suggestion, but there's a few issues with it:
`base` is indeed very tricky had can have weird corner cases. But if it would have been an easy fix, I'd go with it. But as `base` is not working for our uses cases (without having to touch all links/templates) I think it's not the best option.
Personally, I'm in favour of using "uri_for()" template methods, which are common in pretty much every web framework around today, but it would probably be a prohibitive amount of work.
A lot work, yes (though I guess that 99% can be done with a few regex, but the hard part will be finding the corner cases that did not work). But the Steiermärkische Landesbibliothek is willing to do that work.
I also wonder how it might affect some of the latest Vue.js work that Jonathan has been doing.
I don't know a lot about how that app is implemented, but usually the Vue.js app will have its own internal routing and will "only" need to know two things: * where is the API the app should be talking to? * where are the vue.js source files and other assets located I also did not take a look how the Mojo API is connected with the rest and if / which paths need to be adapted there (though as Mojo provides `uri_for` I assume it will be simple)
I'd love to get rid of "/cgi-bin/koha" one day in any case, since it's a holdover from decades past...
Yes, if we generate links via a function, we could easily get rid of `/cgi-bin/koha` in the same go :-)
Ultimately, I think only the RM can answer this one.
And how can I get the RM to think about this issue, so we might get an answer (sorry, I'm still not that integrated into the Koha community..) Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
participants (2)
-
dcook＠prosentient.com.au -
Thomas Klausner