FS#12898 - Some aur tools might create multiple sessions.

Attached to Project: AUR web interface
Opened by Loui Chang (louipc) - Friday, 23 January 2009, 06:24 GMT
Last edited by Lukas Fleischer (lfleischer) - Wednesday, 09 March 2011, 17:14 GMT
Task Type General Gripe
Category Backend
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Architecture All
Severity Low
Priority Normal
Reported Version 1.5.4
Due in Version 1.8.1
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I noticed a user with five sessions on AUR.
He was using yaourt to vote for packages.
This task depends upon

Closed by  Lukas Fleischer (lfleischer)
Wednesday, 09 March 2011, 17:14 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 1.8.1.
Comment by Loui Chang (louipc) - Thursday, 19 February 2009, 04:29 GMT
Hmm there are a couple ways we could help deal with this:

1. If there are already say two sessions, and a third one is attempted
we can destroy the two old ones and acknowledge a third new one.

2. We can deny more than two, or maybe three sessions to encourage
clients to properly log out, or save their cookies.
This method could create an issue if the session is a 'remembered' session.
So we should only deny if there are more than two 'non remembered' sessions.
Comment by Laszlo Papp (djszapi) - Tuesday, 15 December 2009, 04:04 GMT
Does AUR work fine in this regard its own way without using these tools ? In case yes it's not worth for AUR to adapt to these 'unsupported tools'.
Comment by Lukas Fleischer (lfleischer) - Sunday, 20 February 2011, 21:08 GMT
Imho, we don't need to deal with this as long as we have the "$LOGIN_TIMEOUT" setting in "web/lib/config.inc". Remaining sessions from clients not logging out properly will be deleted automatically after some time, so what's the big issue here?
Comment by Loui Chang (louipc) - Monday, 21 February 2011, 16:00 GMT
Hmm it was more of a general gripe when I documented this, but now I'm thinking it could be a DoS
attack vector. It's possible that the database could be overloaded with sessions long before the
login timeout. I haven't really tried it though.

A proposed solution would be to set a max_sessions_per_user parameter.
Drop all sessions if max_sessions_per_user is exceeded.
Comment by Loui Chang (louipc) - Monday, 21 February 2011, 16:03 GMT
Ah there's also remembered sessions which don't obey the login timeout.
Heh. They're also not configurable from config.inc.
That should be changed.
Comment by Lukas Fleischer (lfleischer) - Monday, 21 February 2011, 18:29 GMT
I don't think we need this. How about users with a huge number of desktops? Say, four machines at home, two at work and one at ones girlfriend - accessing the AUR from all of these machines with the "Remember me" setting enabled. Additionally, running some AUR helpers on all four machines at home simultaneously. That'd mean 11 sessions for this user. How do we distinguish that from a "DoS"?
Comment by Loui Chang (louipc) - Monday, 21 February 2011, 23:27 GMT
That kind of sounds like a corner case. That isn't you is it? hehe
Would it be wrong to ask/expect such a user to reuse some sessions?
Comment by Lukas Fleischer (lfleischer) - Tuesday, 22 February 2011, 09:28 GMT
Nah, I don't use AUR helpers :p What would be a sane default value here? 8?
Comment by Lukas Fleischer (lfleischer) - Wednesday, 23 February 2011, 10:28 GMT
  • Field changed: Due in Version (Undecided → 1.9.0)
Implemented [1].

[1] http://projects.archlinux.org/aur.git/commit/?id=f961ffd9c7f2d3d51d3e3b060990a4fef9e56c1b

Loading...