thor.malmjursson wrote:

Cropped image showing login error @ en.wikinews.org

Attached:

Is this issue still present?

thor.malmjursson wrote:

I haven't seen it for about 24h, Siebrand. Last occurence was 25/4 at 15.20 UTC+1 on a different OS, different browser - Opera Mobile 10.0.154, via Windows Mobile. Still Windows mind... Just wonder if there's a possible fix on the horizon.

thor.malmjursson wrote:

Unable to reproduce again now for over 72 hours. Bug closed as invalid by reporter. Any further occurrences found by other users can be attached here, and the bug could be reopened.

thor.malmjursson wrote:

Had to reopen, bug generated again, this time from my personal PDA, Nokia E71, running Opera Mobile. This is a symbian based OS, Series 60, so I am now stumped for a link as to any possible reason for it's occurrence.

This is most likely due to the login CSRF fix. Tim, could you look into this?

Form login has a relative url (action="/w/index.php?title=Special:UserLogin&action=submitlogin&type=login") and I don't see any item loaded from en.wikipedia.org either (an aggresive preloading of the page links?).

Perhaps some apache / squid is still serving a tokenless page?

Abigor wrote:

I had this error also on the dutch wikipedia last week, refreshing and a purge fixed it for me.

maybe a good note, but it happend after a was logged out, I was working just on the wiki and while I tried to safe the page I was logged out and couldn't login.

thor.malmjursson wrote:

Been a while, but I'm afraid it's back again. Appeared this morning on my Windows XP Pro (SP2) machine at home. Same error as above, so I'm at a loss. I last saw this almost a month ago, and I logged in and out last night with no issues.

Could someone please check this again, and see if a valid fix is possible, or at the bare minimum what can be done to circumvent it in the meantime?

Abigor wrote:

I have done some work and I can cause the bug.

i have a wikifarm with two squid servers. When I reboot one squid people will start seeing this error.

I have tried it on a single machine wiki also and when a kill memcache and restart it the error shows up to people.

So is it possible to check if we had memcache problems or a squid problem in the given time-line cause that would mean that this is the way to reproduce

Killing a memcache loses all sessions set, including login error and messages of "session lost" on edit.

Tim restarted srv194 memcached two day ago since it was giving problems, "there's a memcached server that's broken, mctest.php shows it". Maybe it giving problems again.

It turns out that mctest.php shows random failures, maybe 1 in every 1000. I'm not sure why it happens but it's probably unrelated to this bug.

Changing component, most likely site-specific rather than a software issue.

thor.malmjursson wrote:

Thanks for all your efforts up to now, I've noticed this happening less and less, unfortunately - it's just happened again, when I tried to log into the Norfolk and Pitcairn Wikipedia (pih.wikipedia.org).

I'm using Safari 5.0, unmodified from installation (other than a Flash Player plugin from Adobe), on Windows XP Pro, Service Pack 3.

Cheers guys.

TAM

sajuka.gentoo wrote:

Well i seem to have this error constantly

However on below page its suggest it might have something to do with local IP address, but I'm in the dark as to where or if even how to resolve such an issue...
http://code.google.com/p/lesswrong/issues/detail?id=230

(In reply to comment #15)

Well i seem to have this error constantly

However on below page its suggest it might have something to do with local IP
address, but I'm in the dark as to where or if even how to resolve such an
issue...
http://code.google.com/p/lesswrong/issues/detail?id=230

Sounds like a separate issue since, I'm pretty sure no one is logging into wikipedia/news/etc from a local IP address.

(If its for your own website, and happening to everyone, then the error your describing is commonly caused by php session options being mis-configured)

Sajuka, do you have cookies enabled?
(next version will mention cookies in the message)

sajuka.gentoo wrote:

Thanks for the replys and it was the cookies not being enabled that handed out this error to us...

hieulugia+mw wrote:

i'm able to reproduce this bug on www.mediawiki.org:
Here are the steps:

• login to the site as user A
• logout, select the login link at top right
• select send new password button, retrieve the password from email, and type in the password, click login, the session hijack will show up.

work around:

• paste the password in again, and select login, it should success on the 2nd time
• or completely close the browser, and launch new instance of the browser

hieulugia+mw wrote:

www.mediawiki.org hijacking session error

Attached: