CSRF error on login

[rjmackay]

The login form always returns a CSRF error when loggin in from the popup login form on the main page.

[rjmackay]

It looks like the CSRF token gets cleared before the login controller loads, not sure why yet

[rjmackay]

Weirdly I can't reproduce this anymore.. Closing it unless I see it again

[heatherleson]

Received this error on 2.6.1 for the HHI SIM. It should be reopened.

The error: http://dl.dropbox.com/u/34693557/Screenshots/9n.png
Using Firefox

It is on the latest version:
{"payload":{"domain":"http://hsi2013.standbytaskforce.com/","version":[{"version":"2.6.1","database":"102"}],"checkins":"0","email":"no-reply@standbytaskforce.com","sms":"","plugins":["densitymap","frontlinesms","mapbox"],"features":{"admin_reports_v2":true,"api_key":false,"jsonp":true}},"error":{"code":"0","message":"No Error"}}

Details:

1. attempted login with email address x 2
2. when it did not work, I clicked password retrieval. it gave me this page - http://dl.dropbox.com/u/34693557/Screenshots/9n.png

Notes: One other person on the sim also received the same error

Actions:
User creates their own account
Superadmin upgrades them to a role
user then trys to login, gets error.

[heatherleson]

More details. Reset password won't work. I can't actually login with the account I created.
Note- unchecked 'save password'. Had someone verify my username heatherleson@gmail.com is correct. tried again.

There is a message in the bottom left hand screen with 'javascript:toogle ('sign script'); Loop.

[heatherleson]

The deployment : http://hsi2012.standbytaskforce.com

The project Superadmin set up another account for me hleson@ushahidi.com. Attempted login via firefox after closing browser, new session. No luck.

Chrome attempt

1. tried to login via dropdown in left hand screen, it circled me back to a main login screen and did not log me in. http://dl.dropbox.com/u/34693557/Screenshots/9o.png (unchecked the save password option)
2. the tool simply loops and kicks me back out to a blank login screen

So I was unable to login via Chrome.

Back to Firefox:

the superadmin gave me this detail - http://dl.dropbox.com/u/34693557/Screenshots/9p.png from the admin dashboard.
Full Name Required Heather Leson
Email Required hleson@ushahidi.com
Role ADMIN
Public Profile URL Required
http://hsi2013.standbytaskforce.com/profile/user/heather
Receive Notifications? YES

When I clicked on http://hsi2013.standbytaskforce.com/profile/user/heather, I was able to login (on firefox)

Conclusions:
the login issue is not just Crowdmap, but Ushahidi platform too. There is something in the id and user setup that causes a login loop.

[aoduor]

has this been tested in 2.7b?

[rjmackay]

@aoduor I've never found a reliable way to reproduce it on 2.6 so no haven't tested on 2.7.
CSRF checks are entirely disabled for the login for so I'm not sure how this is triggered. Makes no sense, except that it happening so I'm missing something

[aoduor]

I'm completely at a loss - pinging @srutto can you help us test this?

[aoduor]

Also, @heatherleson which version of firefox/safari/chrome are you using?

[rjmackay]

@heatherleson can someone from the HSI sim send us a copy of their application/config/cookie.php and application/config/session.php ?
I'll compare against core and crowdmap.. slight hunch this could be something to do with session getting dropped between requests.

[aoduor]

May have narrowed this down to a problem with outdated versions of browsers (just a hunch)
Safari
I've tested on Safari v6.0.4(latest), and works fine. One user experiencing this issue is using Safari v5.1.7. Waiting for her to upgrade to test this theory

Chrome
One user upgraded to latest version of chrome i.e v26.0.1410.65 (which I'm using), and the problem disappeared.

More soon, as this continues to unfold

[heatherleson]

My browser is always up to date- firefox 2.0
(auto-updated)

[heatherleson]

sent a note to the HHI Folks to collect details.

[aoduor]

Have you tested this in the past week? Do you mind testing it for me now with this version :)?

[heatherleson]

Firefox 20 release April 4 - https://wiki.mozilla.org/RapidRelease/Calendar
HHI Simulation - April 26th - 28th, 2013 https://sites.google.com/a/standbytaskforce.com/sbtf-hsi-deployment/

I am on auto upgrade. So during the simulation, I was on the latest FF version

I can open a stack of windows, deployments and test. but I am unsure that the browser version relates to this cache/security notice. Happy to test

[aoduor]

From my investigation - it is a possibility. Would really appreciate it if you could test!

[rjmackay]

OK. So I've found a login issue with the hsi2013 site. Login at
http://hsi2012.standbytaskforce.com/index.php/login is NEVER going to work, because real url is
http://hsi2013.standbytaskforce.com/index.php/login and the cookie config is set up to use "hsi2013.standbytaskforce.com". This is sensible and a better security config.
However they're still using both the 2013 and 2013 domain. I wonder if that could be part of the issue?

Since this config means the session gets killed between EVERY request on hsi2012 - its possible it could trigger CSRF.
Heather could you retest with both hsi2012 and hsi2013 and see if you hit CSRF issues on 1 but not the other?

[dkobia]

@rjmackay @aoduor @heatherleson

I've been testing on WinXP with IE8, and my biggest suspect thus far is the user_agent re:

I'm realizing that there's the remote possibility that the user_agent is either changing or just null on some platforms.

@rjmackay -- I'm suggesting we disable user_agent checking altogether, and just have it as

$config['validate'] = array('ip_address');

[ghost]

HSI 2012 url was meant to be a redirect to HSI2013 site since I took the hsi2012 site offline.
However, people using the SIM were only instructed to use the HSI 2013 url.
Also the files are in your email @rjmackay @heatherleson

[rjmackay]

@dkobia putting ip_address back in is a bad idea. I removed that originally because users were having issues any time they switched locations/connections since their IP changed.
Expiration kinda needs to stay in their or session may not be expire properly.
User agent changing seems very weird, the browser should be sending a consisten value between requests. Can you check using something like Charles proxy to see if you user agent remains stable?

[aoduor]

Issue popped up for a deployer using Safari Version 5.1.7 (6534.57.2). Tested with current version (6.0.4) and it works fine..

[kamaulynder]

Closing this,open a new issue in case of anything.