Обсуждение: Can we change auto-logout timing on wiki.postgresql.org?
WWW, wiki.postgresql.org is auto-logging me out after an hour, or less. This is irritating when I'm editing a really long wiki page. Could we please set it to something like 8 hours? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Thu, Apr 25, 2013 at 05:42:30PM -0700, Josh Berkus wrote: > WWW, > > wiki.postgresql.org is auto-logging me out after an hour, or less. This > is irritating when I'm editing a really long wiki page. Could we please > set it to something like 8 hours? +1 :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Fri, Apr 26, 2013 at 2:42 AM, Josh Berkus <josh@agliodbs.com> wrote: > WWW, > > wiki.postgresql.org is auto-logging me out after an hour, or less. This > is irritating when I'm editing a really long wiki page. Could we please > set it to something like 8 hours? AFAICT, this is controlled by the PHP variable session.cache_expire, which is set to 3 hours already. are you really editing the same page longer than 3 hours and thus getting kicked off, or may there be something else at play? --Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On 26/04/13 12:40, Magnus Hagander wrote: > On Fri, Apr 26, 2013 at 2:42 AM, Josh Berkus <josh@agliodbs.com> wrote: >> WWW, >> >> wiki.postgresql.org is auto-logging me out after an hour, or less. This >> is irritating when I'm editing a really long wiki page. Could we please >> set it to something like 8 hours? > > AFAICT, this is controlled by the PHP variable session.cache_expire, > which is set to 3 hours already. are you really editing the same page > longer than 3 hours and thus getting kicked off, or may there be > something else at play? Despite its name, session.cache_expire does not affect the expiry of sessions or the cookies associated with them. As far as I can tell from examining the headers, it looks like an expiry date/time is set for the login cookie, but then it is never updated. If this is the case, then eventually the expiry date will pass and the browser will delete the cookie, even if you have been regularly accessing the wiki. Another possibility is that the cronjob which auto-removes session files (assuming files are being used) is set to the default of 24 minutes - which will remove your session after that time regardless of what the cookie's expiry date is set to. -- Paul Waring http://www.pwaring.com
On Fri, Apr 26, 2013 at 2:00 PM, Paul Waring <paul@xk7.net> wrote: > On 26/04/13 12:40, Magnus Hagander wrote: >> >> On Fri, Apr 26, 2013 at 2:42 AM, Josh Berkus <josh@agliodbs.com> wrote: >>> >>> WWW, >>> >>> wiki.postgresql.org is auto-logging me out after an hour, or less. This >>> is irritating when I'm editing a really long wiki page. Could we please >>> set it to something like 8 hours? >> >> >> AFAICT, this is controlled by the PHP variable session.cache_expire, >> which is set to 3 hours already. are you really editing the same page >> longer than 3 hours and thus getting kicked off, or may there be >> something else at play? > > > Despite its name, session.cache_expire does not affect the expiry of > sessions or the cookies associated with them. I was just looking at the mediawiki wiki at http://www.mediawiki.org/wiki/Manual_talk:Configuration_settings which seem to says it does :S But reading it again, it seems there is a second one, the gc one. > As far as I can tell from examining the headers, it looks like an expiry > date/time is set for the login cookie, but then it is never updated. If this > is the case, then eventually the expiry date will pass and the browser will > delete the cookie, even if you have been regularly accessing the wiki. > > Another possibility is that the cronjob which auto-removes session files > (assuming files are being used) is set to the default of 24 minutes - which > will remove your session after that time regardless of what the cookie's > expiry date is set to. We do have session.gc_maxlifetime set to 1440 which is the 24 minutes you're referring to? So maybe this is the parameter we need to (drastically) increase? --Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On 26/04/13 13:06, Magnus Hagander wrote: >> As far as I can tell from examining the headers, it looks like an expiry >> date/time is set for the login cookie, but then it is never updated. If this >> is the case, then eventually the expiry date will pass and the browser will >> delete the cookie, even if you have been regularly accessing the wiki. >> >> Another possibility is that the cronjob which auto-removes session files >> (assuming files are being used) is set to the default of 24 minutes - which >> will remove your session after that time regardless of what the cookie's >> expiry date is set to. > > We do have session.gc_maxlifetime set to 1440 which is the 24 minutes > you're referring to? So maybe this is the parameter we need to > (drastically) increase? Assuming session data is being stored in files (you can check that with session.save_handler), then you might want to increase session.gc_maxlifetime. The cleanup cronjob runs at 9 and 39 minutes past the hour by default, so a session file might be deleted 24-54 minutes since it was last modified. -- Paul Waring http://www.pwaring.com
On 04/26/2013 04:40 AM, Magnus Hagander wrote: > On Fri, Apr 26, 2013 at 2:42 AM, Josh Berkus <josh@agliodbs.com> wrote: >> WWW, >> >> wiki.postgresql.org is auto-logging me out after an hour, or less. This >> is irritating when I'm editing a really long wiki page. Could we please >> set it to something like 8 hours? > > AFAICT, this is controlled by the PHP variable session.cache_expire, > which is set to 3 hours already. are you really editing the same page > longer than 3 hours and thus getting kicked off, or may there be > something else at play? You already seem to be on the trail of this, but the defacto timeout is definitely somewhere between 10min and 1 hour, and far less than 3 hours. Paul's diagnosis would be consistent with the random-seeming kickoffs I'm getting. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Fri, Apr 26, 2013 at 09:57:20AM -0700, Josh Berkus wrote: > On 04/26/2013 04:40 AM, Magnus Hagander wrote: > > On Fri, Apr 26, 2013 at 2:42 AM, Josh Berkus <josh@agliodbs.com> wrote: > >> WWW, > >> > >> wiki.postgresql.org is auto-logging me out after an hour, or less. This > >> is irritating when I'm editing a really long wiki page. Could we please > >> set it to something like 8 hours? > > > > AFAICT, this is controlled by the PHP variable session.cache_expire, > > which is set to 3 hours already. are you really editing the same page > > longer than 3 hours and thus getting kicked off, or may there be > > something else at play? > > You already seem to be on the trail of this, but the defacto timeout is > definitely somewhere between 10min and 1 hour, and far less than 3 hours. > > Paul's diagnosis would be consistent with the random-seeming kickoffs > I'm getting. Yes, I have found it annoying too and complained. The big problem is you are sitting on a wiki page, e.g. TODO, and when you hit the 'edit' button, you can't because you were logged out. This is just user-hostile. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian wrote: > Yes, I have found it annoying too and complained. The big problem is > you are sitting on a wiki page, e.g. TODO, and when you hit the 'edit' > button, you can't because you were logged out. This is just > user-hostile. I'm used to sites keeping me logged in for, say, a week, so I don't have to worry about it at all ... well, except my bank and such, of course. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 04/26/2013 02:21 PM, Paul Waring wrote: > On 26/04/13 13:06, Magnus Hagander wrote: >>> As far as I can tell from examining the headers, it looks like an expiry >>> date/time is set for the login cookie, but then it is never updated. >>> If this >>> is the case, then eventually the expiry date will pass and the >>> browser will >>> delete the cookie, even if you have been regularly accessing the wiki. >>> >>> Another possibility is that the cronjob which auto-removes session files >>> (assuming files are being used) is set to the default of 24 minutes - >>> which >>> will remove your session after that time regardless of what the cookie's >>> expiry date is set to. >> >> We do have session.gc_maxlifetime set to 1440 which is the 24 minutes >> you're referring to? So maybe this is the parameter we need to >> (drastically) increase? > > Assuming session data is being stored in files (you can check that with > session.save_handler), then you might want to increase > session.gc_maxlifetime. > > The cleanup cronjob runs at 9 and 39 minutes past the hour by default, > so a session file might be deleted 24-54 minutes since it was last > modified. interesting hint - thanks. I have now increased the relevant timeouts to 6h - lets see how that goes.. Stefan
On 04/26/2013 11:39 PM, Stefan Kaltenbrunner wrote: > interesting hint - thanks. > > I have now increased the relevant timeouts to 6h - lets see how that goes.. FTR, I don't think we should autologout people or at least it should be set to something like 7D. JD > > > Stefan > >
On 04/27/2013 08:55 AM, Joshua D. Drake wrote: > > On 04/26/2013 11:39 PM, Stefan Kaltenbrunner wrote: > >> interesting hint - thanks. >> >> I have now increased the relevant timeouts to 6h - lets see how that >> goes.. > > FTR, I don't think we should autologout people or at least it should be > set to something like 7D. 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. Stefan
On Sat, Apr 27, 2013 at 11:10:43AM +0200, Stefan Kaltenbrunner wrote: > On 04/27/2013 08:55 AM, Joshua D. Drake wrote: > > > > On 04/26/2013 11:39 PM, Stefan Kaltenbrunner wrote: > > > >> interesting hint - thanks. > >> > >> I have now increased the relevant timeouts to 6h - lets see how that > >> goes.. > > > > FTR, I don't think we should autologout people or at least it should be > > set to something like 7D. > > 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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Sat, Apr 27, 2013 at 4:09 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Sat, Apr 27, 2013 at 11:10:43AM +0200, Stefan Kaltenbrunner wrote: >> On 04/27/2013 08:55 AM, Joshua D. Drake wrote: >> > >> > On 04/26/2013 11:39 PM, Stefan Kaltenbrunner wrote: >> > >> >> interesting hint - thanks. >> >> >> >> I have now increased the relevant timeouts to 6h - lets see how that >> >> goes.. >> > >> > FTR, I don't think we should autologout people or at least it should be >> > set to something like 7D. >> >> 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. Note that this is not 7 days since you logged in. It's 7 days since you last did something. And as long as you don't stop working, you never get logged out ;) --Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On 04/27/2013 07:09 AM, Bruce Momjian wrote: > > On Sat, Apr 27, 2013 at 11:10:43AM +0200, Stefan Kaltenbrunner wrote: >> On 04/27/2013 08:55 AM, Joshua D. Drake wrote: >>> >>> On 04/26/2013 11:39 PM, Stefan Kaltenbrunner wrote: >>> >>>> interesting hint - thanks. >>>> >>>> I have now increased the relevant timeouts to 6h - lets see how that >>>> goes.. >>> >>> FTR, I don't think we should autologout people or at least it should be >>> set to something like 7D. >> >> 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. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC @cmdpromptinc - 509-416-6579
On 04/27/2013 05:24 PM, Magnus Hagander wrote: > On Sat, Apr 27, 2013 at 4:09 PM, Bruce Momjian <bruce@momjian.us> wrote: >> On Sat, Apr 27, 2013 at 11:10:43AM +0200, Stefan Kaltenbrunner wrote: >>> On 04/27/2013 08:55 AM, Joshua D. Drake wrote: >>>> >>>> On 04/26/2013 11:39 PM, Stefan Kaltenbrunner wrote: >>>> >>>>> interesting hint - thanks. >>>>> >>>>> I have now increased the relevant timeouts to 6h - lets see how that >>>>> goes.. >>>> >>>> FTR, I don't think we should autologout people or at least it should be >>>> set to something like 7D. >>> >>> 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. > > Note that this is not 7 days since you logged in. It's 7 days since > you last did something. And as long as you don't stop working, you > never get logged out ;) and from looking at the average time between changes and the overall changerate of any given site I don't really see how people people will realistically hit the 6h limit. Anyhow if somebody wants to change this to a larger limit I wont object, but 7 days seems mighty excessive... Stefan
> and from looking at the average time between changes and the overall > changerate of any given site I don't really see how people people will > realistically hit the 6h limit. Anyhow if somebody wants to change this > to a larger limit I wont object, but 7 days seems mighty excessive... I'm fine with 6 hours, myself. Especially since whatever used to prevent me from caching my login creds got fixed/changed; logging in is just clicking a link. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Sat, Apr 27, 2013 at 09:27:13AM -0700, Joshua D. Drake wrote: > > On 04/27/2013 07:09 AM, Bruce Momjian wrote: > > > >On Sat, Apr 27, 2013 at 11:10:43AM +0200, Stefan Kaltenbrunner wrote: > >>On 04/27/2013 08:55 AM, Joshua D. Drake wrote: > >>> > >>>On 04/26/2013 11:39 PM, Stefan Kaltenbrunner wrote: > >>> > >>>>interesting hint - thanks. > >>>> > >>>>I have now increased the relevant timeouts to 6h - lets see how that > >>>>goes.. > >>> > >>>FTR, I don't think we should autologout people or at least it should be > >>>set to something like 7D. > >> > >>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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Sat, Apr 27, 2013 at 07:01:34PM +0200, Stefan Kaltenbrunner wrote: > > Note that this is not 7 days since you logged in. It's 7 days since > > you last did something. And as long as you don't stop working, you > > never get logged out ;) > > and from looking at the average time between changes and the overall > changerate of any given site I don't really see how people people will > realistically hit the 6h limit. Anyhow if somebody wants to change this > to a larger limit I wont object, but 7 days seems mighty excessive... The problem is not having it timeout while you are using the wiki, it is having it open and then having to re-login every day to do something. Please make it 7 days. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, May 3, 2013 at 2:40 AM, Bruce Momjian <bruce@momjian.us> wrote: > On Sat, Apr 27, 2013 at 09:27:13AM -0700, Joshua D. Drake wrote: >> >> On 04/27/2013 07:09 AM, Bruce Momjian wrote: >> > >> >On Sat, Apr 27, 2013 at 11:10:43AM +0200, Stefan Kaltenbrunner wrote: >> >>On 04/27/2013 08:55 AM, Joshua D. Drake wrote: >> >>> >> >>>On 04/26/2013 11:39 PM, Stefan Kaltenbrunner wrote: >> >>> >> >>>>interesting hint - thanks. >> >>>> >> >>>>I have now increased the relevant timeouts to 6h - lets see how that >> >>>>goes.. >> >>> >> >>>FTR, I don't think we should autologout people or at least it should be >> >>>set to something like 7D. >> >> >> >>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? --Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
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. 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. 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. 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. 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. 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. (No, I have not written one, _yet_. ;-) ) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 05/03/2013 06:23 AM, Bruce Momjian wrote: >> 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. As CVE as so eloquently pointed out, removing barriers to using the Wiki is a good idea. I like that when I decide to open Gmail it is just there, working. If I spent a lot of time on the wiki, I would expect it to work the same way. I don't want to log in every time, it isn't my bank. Sincerely, JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC @cmdpromptinc - 509-416-6579
On Fri, May 3, 2013 at 08:55:53AM -0700, Joshua D. Drake wrote: > > On 05/03/2013 06:23 AM, Bruce Momjian wrote: > > >>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. > > As CVE as so eloquently pointed out, removing barriers to using the > Wiki is a good idea. I like that when I decide to open Gmail it is > just there, working. If I spent a lot of time on the wiki, I would > expect it to work the same way. I don't want to log in every time, > it isn't my bank. OK, having Googled "CVE" after seeing the above and failing, it took me three hours to realize it is a joke related to PGDay NYC and stands for Chief Village Elder. LOL -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
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
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. +
On 05/04/2013 04:05 PM, Bruce Momjian wrote: > 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. true - the question is "are the MW people aware?" or maybe "is it something that in a newer version is fixed?" [...] > 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 not > allowed to update your external account. hmm thanks for the report - that seems to be a (fairly) recently introduced buglet in our custom authentication backend, it should however not have resulted in any lost functionality just the above error message. Should be fixed now anyway. > > 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? I do ;) > > 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 the "notfiy watchlist" feature is off by default in MW. > >>> 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> > <li class="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. it is broken for me as well - I have no idea why though... [..] >> 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. hmm not sure I get that - if you restart your browser daily how are the session cookies even get preserved, or do you use one of these "restore session" features? Stefan
On Sat, May 4, 2013 at 07:44:20PM +0200, Stefan Kaltenbrunner wrote: > [...] > > 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 not > > allowed to update your external account. > > hmm thanks for the report - that seems to be a (fairly) recently > introduced buglet in our custom authentication backend, it should > however not have resulted in any lost functionality just the above error > message. Should be fixed now anyway. OK, I was now able to add email notification for watch list changes. Let's see if I get any email when someone modifies something. It might take a few weeks before I would know. > > 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? > > I do ;) Oh, that's interesting. Did you have those buttons checked in your preferences? I did not. > > 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 > > the "notfiy watchlist" feature is off by default in MW. OK. > >> 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. > > hmm not sure I get that - if you restart your browser daily how are the > session cookies even get preserved, or do you use one of these "restore > session" features? Uh, well, I have the TODO list as one of my default startup tabs. Most websites can still use old cookies on a browser restart, e.g. Gmail, Slashdot. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Sat, May 4, 2013 at 02:08:54PM -0400, Bruce Momjian wrote: > > hmm not sure I get that - if you restart your browser daily how are the > > session cookies even get preserved, or do you use one of these "restore > > session" features? > > Uh, well, I have the TODO list as one of my default startup tabs. Most > websites can still use old cookies on a browser restart, e.g. Gmail, > Slashdot. I just checked and you are right that a browser restart automatically logs me out. I guess the code just doens't assume someone will be sitting on a wiki page for hours/days. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 05/04/2013 08:08 PM, Bruce Momjian wrote: > On Sat, May 4, 2013 at 07:44:20PM +0200, Stefan Kaltenbrunner wrote: >> [...] >>> 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 not >>> allowed to update your external account. >> >> hmm thanks for the report - that seems to be a (fairly) recently >> introduced buglet in our custom authentication backend, it should >> however not have resulted in any lost functionality just the above error >> message. Should be fixed now anyway. > > OK, I was now able to add email notification for watch list changes. > Let's see if I get any email when someone modifies something. It might > take a few weeks before I would know. hmm weird - afaiks the error message should have been cosmetic only, are you saying that it seems to have actually prevented the notifications? > >>> 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? >> >> I do ;) > > Oh, that's interesting. Did you have those buttons checked in your > preferences? I did not. yeah i had them (but I'm pretty sure I had manually checked them) >>>> 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. >> >> hmm not sure I get that - if you restart your browser daily how are the >> session cookies even get preserved, or do you use one of these "restore >> session" features? > > Uh, well, I have the TODO list as one of my default startup tabs. Most > websites can still use old cookies on a browser restart, e.g. Gmail, > Slashdot. hmm pretty sure that browsers are supposed to clear session cookies if they are restarted otherwise you will create bad security issues. Consider logging in to a some site with personal information, close your browser hand over your laptop to somebody in the family for a quick browsing session and he will automatically log in to whatever site you been at before... Stefan
On Sat, May 4, 2013 at 08:19:38PM +0200, Stefan Kaltenbrunner wrote: > On 05/04/2013 08:08 PM, Bruce Momjian wrote: > > On Sat, May 4, 2013 at 07:44:20PM +0200, Stefan Kaltenbrunner wrote: > >> [...] > >>> 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 not > >>> allowed to update your external account. > >> > >> hmm thanks for the report - that seems to be a (fairly) recently > >> introduced buglet in our custom authentication backend, it should > >> however not have resulted in any lost functionality just the above error > >> message. Should be fixed now anyway. > > > > OK, I was now able to add email notification for watch list changes. > > Let's see if I get any email when someone modifies something. It might > > take a few weeks before I would know. > > hmm weird - afaiks the error message should have been cosmetic only, are > you saying that it seems to have actually prevented the notifications? Oh, it certainly prevented me from modifying my preferences, but it certainly works now. > >>> 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? > >> > >> I do ;) > > > > Oh, that's interesting. Did you have those buttons checked in your > > preferences? I did not. > > yeah i had them (but I'm pretty sure I had manually checked them) OK. That explains it then. > >>>> 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. > >> > >> hmm not sure I get that - if you restart your browser daily how are the > >> session cookies even get preserved, or do you use one of these "restore > >> session" features? > > > > Uh, well, I have the TODO list as one of my default startup tabs. Most > > websites can still use old cookies on a browser restart, e.g. Gmail, > > Slashdot. > > > hmm pretty sure that browsers are supposed to clear session cookies if > they are restarted otherwise you will create bad security issues. > Consider logging in to a some site with personal information, close your > browser hand over your laptop to somebody in the family for a quick > browsing session and he will automatically log in to whatever site you > been at before... Well, if I just go to gmail.com, it certainly knows I am bmomjian. If I go to slashdot.org, it knows I am bmomjian too. I have to explicitly log out if I want be logged out. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Sat, May 4, 2013 at 7:19 PM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > hmm pretty sure that browsers are supposed to clear session cookies if > they are restarted otherwise you will create bad security issues. > Consider logging in to a some site with personal information, close your > browser hand over your laptop to somebody in the family for a quick > browsing session and he will automatically log in to whatever site you > been at before... What is this "close your browser"? Are you sure you know when you close your browser? What about background tasks that might keep the browser process running even with no windows? And just because you want Gmail open why does that mean you want to keep credentials for Facebook and Amazon loaded? Or does it happen when you close the window? What if there were other windows or if some other site had an iframe on the web site you're trying to close that you didn't even know about? When do you "close your browser" on your phone? Now that the web is more of an application platform each application needs to think about when it wants the credentials or other local data it uses to expire and arrange for it to happen as desired. Depending on a concept like "close the browser" means not really knowing when it will happen. -- greg
On 05/04/2013 08:24 PM, Bruce Momjian wrote: > On Sat, May 4, 2013 at 08:19:38PM +0200, Stefan Kaltenbrunner wrote: >> hmm pretty sure that browsers are supposed to clear session cookies if >> they are restarted otherwise you will create bad security issues. >> Consider logging in to a some site with personal information, close your >> browser hand over your laptop to somebody in the family for a quick >> browsing session and he will automatically log in to whatever site you >> been at before... > > Well, if I just go to gmail.com, it certainly knows I am bmomjian. If I > go to slashdot.org, it knows I am bmomjian too. I have to explicitly > log out if I want be logged out. erm - I guess those are using persistent (tracking) cookies(as in you clicked on "keep me signed in" at one time) vs classic session cookies, are you proposing we should impose persistent cookies on our users? Stefan
On Sat, May 4, 2013 at 10:23:14PM +0200, Stefan Kaltenbrunner wrote: > On 05/04/2013 08:24 PM, Bruce Momjian wrote: > > On Sat, May 4, 2013 at 08:19:38PM +0200, Stefan Kaltenbrunner wrote: > >> hmm pretty sure that browsers are supposed to clear session cookies if > >> they are restarted otherwise you will create bad security issues. > >> Consider logging in to a some site with personal information, close your > >> browser hand over your laptop to somebody in the family for a quick > >> browsing session and he will automatically log in to whatever site you > >> been at before... > > > > Well, if I just go to gmail.com, it certainly knows I am bmomjian. If I > > go to slashdot.org, it knows I am bmomjian too. I have to explicitly > > log out if I want be logged out. > > erm - I guess those are using persistent (tracking) cookies(as in you > clicked on "keep me signed in" at one time) vs classic session cookies, > are you proposing we should impose persistent cookies on our users? I find the use of the word "impose" curious. How do such cookies "impose"? Is it storage imposition? Security imposition? From a user perspective, it seems like a feature, not an imposition. One nice thing our site does is when you click "login", it logs you in without requiring me to actually see or type the username/password. I have no idea how we do that, so I suspect there must be some cookie activity. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Sat, May 4, 2013 at 02:08:54PM -0400, Bruce Momjian wrote: > On Sat, May 4, 2013 at 07:44:20PM +0200, Stefan Kaltenbrunner wrote: > > [...] > > > 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 not > > > allowed to update your external account. > > > > hmm thanks for the report - that seems to be a (fairly) recently > > introduced buglet in our custom authentication backend, it should > > however not have resulted in any lost functionality just the above error > > message. Should be fixed now anyway. > > OK, I was now able to add email notification for watch list changes. > Let's see if I get any email when someone modifies something. It might > take a few weeks before I would know. I am now getting email notifications of TODO changes. :-) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, May 2, 2013 at 08:41:53PM -0400, Bruce Momjian wrote: > On Sat, Apr 27, 2013 at 07:01:34PM +0200, Stefan Kaltenbrunner wrote: > > > Note that this is not 7 days since you logged in. It's 7 days since > > > you last did something. And as long as you don't stop working, you > > > never get logged out ;) > > > > and from looking at the average time between changes and the overall > > changerate of any given site I don't really see how people people will > > realistically hit the 6h limit. Anyhow if somebody wants to change this > > to a larger limit I wont object, but 7 days seems mighty excessive... > > The problem is not having it timeout while you are using the wiki, it is > having it open and then having to re-login every day to do something. > Please make it 7 days. Where are we on increasing this timeout? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Tue, May 14, 2013 at 11:25:09PM -0400, Bruce Momjian wrote: > On Thu, May 2, 2013 at 08:41:53PM -0400, Bruce Momjian wrote: > > On Sat, Apr 27, 2013 at 07:01:34PM +0200, Stefan Kaltenbrunner wrote: > > > > Note that this is not 7 days since you logged in. It's 7 days since > > > > you last did something. And as long as you don't stop working, you > > > > never get logged out ;) > > > > > > and from looking at the average time between changes and the overall > > > changerate of any given site I don't really see how people people will > > > realistically hit the 6h limit. Anyhow if somebody wants to change this > > > to a larger limit I wont object, but 7 days seems mighty excessive... > > > > The problem is not having it timeout while you are using the wiki, it is > > having it open and then having to re-login every day to do something. > > Please make it 7 days. > > Where are we on increasing this timeout? On other weird thing is that when your session login times out, there is no indication on the screen, and when you click on something like "edit", instead of being presented with a login request, you get a read-only copy of the page. With other sites, I would normally get a request to login for such an action. I am not sure if this is the wiki software default, or caused by the way our wiki login is hooked to our community login credentials. This is another aspect of the login timeout that makes the site unfriendly --- you are never really sure if an action is going to work, or you are going to get a read-only copy, and the read-only copy isn't obvious until you start trying to type something or notice the text is more dim than usual. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
WWW, First off, whatever tuning you did didn't work. I'm still getting logged out, after considerably less than 6 hours. I'd say about 20min, in fact. Second, people should be aware of a bug where if you have an ' in your URL, you can't use the login on that page (try logging in from the What's New page). It's a mediawiki bug. > On other weird thing is that when your session login times out, there is > no indication on the screen, and when you click on something like > "edit", instead of being presented with a login request, you get a > read-only copy of the page. With other sites, I would normally get a > request to login for such an action. This is a mediawiki design flaw. i.e. it's a bad design choice upstream. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 05/15/2013 10:55 AM, Josh Berkus wrote: > WWW, > > First off, whatever tuning you did didn't work. I'm still getting > logged out, after considerably less than 6 hours. I'd say about 20min, > in fact. Wait, no. That's not the issue. The real issue is somewhat stranger. 1. log into wiki.postgresql.org. 2. in a new browser tab/window, follow this link: http://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting ... you will find yourself not logged in on that tab, even though you are on another tab. 3. now click this link: https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting ... now you're logged in. WTF? Apparently login state is only detected for HTTPS links? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Wed, May 15, 2013 at 7:58 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 05/15/2013 10:55 AM, Josh Berkus wrote: >> WWW, >> >> First off, whatever tuning you did didn't work. I'm still getting >> logged out, after considerably less than 6 hours. I'd say about 20min, >> in fact. > > Wait, no. That's not the issue. The real issue is somewhat stranger. > > 1. log into wiki.postgresql.org. > > 2. in a new browser tab/window, follow this link: > > http://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting > > ... you will find yourself not logged in on that tab, even though you > are on another tab. > > 3. now click this link: > > https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting > > ... now you're logged in. WTF? Apparently login state is only detected > for HTTPS links? Yes, the login cookie is set to be sent only over https, for security reasons. For our other websites, this will be automatically detected and you get redirected to https (try going to your account page on the main website with http for example), but at last I don't know of a way to do that in mediawiki. Should be easy enough to see - check your mediawiki cookies, and you'll see they are enabled for https only. --Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On 15/05/13 19:00, Magnus Hagander wrote: > On Wed, May 15, 2013 at 7:58 PM, Josh Berkus <josh@agliodbs.com> wrote: >> On 05/15/2013 10:55 AM, Josh Berkus wrote: >>> WWW, >>> >>> First off, whatever tuning you did didn't work. I'm still getting >>> logged out, after considerably less than 6 hours. I'd say about 20min, >>> in fact. >> >> Wait, no. That's not the issue. The real issue is somewhat stranger. >> >> 1. log into wiki.postgresql.org. >> >> 2. in a new browser tab/window, follow this link: >> >> http://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting >> >> ... you will find yourself not logged in on that tab, even though you >> are on another tab. >> >> 3. now click this link: >> >> https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting >> >> ... now you're logged in. WTF? Apparently login state is only detected >> for HTTPS links? > > Yes, the login cookie is set to be sent only over https, for security reasons. > > For our other websites, this will be automatically detected and you > get redirected to https (try going to your account page on the main > website with http for example), but at last I don't know of a way to > do that in mediawiki. > > Should be easy enough to see - check your mediawiki cookies, and > you'll see they are enabled for https only. That's not quite accurate - there are three cookies set by *.postgresql.org: postgresql.org - csrftoken (expires a year after being set) postgresql.org - sessionid (expires two weeks after being set) wiki.postgresql.org - wikidb_session (expires on browser close) Only the sessionid cookie requires a https connection, the other cookies will be sent if a request is made over a http connection. If all wiki connections should be over https - including guests - then that can be accomplished via a simple rule in the Apache virtual host configuration. If only logged in users require https then you'd need either a plugin to handle this, or register a 'hook' which is a small piece of PHP which is run before Mediawiki displays a page and forces a redirect if the request was not made over https *and* the wikidb_session cookie is set. -- Paul Waring http://www.pwaring.com
On Wed, May 15, 2013 at 8:44 PM, Paul Waring <paul@xk7.net> wrote: > On 15/05/13 19:00, Magnus Hagander wrote: >> >> On Wed, May 15, 2013 at 7:58 PM, Josh Berkus <josh@agliodbs.com> wrote: >>> >>> On 05/15/2013 10:55 AM, Josh Berkus wrote: >>>> >>>> WWW, >>>> >>>> First off, whatever tuning you did didn't work. I'm still getting >>>> logged out, after considerably less than 6 hours. I'd say about 20min, >>>> in fact. >>> >>> >>> Wait, no. That's not the issue. The real issue is somewhat stranger. >>> >>> 1. log into wiki.postgresql.org. >>> >>> 2. in a new browser tab/window, follow this link: >>> >>> http://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting >>> >>> ... you will find yourself not logged in on that tab, even though you >>> are on another tab. >>> >>> 3. now click this link: >>> >>> https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting >>> >>> ... now you're logged in. WTF? Apparently login state is only detected >>> for HTTPS links? >> >> >> Yes, the login cookie is set to be sent only over https, for security >> reasons. >> >> For our other websites, this will be automatically detected and you >> get redirected to https (try going to your account page on the main >> website with http for example), but at last I don't know of a way to >> do that in mediawiki. >> >> Should be easy enough to see - check your mediawiki cookies, and >> you'll see they are enabled for https only. > > > That's not quite accurate - there are three cookies set by *.postgresql.org: > > postgresql.org - csrftoken (expires a year after being set) That one is, I believe, not actually part of that site. It's leaking over fromthe main website. > postgresql.org - sessionid (expires two weeks after being set) > wiki.postgresql.org - wikidb_session (expires on browser close) > > Only the sessionid cookie requires a https connection, the other cookies > will be sent if a request is made over a http connection. Yes. But the interesting cookies here are wikidbUserID and wikidbUserName. > If all wiki connections should be over https - including guests - then that > can be accomplished via a simple rule in the Apache virtual host > configuration. If only logged in users require https then you'd need either Assumign we used apache. But yes, that's a trivial configuration in any webserver. That is not the current intention, though we might want to revisit that in the future. > a plugin to handle this, or register a 'hook' which is a small piece of PHP > which is run before Mediawiki displays a page and forces a redirect if the > request was not made over https *and* the wikidb_session cookie is set. Do you know if there's a readymade plugin that supports this? --Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On 15/05/13 19:47, Magnus Hagander wrote: > On Wed, May 15, 2013 at 8:44 PM, Paul Waring <paul@xk7.net> wrote: >> On 15/05/13 19:00, Magnus Hagander wrote: >>> >>> On Wed, May 15, 2013 at 7:58 PM, Josh Berkus <josh@agliodbs.com> wrote: >>>> >>>> On 05/15/2013 10:55 AM, Josh Berkus wrote: >>>>> >>>>> WWW, >>>>> >>>>> First off, whatever tuning you did didn't work. I'm still getting >>>>> logged out, after considerably less than 6 hours. I'd say about 20min, >>>>> in fact. >>>> >>>> >>>> Wait, no. That's not the issue. The real issue is somewhat stranger. >>>> >>>> 1. log into wiki.postgresql.org. >>>> >>>> 2. in a new browser tab/window, follow this link: >>>> >>>> http://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting >>>> >>>> ... you will find yourself not logged in on that tab, even though you >>>> are on another tab. >>>> >>>> 3. now click this link: >>>> >>>> https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting >>>> >>>> ... now you're logged in. WTF? Apparently login state is only detected >>>> for HTTPS links? >>> >>> >>> Yes, the login cookie is set to be sent only over https, for security >>> reasons. >>> >>> For our other websites, this will be automatically detected and you >>> get redirected to https (try going to your account page on the main >>> website with http for example), but at last I don't know of a way to >>> do that in mediawiki. >>> >>> Should be easy enough to see - check your mediawiki cookies, and >>> you'll see they are enabled for https only. >> >> >> That's not quite accurate - there are three cookies set by *.postgresql.org: >> >> postgresql.org - csrftoken (expires a year after being set) > > That one is, I believe, not actually part of that site. It's leaking > over fromthe main website. > >> postgresql.org - sessionid (expires two weeks after being set) >> wiki.postgresql.org - wikidb_session (expires on browser close) >> >> Only the sessionid cookie requires a https connection, the other cookies >> will be sent if a request is made over a http connection. > > Yes. But the interesting cookies here are wikidbUserID and wikidbUserName. > > >> If all wiki connections should be over https - including guests - then that >> can be accomplished via a simple rule in the Apache virtual host >> configuration. If only logged in users require https then you'd need either > > Assumign we used apache. But yes, that's a trivial configuration in > any webserver. That is not the current intention, though we might want > to revisit that in the future. > >> a plugin to handle this, or register a 'hook' which is a small piece of PHP >> which is run before Mediawiki displays a page and forces a redirect if the >> request was not made over https *and* the wikidb_session cookie is set. > > Do you know if there's a readymade plugin that supports this? There does not appear to be one - the two which did exist have been deprecated and not updated since 2009, and in any case they only forced https on pages such as the login. -- Paul Waring http://www.pwaring.com