Item8917: odd recurring login screen

I have a test web which contains an ALLOWTOPICVIEW setting set to a group that does not exist (copied from another site

when I log in as admin I can view the topic i request. When I then try to refresh, or navigate to another topic in that web, I get a 302 http status, and then get redirected to the login screen - from which I log in, successfully see that topic, and we go again.

I'm _reasonably certain that my setup is quite normal - but obviously is needs reproduction (I suspect this might be related to the other group security issue i reported the other day.

-- SvenDowideit - 16 Apr 2010

yes, removing the Group reverts the wiki to the expected function.

-- SvenDowideit - 16 Apr 2010

For what it's worth, it's as if sessions are being invalidated sometimes for me too (when trying to do something the user has no privileges for). I'll try to come up with something reproducable.

-- PaulHarvey - 17 Apr 2010

Nothing to do until this can be reproduced reliably.....

-- CrawfordCurrie - 18 Apr 2010

My dev wiki (which uses custom natskin, among other things) reports Foswiki-1.1.0-dev, Fri, 02 Apr 2010, build 7038, Plugin API version 2.1

svn is at distro:c4483c763879

• Create test topic in sandbox
• Save (autoinc gives us a real topic name)
• edit
• save
• browser back button
• save
• CSRF confirmation screen
• login prompt

Unable to reproduce on trunk.foswiki.org. About to check if this happens on a clean trunk svn install.

-- PaulHarvey - 19 Apr 2010

Confirmed on a clean trunk install with NatSkin + deps: but this does not happen with pattern, default or widgets.

-- PaulHarvey - 19 Apr 2010

I get this on Widgets ( and on 1.0.9) - but even better, I've worked out what is causing it.

on my system, I have ErrorDocument 404 http://somserver/bin/viewfile and I have some missing images - when it goes this way, a fresh cookie is produced - presumably because apache isn't sending through the cookie stuff...

disabling that, appears to solve the loss of session.

however this may be a separate issue from the original report - i'll have to test that too.

-- SvenDowideit - 19 Apr 2010

Great find, I'm also using the viewfile as an ErrorDocument. That explains a lot. Perhaps we should document that somewhere.

-- PaulHarvey - 21 Apr 2010

only if we can't fix it

-- SvenDowideit - 21 Apr 2010

OK, step by step.

1. Reproducing the original conditions Sven described, I cannot replicate this.
2. It may happen with NatSkin, but that's not a release blocker
3. Which leaves the images protected by viewfile - which I can't replicate either. "presumably because apache isn't sending through the cookie stuff..." - do you mean you think that the 302 isn't inheriting the cookies from the original request? What makes you think that? Wiresharking strongly suggests otherwise.

This needs a lot more information on how to replicate it before it can be confirmed.

-- CrawfordCurrie - 28 Jul 2010

If a bug is so hard to trigger that our best coders cannot reproduce it since April, then it cannot be an urgent bug. I am downgrading to Normal

-- KennethLavrsen - 19 Aug 2010

Need to test if the fix mentioned in Item10147 fixes this too.

-- PaulHarvey - 11 Dec 2010

I have been seeing trunk continue to do this on occasion. Still trying to isolate it.

-- PaulHarvey - 14 Mar 2011

Okay, I'm 99% sure my login problems are due to something to do with Item1636, where the authenticated https user accidentally gets taken back to the http site (which trashes their session cookie). Proposing a solution at Development.ConfigurableCookieNamesAndPaths

-- PaulHarvey - 10 Apr 2011

Commenting is disabled while not logged in