Обсуждение: Session timeout on commitfest.postgresql.org
$SUBJECT seems to be less than 12 hours, which is annoyingly short.
I don't see a good reason why I should have to log in again every
morning. I could see expiring the cookie in a week or so, or tying
it to a particular IP address, but this is just getting in the way.
regards, tom lane
On Tue, Aug 10, 2010 at 10:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > $SUBJECT seems to be less than 12 hours, which is annoyingly short. > I don't see a good reason why I should have to log in again every > morning. I could see expiring the cookie in a week or so, or tying > it to a particular IP address, but this is just getting in the way. Hrm. It seems that there's not really any timeout at all (which probably needs to be fixed); rather, it just sets a cookie that lasts for the lifetime of your browser session. Let me see about doing something about this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Tom Lane <tgl@sss.pgh.pa.us> wrote: > $SUBJECT seems to be less than 12 hours, which is annoyingly > short. I don't see a good reason why I should have to log in > again every morning. I could see expiring the cookie in a week or > so, or tying it to a particular IP address, but this is just > getting in the way. Could it be a firewall doing that to you? I stay logged in to the CF app for weeks at a time. The Wiki seems to log me out on an annoyingly short timer, but not the CF app. -Kevin
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Aug 10, 2010 at 10:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> $SUBJECT seems to be less than 12 hours, which is annoyingly short.
>> I don't see a good reason why I should have to log in again every
>> morning. �I could see expiring the cookie in a week or so, or tying
>> it to a particular IP address, but this is just getting in the way.
> Hrm. It seems that there's not really any timeout at all (which
> probably needs to be fixed); rather, it just sets a cookie that lasts
> for the lifetime of your browser session. Let me see about doing
> something about this.
I haven't restarted Safari in quite a while, but I've been forced to log
in again roughly daily for the past week. It appears to time out after
8 or 10 hours of non-access to the site.
regards, tom lane
Robert Haas <robertmhaas@gmail.com> wrote: > it just sets a cookie that lasts > for the lifetime of your browser session. Ah, that's probably the difference -- I don't close the browser window with the CF app. I just lock my workstation. -Kevin
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> $SUBJECT seems to be less than 12 hours, which is annoyingly
>> short. I don't see a good reason why I should have to log in
>> again every morning. I could see expiring the cookie in a week or
>> so, or tying it to a particular IP address, but this is just
>> getting in the way.
> Could it be a firewall doing that to you?
Don't see how a firewall could affect cookies. Possibly this is a
browser-specific issue, though. I'm using current-rev Safari on a Mac.
I notice it shows the commitfest cookie as having no particular
expiration time, which may mean that some Apple-specific expiration
policy gets applied. But on the other hand, when I got prompted to
log in this morning, I checked the cookie list and there was such a
cookie there already --- so it wasn't that the browser had just dropped
it.
regards, tom lane
On Tue, Aug 10, 2010 at 11:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> $SUBJECT seems to be less than 12 hours, which is annoyingly >>> short. I don't see a good reason why I should have to log in >>> again every morning. I could see expiring the cookie in a week or >>> so, or tying it to a particular IP address, but this is just >>> getting in the way. > >> Could it be a firewall doing that to you? > > Don't see how a firewall could affect cookies. Possibly this is a > browser-specific issue, though. I'm using current-rev Safari on a Mac. > I notice it shows the commitfest cookie as having no particular > expiration time, which may mean that some Apple-specific expiration > policy gets applied. But on the other hand, when I got prompted to > log in this morning, I checked the cookie list and there was such a > cookie there already --- so it wasn't that the browser had just dropped > it. *scratches head* I don't see how that's possible, unless your browser is eating cookies for breakfast. There's no code anywhere in the application to (a) remove cookies from the database or (b) refuse to use cookies that are in the database based on the time they were issued. I can change the code to set an expires header (in fact, I'm working on that that now), but the symptoms you describe are inexplicable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On 10 August 2010 16:26, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Aug 10, 2010 at 11:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >>> Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> $SUBJECT seems to be less than 12 hours, which is annoyingly >>>> short. I don't see a good reason why I should have to log in >>>> again every morning. I could see expiring the cookie in a week or >>>> so, or tying it to a particular IP address, but this is just >>>> getting in the way. >> >>> Could it be a firewall doing that to you? >> >> Don't see how a firewall could affect cookies. Possibly this is a >> browser-specific issue, though. I'm using current-rev Safari on a Mac. >> I notice it shows the commitfest cookie as having no particular >> expiration time, which may mean that some Apple-specific expiration >> policy gets applied. But on the other hand, when I got prompted to >> log in this morning, I checked the cookie list and there was such a >> cookie there already --- so it wasn't that the browser had just dropped >> it. > > *scratches head* > > I don't see how that's possible, unless your browser is eating cookies > for breakfast. There's no code anywhere in the application to (a) > remove cookies from the database or (b) refuse to use cookies that are > in the database based on the time they were issued. I can change the > code to set an expires header (in fact, I'm working on that that now), > but the symptoms you describe are inexplicable. > > -- Not anything to do with this?: http://hivelogic.com/articles/the-safari-cookie-issue-fixed -- Thom Brown Registered Linux user: #516935
Thom Brown <thom@linux.com> writes: > On 10 August 2010 16:26, Robert Haas <robertmhaas@gmail.com> wrote: >> I don't see how that's possible, unless your browser is eating cookies >> for breakfast. �There's no code anywhere in the application to (a) >> remove cookies from the database or (b) refuse to use cookies that are >> in the database based on the time they were issued. I can change the >> code to set an expires header (in fact, I'm working on that that now), >> but the symptoms you describe are inexplicable. > Not anything to do with this?: > http://hivelogic.com/articles/the-safari-cookie-issue-fixed Dunno, because that update was months ago. Robert's comments make the situation even odder, though, because I have *always* seen the commitfest app want me to log back in anytime I hadn't used it recently. I assumed that was policy. I only complained because the timeout seemed to have dropped to an irrationally short value during this fest. Anyway, maybe setting a normal expires date will make it work better. regards, tom lane
On Tue, Aug 10, 2010 at 1:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> On 10 August 2010 16:26, Robert Haas <robertmhaas@gmail.com> wrote: >>> I don't see how that's possible, unless your browser is eating cookies >>> for breakfast. There's no code anywhere in the application to (a) >>> remove cookies from the database or (b) refuse to use cookies that are >>> in the database based on the time they were issued. I can change the >>> code to set an expires header (in fact, I'm working on that that now), >>> but the symptoms you describe are inexplicable. > >> Not anything to do with this?: >> http://hivelogic.com/articles/the-safari-cookie-issue-fixed > > Dunno, because that update was months ago. Robert's comments make the > situation even odder, though, because I have *always* seen the > commitfest app want me to log back in anytime I hadn't used it recently. > I assumed that was policy. I only complained because the timeout seemed > to have dropped to an irrationally short value during this fest. > > Anyway, maybe setting a normal expires date will make it work better. Done. http://git.postgresql.org/gitweb?p=pgcommitfest.git;a=summary While I was at it, I implemented a feature I've been wanting for a while: I made the "Status Summary" line at the top of the CommitFest page have links to filter by status. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Aug 10, 2010 at 1:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Anyway, maybe setting a normal expires date will make it work better.
> Done.
[ logs in again ... ] Hm, looks like you went for a one-week timeout?
That'll be an improvement for me, I expect, but maybe not for other
people. Should it be longer?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> wrote: > Hm, looks like you went for a one-week timeout? > That'll be an improvement for me, I expect, but maybe not for > other people. Should it be longer? The longer the setting, the more convenient for me, but I have a hard time getting work up over logging in once per week. :-) -Kevin
Robert Haas <robertmhaas@gmail.com> wrote: > While I was at it, I implemented a feature I've been wanting for a > while: I made the "Status Summary" line at the top of the > CommitFest page have links to filter by status. Very nice. I was going to ask to have "Ready for Committer" split out to its own section, but with this filtering, it's probably not worth the bother. This change will be very nice for CF managers. While we're on the topic of CF app enhancements, I often wished that the date of the last change to the "Reviewers" column would show underneath the name(s) where the value was not empty and the date was later than both the "Last Activity" date and the start of the CF. (Either that or count a non-NULL value set into this column as a reason to set the current date into "Last Activity", but I like the extra date better.) It occasionally seems as though WiP patches are different enough that there should be a more systematic was to flag them and count them, but I can't think of any concrete way to do that which doesn't introduce more problems than it would fix. And I still think that a link back to the CommitFest Wiki page might prevent the occasional gaff by people new to the application, but that assumes they'd follow the link and read up on the process before jumping in with entries in the app. The two most common issues seem to be putting a URL in the Message-ID field, and putting a whole review into the comment text rather than a brief summary and a link to a post with the review. Occasionally people failed to set a new status when they should have done after linking in a new patch or review. -Kevin
On Tue, Aug 10, 2010 at 2:43 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Very nice. I was going to ask to have "Ready for Committer" split > out to its own section, but with this filtering, it's probably not > worth the bother. This change will be very nice for CF managers. Glad you like. > While we're on the topic of CF app enhancements, I often wished that > the date of the last change to the "Reviewers" column would show > underneath the name(s) where the value was not empty and the date > was later than both the "Last Activity" date and the start of the > CF. (Either that or count a non-NULL value set into this column as > a reason to set the current date into "Last Activity", but I like > the extra date better.) That seems complex. > It occasionally seems as though WiP patches are different enough > that there should be a more systematic was to flag them and count > them, but I can't think of any concrete way to do that which doesn't > introduce more problems than it would fix. I agree that it occasionally seems that way, but it seems hard to get worked up about it. > And I still think that a link back to the CommitFest Wiki page might > prevent the occasional gaff by people new to the application, but > that assumes they'd follow the link and read up on the process > before jumping in with entries in the app. The two most common > issues seem to be putting a URL in the Message-ID field, and putting > a whole review into the comment text rather than a brief summary and > a link to a post with the review. Oh, yeah, I forgot that you asked for this. It's probably a good idea to work that in somewhere. > Occasionally people failed to set > a new status when they should have done after linking in a new patch > or review. I remain unconvinced that any tweaking of the system in this area comes out to a net plus. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Aug 10, 2010 at 2:43 PM, Kevin Grittner >> While we're on the topic of CF app enhancements, I often wished >> that the date of the last change to the "Reviewers" column would >> show underneath the name(s) where the value was not empty and the >> date was later than both the "Last Activity" date and the start >> of the CF. (Either that or count a non-NULL value set into this >> column as a reason to set the current date into "Last Activity", >> but I like the extra date better.) > > That seems complex. Well, yeah, but I found myself doing this "by hand" when I was getting organized to send out off-list "nag" emails. Whenever I find myself growling "Some day they'll invent a machine to do this" while doing some tedious task, I consider it a candidate for automation. ;-) >> Occasionally people failed to set a new status when they should >> have done after linking in a new patch or review. > > I remain unconvinced that any tweaking of the system in this area > comes out to a net plus. Agreed; that was just part of my list of things someone might get right more often if they had a handy link to the documentation to which they could refer while they were in making entries. -Kevin