Web staff client iframe URL generation can fail with hostnames starting with "eg" or "staff"

[Jeff Godin]

In several places within the web staff client, URLs for iframes are generated based on the current URL:

$location.absUrl().replace(/\/staff.*/, '/opac/advanced');

$location.absUrl().replace(/\/eg.*/, '/opac/extras/merge_template');

These replacements can fail on URLs where the hostname part begins with "staff" or "eg".

The most obvious symptom is that these interfaces fail to load, and if you dig into the matter, you'll see that the URL that the browser is attempting to load is https://opac/advanced/ or similar (using the first example above).

One option would be to use a pattern like /!\/\/staff.*/

Another option is to embrace the fact that we don't currently seamlessly/universally support changing the URL prefix /eg/ -- which is actually what some existing URL generation code in the web staff client already does, using a match pattern of /\/eg\/staff.*/

Working branch on that way.

[Jeff Godin (jgodin)]

I've revised some of my thoughts and will reflect that in the working branch and a followup comment -- but the pattern /\/eg\/staff.*/ without putting /eg/ or a match group in the substitution string will break in at least a few of these places.

[Bill Erickson (berick)]

I would be OK with embracing the use of /eg/. Ironically, it would probably be easier to modify a consistent, hard-coded prefix than the hodgepodge of prefix styles in use now. It would also simplify a lot of code.

[Terran McCanna (tmccanna)]

Is this still an issue with the move away from embedded frames?