>>>>> "ST" == Stephen Turner <[email protected]> writes:
ST> I am the upstream author. I tend to feel that the fault is in the ST> browser for retaining sensitive information in the referrer. But in ST> any case, you can use analog's REFALIAS command to modify the ST> referrer and remove the information. Such password containing URLs can and have appeared in any section of the Analog report where URLs appear, not just referral sections. All they have to do is somehow appear in the Apache etc. logs, thus the browsers, which we have no control of anyway, are not always to blame. One could say that Apache is to blame for putting them into logs, but it is only reporting what URL failed that day (though it worked the next...) and those logs are in a secure area (at least on Dreamhost, where one person can see them vs. Analog reports that a team can see, though yes, not the whole world.) Anyway, my main point is the Analog configuration is very often highly restricted by ISPs in what one can adjust. And only a few items can be changed, and only through a "panel". Therefore zapping such sensitive parts of URLs should be the new Analog default, and passing them through unscathed should be a configuration item, default zap=yes. So the should look like http://[username:[email protected]/bla instead of the actual details. The href should just be example.com/bla . -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
