Session timeout on commitfest.postgresql.org

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