Re: notes and all that

I just found out that Opera allows you to not send HTTP_REFERER as part of the user agent response. (presumably the same goes for the GTK 1 browser you mentioned?). Apparently some firewalls also block it. I still think refusing to send a referer string is a design flaw on the part of browsers (and firewalls). If the devs were going to do that as a security/privacy measure, they could've at least allowed referers through when the referer base matches the base url on the current site. As it is, we're potentially looking at quite a number of our site users not being able to add to manual notes when they try. :-( There are three possible 'fixes' I can see to allow for this horrible behaviour. One would be to use javascript and call history.go() - but you can bet your boots that anyone paranoid enough to turn off referer logging will also have javascript support turned off. Another way would be to send the name of the referring page as part of the query string, which is a) ugly and b) means the GET var needs validating at the receiving end. The third would be to store the name of the referring page somewhere it can be retrieved, e.g. a cookie or session. None of these solutions are good, and whichever way we choose there's no way to know whether the browser's going to send a referer string until the original page is history. Even if firewalls weren't an issue, Opera offers the option to disguise its user agent string as something else. So... what I'm sketching out here is this: Check PHP_SELF at source. (I've already done this on the live site by cleaning it in the auto-prepend file, but we'll see what Rasmus and his Famous Tool [TM] have to say about that) Where possible, send PHP_SELF as a parameter (either directly to a function or as a hidden form element). Check whether HTTP_REFERER is set and, if not, regard it as '/' in most cases (i.e. logout and when the access level is breached) or take a wild guess at where the user should have come from (generally, admin-login). Having done that, the only problem page remaining in the entire notes system should be add-note.php itself, which should (theoretically at least) only ever be reached via the links to it on the manual pages. The kindest thing I can see to do at that point would be to give a lengthy sermon on how wonderful HTTP_REFERER would be if only the user had one, and ask them to either enable it (which ALL referer blockers give the option to do) or hit their back button so we can pick up the info via PHP_SELF and maintain state in one of the three ways outlined above. The other alternative is to inflict a nasty workaround on _all_ users - this on every page of the manual - with GET being the simplest and cheapest of the options available to us. Thoughts, anyone? - Steph

Docteam regulars should be able to get into the 'test' area without any problem, but nowhere else restricted. If you find you can reach something you shouldn't be able to reach, please let me know(!). Also if you can't reach something you think you should be able to, of course.

1. The admin-login page misses a no-cache meta tag - it stays in cache, and I always need to reload it to see my login or logout. 2. When passing the wrong un/pw combination, a white page is shown. I'd prefer a "Haha! Go spooking elsewhere" or something, so that you know that the system did something instead of crashing silently. 3. Accessing info.php without a cookie returns a UTF-16 file. Wait, that is generated by opera. It does redirect one to somewhere "" (empty)? Seems as that happens with all admin pages without a cookie. Perhaps some more, I'll see -- Regards/MfG, Christian Weiske __________ NOD32 1.1380 (20060125) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com