URL modification with regular expressions can lead to 403 Forbidden errors

[Jason Boyer]

All web client versions affected.

As an example, when you search the catalog from the splash page the browser url is eg/staff/cat/catalog/results?query=testing, but looking at the console egEmbedFrameLoader logs the actual URL sent to the catalog iframe: eg/opac//results?query=testing. That 1 extra / isn't a big deal on its own, until you click the Next button and then get eg/opac//results/opac//results?query=concerto;page=1, which each click of the Next doubling the length of the URL that you can't see until the total length of the iframe URL is such that Apache will have no more of this nonsense and throw you a 403.

There are 2 issues that work together to cause this. The base issue is that the opac doesn't handle // correctly when building links, so each time you click Next you get twice as much /thats//weird/ as you had before. If it weren't for this doubling I doubt most people would ever notice it.

The issue that causes this initially in the web client is the use of regular expression replacement on a base URL of /opac/advanced (at least in staff/cat/catalog/app.js, there may be other causes). Because this: url.replace(/advanced/, '/results?') looks kind of like it takes 'eg/opac/advanced/' and changes it to 'eg/opac/results?' but is instead changing 'eg/opac/advanced' to 'eg/opac//results?' which then sets off the bug above.

It's easiest to see this at work in the regular OPAC by inserting an extra / before 'results' in your address bar and then pressing enter to load that URL. Click Next a few times and you too can watch it expand to fill your address bar and beyond.

Branch coming soon to address the AngularJS bits, I'm not sure how best to tackle the actual root cause.

[Jason Boyer (jboyer)]

Here's a small branch to prevent the staff client from potentially causing this in a couple of places: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1858701_so_many_solidus / working/user/jboyer/lp1858701_so_many_solidus

[Jason Boyer (jboyer)]

Steps to test:
pre-patch, type a search into the splash page search box and look at the browser console for the egEmbedFrameLoader log line where it shows the URL loaded in the iframe. It will look like /eg/opac//results?q=... Click Next a few times and watch the URL grow. Using the retrieve bib by id function can also cause this (/eg/opac//record/<id>), but since there are no next or prev buttons for a single record retrieval this is unlikely to ever result in a 403.

post-patch, perform the same steps as above and note that the url looks normal: /eg/opac/results?q... and you can click next and previous until your hand cramps up and not get a 403.

[Rogan Hamby (rogan-hamby)]

Works as expected. Signoff at: user/rogan/lp1858701_so_many_solidus_signoff

[Jane Sandberg (sandbergja)]

Thanks, Jason and Rogan! Pushed to master, rel_3_5, and rel_3_4.