Plack Middleware to isolate library branches via path
Hi! A customer wants to access branches/branchgroups via a subpath, instead of the more common / documented way of setting up a subdomain per branch: https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config So instead of https://aaa.library.example.com/ they want https://library.example.com/aaa/ (for ~10 branches) This boils down to: - matching the path and munging the URL - setting some ENV vars (OPAC_SEARCH_LIMIT, OPAC_CSS_OVERRIDE, etc) - munging the HTML generated by Koha to fix the links While this could be implemented via carefull application of various Apache modules (mod_proxy, mod_rewrite, mod_proxy_html) I feel more comfortable implementing this in Perl in a Plack Middleware. The result is not very pretty, but seems to work (see attached code...) But to load the middleware, I have to enable it in /etc/koha/plack.psgi and thus change a core file (or copy upstream plack.psgi and edit the copy, which still means that we'll have to apply our changes after each update) In theory we could add some config to load custom Middlewares, but as the load order of Middlewares is very relevant, this seems hardly doable - unless we start with one middleware config slot at the location I need :-) Anyway, I think we'll just go with maintaining a custom plack.psgi, unless anybody here has any other ideas / best practices / solutions on how to mount library branches at location/sub-dirs... I'm also not sure if this feature is on any roadmap etc. Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Hi Thomas, The timing of your email is interesting! I was just reflecting the other day about how Koha can't work off anything but the root path. However, it's not something that I'm likely to ever work on, as the subdomains work fine for us. (Although self-checkout URLs using branch-based paths could be very useful for us.) I have a Catalyst app where I use the out of the box method $c->uri_for which constructs an absolute URI using the application root (e.g. /aaa/), but that would require rewriting Koha's templates. I use that same strategy for some of my other web apps, which lets the deployment be quite flexible. (In the case of Catalyst, it auto-detects the path based on the location of the controller. With CGI apps I have, I rely on a configuration variable.) With your solution, how do you handle Javascript navigation that doesn't necessarily rely on HTML? (I can't think of any examples off the top of my head but I'm sure they must exist, although perhaps only on the Staff Interface...) 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: Tuesday, 19 April 2022 10:13 PM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] Plack Middleware to isolate library branches via path Hi! A customer wants to access branches/branchgroups via a subpath, instead of the more common / documented way of setting up a subdomain per branch: https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config So instead of https://aaa.library.example.com/ they want https://library.example.com/aaa/ (for ~10 branches) This boils down to: - matching the path and munging the URL - setting some ENV vars (OPAC_SEARCH_LIMIT, OPAC_CSS_OVERRIDE, etc) - munging the HTML generated by Koha to fix the links While this could be implemented via carefull application of various Apache modules (mod_proxy, mod_rewrite, mod_proxy_html) I feel more comfortable implementing this in Perl in a Plack Middleware. The result is not very pretty, but seems to work (see attached code...) But to load the middleware, I have to enable it in /etc/koha/plack.psgi and thus change a core file (or copy upstream plack.psgi and edit the copy, which still means that we'll have to apply our changes after each update) In theory we could add some config to load custom Middlewares, but as the load order of Middlewares is very relevant, this seems hardly doable - unless we start with one middleware config slot at the location I need :-) Anyway, I think we'll just go with maintaining a custom plack.psgi, unless anybody here has any other ideas / best practices / solutions on how to mount library branches at location/sub-dirs... I'm also not sure if this feature is on any roadmap etc. Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Hi! On Wed, Apr 20, 2022 at 10:56:36AM +1000, dcook@prosentient.com.au wrote:
The timing of your email is interesting! I was just reflecting the other day about how Koha can't work off anything but the root path.
:-)
I have a Catalyst app where I use the out of the box method $c->uri_for which constructs an absolute URI using the application root (e.g. /aaa/), but that would require rewriting Koha's templates. I use that same strategy
Most web frameworks and/or router implementations provide methods to generate links, and those methods should honor HTTP headers like X-Forwarded-For etc. I usually use Plack::Middleware::ReverseProxyPath https://metacpan.org/pod/Plack::Middleware::ReverseProxyPath which uses X-Forwarded-Script-Name and X-Traversal-Path to allow for a very flexible setup, if the apps/routers used support those headers to generate links (Catalyst does, AFAIK) But I guess the reason that Koha cannot use somethink like this is that it generates a lot of links via literal strings in the templates. And changing this to use a method/function would be a lot of work! Which is why I choose the rather ugly and probably not very stable approach to fix (hopefully..) the generated URLs after rendering using a regex...
With your solution, how do you handle Javascript navigation that doesn't necessarily rely on HTML? (I can't think of any examples off the top of my head but I'm sure they must exist, although perhaps only on the Staff Interface...)
Currently we don't, but the users are as of now only starting to test the path-based branches. We'll see what problems they'll encounter. And we're only using this branch separation on the OPAC. Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
participants (2)
-
dcook＠prosentient.com.au -
Thomas Klausner