Page MenuHomePhabricator

SessionManager is breaking SecurePoll's use of sessions
Open, LowPublicBUG REPORT

Description

Sometimes a user cannot vote on an election.

They see the message:

You must log in to vote in this election - please try following the link from your Special:SecurePoll on your local Wikimedia site.

This seems to be intermittent. If the user tries again, they are often successful.

Possibly related log message:

Error
normalized_message
Session "{session}": Metadata has an anonymous user, but a non-anon user was provided
exception.trace

From page https://vote.wikimedia.org/wiki/Special:SecurePoll/vote/1101.

It looks like SessionManager is breaking SecurePoll's use of sessions, since 2018 a8d30a7667e92a196e1b7623d9a45a103081ef25. Presumably the cookie dup feature is also broken. Session manager will refuse to load the session data due to a user ID mismatch, but SecurePoll actually wants to see the user ID mismatch. I guess it just needs its own cookies.

Event Timeline

+1 on this. I have seen this twice today.

This happened to me in the past, usually because I was already logged in on votewiki - not sure if that's the cause? In that case, the system gets confused, logs me out on votewiki, so I just hit back and proceed again and can vote normally.

tstarling renamed this task from SecurePoll: Session "{session}": Metadata has an anonymous user, but a non-anon user was provided to SecurePoll: You must log in to vote in this election.Aug 16 2021, 12:40 AM
tstarling updated the task description. (Show Details)

It looks like SessionManager is breaking SecurePoll's use of sessions, since 2018 a8d30a7667e92a196e1b7623d9a45a103081ef25. Presumably the cookie dup feature is also broken. Session manager will refuse to load the session data due to a user ID mismatch, but SecurePoll actually wants to see the user ID mismatch. I guess it just needs its own cookies.

I think as @jrbs says, if you're not logged in on votewiki, it should work. If someone notices this happening when you're not logged in, please report the details.

tstarling raised the priority of this task from Medium to High.Aug 17 2021, 12:14 AM

I noticed this myself, and I was able to reproduce it with curl. I think it is a race between session creation in the POST request and session existence in the subsequent GET request. Reproduction is reliable using curl -L to request the login page, with curl running on mwmaint2002 to reduce latency. I reproduced it 3 times in 3 attempts that way. It's not multi-DC, maybe just a post-send update?

tstarling lowered the priority of this task from High to Medium.Aug 17 2021, 12:52 AM

Never mind, I just neglected to use --cookie-jar. I confirmed in the debug log that session writes are apparently correctly ordered.

Niharika renamed this task from SecurePoll: You must log in to vote in this election to SecurePoll: You must log in to vote in this election [Timebox: 8h].Aug 18 2021, 4:15 PM
jrbs lowered the priority of this task from Medium to Low.Jul 30 2022, 12:28 AM

Boldly lowering the priority. This should only impact people who have an account and are logged in on votewiki, which is deliberately a very small pool of people.

Evaluation:

Probably complicated, as involves SessionManager. TS suggests changing the cookie handling in general. Task description says this is timeboxed anyways, so we can just try

jrbs renamed this task from SecurePoll: You must log in to vote in this election [Timebox: 8h] to SessionManager is breaking SecurePoll's use of sessions.Feb 15 2023, 8:01 PM
jrbs updated the task description. (Show Details)

(Removed the timebox since it's a holdover from AHT's work on SecurePoll)