Okay, and UserSessionScratch, too.  It turns out that WebGUI will look for a scratch variable called redirectAfterLogin, and if it is set, it will redirect you to that page after logging in.

And, of course, after redirecting it will erase itself from the scratch table, erasing all traces of itself.

I don't suppose you use WebGUI's Commerce on your site? 

Today this happened again, when  I was switching browser to IE. So this time I logged in at /site/test and landed at uploads/kP/g9/kPg9nhxAugsePAZpczPf4w/very_much_confidential.pdf

Since I am admin I do not mind but would a non authorized user be able to see this file (.wgaccess)? 

Back to the case; it turns out that I do have a session but I do not have any post in userSessionScratch. My guess is that someone else has read this file

I clicked around on the site but no post in scratch table.
Actually I do not get a post in userSessionScratch until I made a search for a user in admin console! 

Maybe this information could be helpful...

/Erik 

I can reproduce this bug regularly on my site -- it is due to the way redirectAfterLogin is handled.  The basic idea to reproduce is to go to a restricted page as Visitor, but don't log in.  Go to another restricted page and login there.  You will be redirected to the first page.  Here is a way to replicate the bug on plainblack.com (though I admit this path is unlikely for a user of plainblack, on other websites with more restricted content this does really happen):

1. Go to  http://www.plainblack.com
2. Log out
3. Go to:  https://www.plainblack.com/plain_black_support
4. Do NOT log in. 
   
5. Go to: https://www.plainblack.com/webgui/dev/discuss?func=add;class=WebGUI::Asset::Post::Thread
   
6. It should say Permission Denied.  Click on: log in with an account
7. Log In.
8. You should find yourself on the plain_black_support page now.

Note if you have trouble replicating this, try clearing your browser cache first.

This bug can be traced to Auth.pm where displayLogin contains the code:

# Automatically set redirectAfterLogin unless we've linked here directly
	# or it's already been set.
	unless ($self->session->form->process("op") eq "auth"
		|| $self->session->scratch->get("redirectAfterLogin") ) {
	   	$self->session->scratch->set("redirectAfterLogin",$self->session->url->page($self->session->env->get("QUERY_STRING")));
	}

Note that since redirectAfterLogin was set the first time we got a login prompt, it doesn't get reset the next time.  I would say the fix is just to remove that OR part of the conditional, but I expect it is there for a reason that I don't understand.  One clue is that Operation::Commerce.pm sets redirectAfterLogin too.  Hmmm.