Apache OpenOffice (AOO) Bugzilla – Issue 26081
projects' documents & files new since last upgrade require cookies
Last modified: 2005-08-01 14:56:35 UTC
Project files updated or added to the projects' documents and files sections since the last hdwr upgrade where the site was down for a couple of days (i think this is the timing, but i may be wrong) are not accessible. If you click on links to these files, they are redirected several times until a failure occurs due to too many redirects. My browser info was grabbed automatically, is shown below (in bug cgi form) and is correct. Files attached prior to the upgrade are accessible. This can be seen best at the bizdev project, where the two earliest (datestamps) files are accessible, and all others are not. It is also visible at the qa project, where ja's statistic file, which is updated regularly, is not accessible, but others listed there are obtainable. Because it is visible at two projects, I am assuming that the issue is site wide.
Does the auto-detected browser info really show somewhere on this issue? I cannot see it anywhere. I am running mozilla 1.2.1 on rh9 linux.
Diane, Before I forward this to CollabNet support... are you still experiencing the issue? louis
Hi Louis, I am. But I tested a bit further and learned that the newer files require cookies to view, but the older files do not. If cookies are accepted, all works as expected. If cookies are not enabled, it works as described in my first entry on this report. Kinda interesting. Hadn't picked up on this earlier. Diane
Changed the summary. Not sure which upgrade caused the change, but suspect it was one of them, without digging into an actual border in the file datestamps between files that work and files that do not, so made that part more generic. Also changed definition of behaviour from "not accessible" to "require cookies". Many folks surf the internet with cookies disabled. I am one of them. I run into folks that need this clue to edit issues too. Enabling cookies for sites is sorta treated like "special handling" for many surfers. I think it is likely that more folks would browse the files & documents, if cookies were not required. I also think that browsing the site should be encouraged as much as possible. I would like to suggest that cookies not be required for viewing or download of project files. In some places, such as the issue tracker, or places where viewer input is used, it is understandable why cookies might be required. But to only view pages, it feels more like a tracking mechanism than a necessary tool. If you have ever surfed with cookies enabled and no cookie manager you would very soon understand why cookies are viewed this way.
Diane Hm. My understanding is that for the interactive elements of sourcecast (eg, file downloads) to operate as expected cookies must be enabled. We understand that many surf with cookies disabled; but early on in OOo's history, it was decided that requiring cookies was acceptable. The cookies are more than a tracking mechanism--I for instance, don't track via cookies at all. They are, rather, a sort of shibboleth that allows us to build the site for both members and not. Unfortunately, all things like the downloads, etc., are now in the members' category, and it would be difficult to move them out. louis
fair enough. looks like i no longer have power to close this issue as invalid, or i would.
hm. maybe you should also ask for content developer privs in qa? anyway, resolving it for you, Louis
closing resolved (invalid) issue.