Re: Can we change auto-logout timing on wiki.postgresql.org? - Mailing list pgsql-www
From | Bruce Momjian |
---|---|
Subject | Re: Can we change auto-logout timing on wiki.postgresql.org? |
Date | |
Msg-id | 20130504140518.GA5625@momjian.us Whole thread Raw |
In response to | Re: Can we change auto-logout timing on wiki.postgresql.org? (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Responses |
Re: Can we change auto-logout timing on wiki.postgresql.org?
|
List | pgsql-www |
On Sat, May 4, 2013 at 03:14:03PM +0200, Stefan Kaltenbrunner wrote: > > 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... It is certainly usable, but if it can be made more user-friendly, why not? The number of bugs I have reported isn't ideal, for sure. > > 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). Well, I start my browser daily probably, but that doesn't seem to help. > 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). I decided to look into this again and I see my preferences aren't set for me to get emails for changes on my watch list: E-mail me when a page on my watchlist is changed I am not sure of the value of a watch list if you don't get email notifications. If I try to enable that and save, I get a failure: There was either an authentication database error or you are notallowed to update your external account. I am not sure when that setting was changed, but I certainly didn't do it. I bet that is why I don't get wiki change notifications. Does anyone else get notifications? Also, it seems not getting email notifications is the default, because if I press "Restore all default settings", it say it is saved and the email is unclicked: https://wiki.postgresql.org/index.php?title=Special:Preferences&success > > 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 don't even understand why it isn't working. Here is TOAST and Montoring: <li class="toclevel-1"><a href="#TOAST"><span class="tocnumber">23</span> <span class="toctext">TOAST</span></a></li> <liclass="toclevel-1"><a href="#Monitoring"><span class="tocnumber">24</span> <span class="toctext">Monitoring</span></a></li> Here are the anchors: <a name="TOAST" id="TOAST"></a> <a name="Monitoring" id="Monitoring"></a> TOAST link works, Monitoring does not. Perhaps the HTML is mangled and Firefox is buggy. > > 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? Yes, I can't tell as my usecase is unusual. > > 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? I have no idea. > > 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. Agreed. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +