UserSessionScratch is a table used to store data in your session inbetween page loads. So it's possible to have several entries in that table.

It would be much more interesting if you had multiple entries in the userSession table.

Actually, it would be interesting to see if you could show what's in your userSession entires before and after one of these mystery redirects. 

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? 

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

We do not use Commerce. The redirect occurs as I see it randomly, but there might be a pattern out there... 

/erik 

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've tried multiple times to reproduce this and have been unable to do so.  In order to rule out your server environment, I need you to duplicate this on a demo site.  Even if it's not reproducable over and over again, just telling us the steps you took to make it happen once on a demo may help.  If it is reproducable then that is  very very helpful.

Please duplicate on a demo site and re-open the bug if you can do so with a link to the demo and the steps you took.

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. 

Thanks for providing a way to duplicate this bug.  I've fixed it (and kept the Commerce system happy) by forcing redirectAfterLogin to be reset unless it contains an operation.

Tested on PB.com

Fixed in 7.3.14

SVN commit #3926