You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2014/01/21 01:32:47 UTC

[Bug 56041] New: should be able to disable session expiry increment

https://issues.apache.org/bugzilla/show_bug.cgi?id=56041

            Bug ID: 56041
           Summary: should be able to disable session expiry increment
           Product: Apache httpd-2
           Version: 2.4.7
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: mod_session
          Assignee: bugs@httpd.apache.org
          Reporter: erik@adaptations.com

A common use case, is for client side web apps to provide a constantly
refreshed display. The display could be refreshed, for example, with data
fetched periodically from the web server. This functionality is used to keep a
display updated with changes on the server, such as graphs, tables, messages,
etc. 

In the context of an authenticated web page, in which the original page view
and subsequent ajax calls all need to be authenticated, the session mechanism
will currently update the session cookie with each request, and the expiry time
parameter will continually "keep up" with real time. In many cases the web app
requirements are that the expiry time should remain at the time when the
primary page was provided to the client, with subsequent ajax fetches not
updating the expiry. This would provide the experience most people would expect
for an authenticated web page left unattended: It will eventually time out.

Another use case is the ability for a client web app to query the server for
authentication state, in order to provide a smooth user experience for re-login
or a timeout page. Clearly such a server query needs to be included in the
authentication realm, yet not affect the expiry of the session.

There would be different ways of implementing this. There could be a server
config directive to inhibit expiry incrementing per some sort of path match
(e.g. within a LocationMatch). I don't know enough about internals to know the
best technical direction.

Another approach, one that would be handy for client web app developers, would
be a request header field which would inhibit expiry incrementing.

Another use case would be the ability to give the end user the option of
"staying logged in", enabled by a user interface prompt. This would be
facilitated by a server request that would be intended to refresh the session
and bring the expiry up to date. This could be accomplished either by a
specific end-point, configured on the server, or by a header field recognized
by mod_session (or friends.)

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 56041] should be able to disable session expiry increment

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56041

--- Comment #1 from Erik Pearson <er...@adaptations.com> ---
I've made a first pass, adding a configuration parameter SessionRefreshExpiry.
This config can be set directly in a config file, or set via an If config,
triggered on a request header field. I tested with a header field named
"X-Session-Refresh-Expiry". Both direct config and via If behave as expected.

I have another couple of changes to sessions that I need for my current
project. One has been submitted in bugzilla as an enhancement (need to have
cookie with "session" lifetime), and another not submitted yet (need "hard
lifetime" of session -- the session may not live longer than this time limit.)

Is it better to submit these as additional patches or as one unified patch?
They involve the same set of files or at least overlap -- I don't know enough
about svn to determine how difficult it is to manage multiple patches as the
codebase is progressively modified without checkin...

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org