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

Bug #1593300 reported by Jeff Godin
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Jeff Godin

Bug Description

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.

Revision history for this message
Jeff Godin (jgodin) wrote :

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.

Revision history for this message
Bill Erickson (berick) wrote :

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.

Revision history for this message
Terran McCanna (tmccanna) wrote :

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

tags: added: cleanup
removed: webstaffclient
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers