Comment 7 for bug 1552409

I'll admit that I hadn't considered privacy tools that block sending of the referrer. I'm sure the number of options to do this is high, I'm not sure what the actual adoption level is. I consider myself fairly tuned into privacy issues and this isn't something I've considered doing. That said, I do think this is an important issue and, if possible, we should make an effort to detect if this is happening by adding a check to the referrer page that checks for the existence of the header from the initial click and/or login form. I'm sure there are other/better solutions, so we should discuss.

The issue of this being easily spoofable doesn't seem like something we should be overly concerned about. This is an inherently insecure method, and the vendor knows it. In fact, I've had a discussion with another vendor (who doesn't even require the referring page to be behind a login) and expressed my shock that they'd even allow it. They realize that this is a method to keep honest people honest. Adding another layer of obfuscation and another redirection seems to me like upgrading your bike security by going from this: http://i.imgur.com/7ezRPCE.jpg to this: http://gallery.roadbikereview.com/data/roadbike/500/bike-lock.jpg

So, if we're going to do referring URL, then I'm happy with what Blake's put together. At least, the broad strokes. It sounds like the specifics of the implementation could be improved.

When we started talking options here, I had mentioned the blue sky idea of adding a Proxy/URL-Rewriting feature to Evergreen. There's another software out there doing a bang up job of this already, which many (many, many) libraries are paying for in addition to their ILS. I think this would be a better solution overall as it's more secure and a more widely supported method. Obviously the complexity is much greater - but I wonder if it's a discussion worth having whether or not we move forward with the redirection method Blake has put together.