After correcting registration errors, the redirect for strikeone validation sends the user to the bin/login screen.

My assumption is that the user should have been redirected to the strikeone validation, but preferably in this case, the user should not have been redirected at all since the instructions were to use the back button.

-- GeorgeClark - 17 May 2010

The login script is used to perform the strikeone validation rejection sequence, so I'd expect it to go to bin/login. Sounds like some parameters are not being passed on.... can you confirm this?

-- CrawfordCurrie - 23 May 2010

But prompting for the userid/password from a user who has not yet registered will be frustrating to users and doesn't make sense.

Here is the sequence again - (Ran svn update and re pesudo-installed the extensions)

HTTP/1.1 200 OK
Date: Sun, 23 May 2010 23:38:38 GMT
Server: Apache
X-Foswikiuri: /System/UserRegistration
X-Foswikiaction: view
Cache-Control: max-age=0
Set-Cookie: FOSWIKISTRIKEONE=19500705f172331f7f2ec2dbea96af4c; path=/

HTTP/1.1 500 Internal Server Error
Date: Sun, 23 May 2010 23:38:57 GMT
Server: Apache
X-Foswikiuri: /bin/register/Main/WebHome
X-Foswikiaction: register
Cache-Control: max-age=0
Set-Cookie: FOSWIKISID=db7d27c2ba43949dc43485a5072b9b83; path=/; HttpOnly

Message to user is: Incorrect WikiName? ... Please go back in your browser and try again

Twk1Confirm   
Twk1Email   
Twk1FirstName   bleh
Twk1LastName   blah
Twk1Password   
Twk1WikiName   BlehBlah
action   register
topic   DefaultUserRegistration
validation_key   0ae80b87e17c326247a1f782b78c0638

* Response is a 302 redirect

HTTP/1.1 302 Found
Date: Sun, 23 May 2010 23:39:14 GMT
Server: Apache
Set-Cookie: FOSWIKISID=db7d27c2ba43949dc43485a5072b9b83; path=/; HttpOnly
Location: http://xxxxxxxx/bin/login/Main/DefaultUserRegistration?foswikiloginaction=validate;foswikioriginalquery=cfa977b50a94e8356745eba61ee486dd
Content-Length: 0

Unfortunately I can't recreate this directly on trunk.foswiki.org, because any access to trunk requires login.

OK, what's happening here is that the initial topic that you are normally dumped into is protected, so requires a login to view. Item2497 added strikeone protection to the registration, but strikeone requires a logged-in user. So when the validation fails, it sees no-one is logged in and tries to get a user.

I can't think why I required an authenticated user during validation. CSRF has to be trapped when a user is logged in, but the protection doesn't actually require anyone to be logged in. I disabled the 'authenticated user' check and your registration case is fine now, but we need to be alert for other cases where an authenticated user is required.

-- CrawfordCurrie - 24 May 2010

 

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons LicenseGet Foswiki at sourceforge.net. Fast, secure and Free Open Source software downloads