Re: Can we change auto-logout timing on wiki.postgresql.org?

On 05/03/2013 03:23 PM, Bruce Momjian wrote:
> On Fri, May  3, 2013 at 10:19:09AM +0200, Magnus Hagander wrote:
>>>>>> well from a security perspective it is usually advisable to keep session
>>>>>> lifetimes as short as possible, I agree that the current setup was way
>>>>>> to aggressive, but 6h already results in a 6-15x increase of what we had
>>>>>> before. We can always adjust upwards if we people are really working 6h+
>>>>>> on an article but lets see first if this change really fixes the issue
>>>>>> berkus complained about.
>>>>>
>>>>> This is a wiki, not a banking website.  We need to use security that is
>>>>> appropriate for what we are guarding.  We could just prevent edits and
>>>>> it would be even more secure.  ;-)
>>>>>
>>>>> I would like 7 days, myself.
>>>>>
>>>>
>>>> Yep, I mean really, it is a wiki.
>>>
>>> OK, please make it 7 days.  I keep the wiki tab open on my browser and
>>> having to log in every day is a pain.  Now, if you want me to stop using
>>> the wiki, I am happy to do that.
>>
>> Really, Bruce?
> 
> Yes, really.  I am not saying I will stop using the wiki, but it
> certainly would be nice if I didn't have to use the wiki because others
> used it more.  And the more cumbersome with wiki is to use, the more I
> would like to avoid using it --- that's just natural.  I would think we
> would have a setup to encourage people to use the wiki more by making it
> easier to use.

the huge success of MW as a basis for the likes of wikipedia does show
that it seems to be at least somewhat usable...

> 
> I moved to the wiki so others could update the TODO list, but history
> shows that I am still making the majority of the edits:
> 
>     https://wiki.postgresql.org/index.php?title=Todo&action=history
> 
> I do appreciate others making changes, but some of them are added
> without discussion, so they need to be reviewed.  However, I don't
> always get email when someone edits because of some logic that only
> emails me the first time, unless I go to the site, though I have the
> TODO list tab always open --- I never understood that.

well - the idea is that people do not get spammed if somebody does a
large amount of edits, the fact that you "always have the page open in a
tab" does not help there because that means you are not actually doing
an http-request to the page so mw will never notice you are actually
having it open (http is basically stateless).
The current behaviour makes a lot of sense for the general usecase
because this would actually cause a mail storm if say a bot does a ton
of edits (and we have spammers abusing our wiki going through the
actually signing up for a community account and abusing our wiki for
link-backtrack spam, so this is not a theoretical point).



> 
> There are other oddities, like many of the "Contents" links not working
> (e.g. "Montoring"), and broken output when links contain '=', so I added
> a cron job on my machine to check for them.

again this a MW thing - it would be useful for somebody doing the
research if this is fixed in a different version or if there is another
way around it.

> 
> I asked about this timeout issue over a year ago, and was told no one
> knew the cause.  Now that the cause was found, I am told that the
> administrators want to set a timeout that is less than any other
> non-commerce website I visit because of security.  To me that reflects a
> distorted view of usability vs security, and all for a wiki site.

sure it is "only" a wiki - but given we do also maintain more or less
official stuff there it needs to keep a certain reputation. your
specific usecase of always having a particular page open is rather
unique in the general sense and it is not and was never optimized from
both a MW and also a infrastructure pov.
Also - as far as I see we have never gotten feedback if the recent
change to a larger timeout actually changed anything at all?

> 
> So if someone responsible wants to work on the TODO list, go ahead, it
> is all there ready for you.  Odds are, I will never even see
> notifications of your changes anyway.  :-(
> 
> Administrators say they increased the timeout 10x and need feedback if
> it needs to be increased further?  Do you need me to notice that every
> day I have to hit the 'edit' button, realize my session has timed out,
> then hit the login button and try again.  It happened this morning ---
> is that sufficient?  I have no idea.  Do these cookies control anything
> but the wiki?  I assume not because 20 minutes was the MediaWiki default.

the ~20min is not a MW default, it is one from debian about cleaning up
session data (again a protection machanism, http is stateless and you
don't get a "user logged off" thingy in general so we need to remove
session data in some interval to not end up with millions of session files).
And yes as said above - we have speculated only so far on what exactly
the session timeout mechanics are and if the settings we are currently
dealing with actually control what people complain about - I'm still not
sure if you are saying it does or not?

> 
> So, in summary, there are all these things on the wiki that don't work,
> but I am having to fight to get something we can fix to a reasonable
> default, and at a certain point, you just give up and find a way to do
> it yourself, like maybe an auto-login javascript widget for the wiki.

you do realise that the "Administrators" are mostly concerned about
running the platform in a scalable, secure and reliable way?
We are definitly not experts on every single piece of software from an
application PoV.
Most of the current complaints are either software issues (which we can
only support so much) or stuff that comes from the very specific
usecases that are different from what 95% of the people usually do (ie
editing articles for hours and hours in one go instead of multiple
smaller edits and keeping browers windows open for days on a specific
article).
Keep in mind that most of those defaults were choosen by people (package
maintainers, upstream developers,..) that know this stuff likely better
than any of us, so it is imho valid from a sysadmin pov to investigate
on why we need something different.




Stefan