A new request with request id 7851 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is :

Title : Koha-devel Digest, Vol 201, Issue 13
Category :
Description :
Send Koha-devel mailing list submissions to
    koha-devel@lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
    koha-devel-request@lists.koha-community.org

You can reach the person managing the list at
    koha-devel-owner@lists.koha-community.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."


Today's Topics:

1. Serving Intranet from a subpath (Thomas Klausner)
2. String Freeze Notice for 21.11.11 (Arthur)


----------------------------------------------------------------------

Message: 1
Date: Fri, 12 Aug 2022 12:54:59 +0200
From: Thomas Klausner <domm@plix.at>
To: koha-devel@lists.koha-community.org
Subject: [Koha-devel] Serving Intranet from a subpath
Message-ID: <20220812105459.GR864217@plix.at>
Content-Type: text/plain; charset=us-ascii

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$_.$/}


------------------------------

Message: 2
Date: Fri, 12 Aug 2022 13:23:48 +0200
From: Arthur <arthur.suzuki@biblibre.com>
To: koha-devel@lists.koha-community.org
Subject: [Koha-devel] String Freeze Notice for 21.11.11
Message-ID: <297b439c-f789-daf1-eddb-804d6e495456@biblibre.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hello folks,

String freeze will go into effect as of today for 21.11.11 release.

Maintenance release scheduled for the 22 of this month (not next monday
but the one after).

Best,

Arthur Suzuki

Developer @BibLibre, Old-stable branch maintainer.




------------------------------

Subject: Digest Footer

_______________________________________________
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/


------------------------------

End of Koha-devel Digest, Vol 201, Issue 13
*******************************************


NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.