To clarify, I did lodge a bug report https://issues.apache.org/bugzilla/show_bug.cgi?id=56038
A quick fix of the affected code did get SessionExclude working. The behavior is that no session is loaded, so if SessionExclude is applied to a location which requires authentication, the authentication requirement will fail, so this is not a solution to preventing session refresh (unless applied to a resource which doesn't require authentication.) On Mon, Jan 20, 2014 at 10:49 AM, Erik Pearson <e...@adaptations.com> wrote: > Okay, I take that back. Call me an Apache idiot. > The SessionExclude directive did not work. I could not get it to work for > any path prefix. I'm taking a closer look at mod_session.c to see how this > should work. Strangely enough, and I dare barely suggest this, there > appears to be a bug in mod_session regarding the application of > SessionExclude unless there were also SessionIncludes. I'll pursue this as > bug report. > > > > On Mon, Jan 20, 2014 at 8:10 AM, Erik Pearson <e...@adaptations.com>wrote: > >> Well, it looks like I've just answered one of my questions. The >> "SessionExclude" directive "allows sessions to be disabled relative to URL >> prefixes". I had not tried this because I don't want sessions to be >> completely disabled. However, desperate, I tried it. It apparently does not >> completely disable sessions -- they are still understood by mod_auth_form >> -- but it does prevent sessions from being updated. >> >> The language in the docs is confusing, because it both uses words like >> "disabled" or "valid" to describe the effect of SessionExclude and >> SessionInclude, which implies to me that anything that depends on sessions >> like mod_auth_form would not see a session. Yet the same sections also >> mention session "maintenance", which implies the act of refreshing a >> session expiry, max-age, and sessionheader through set-cookie. >> >> My testing shows that when SessionExclude is in effect, the mod_auth_form >> does indeed still see the session -- session crypto even works -- on a url >> that is excluded via SessionExclude -- and the expiry is not updated. >> >> >> On Mon, Jan 20, 2014 at 7:23 AM, Erik Pearson <e...@adaptations.com>wrote: >> >>> Greetings Apache httpd community, >>> >>> I'm following up to myself, since I've had no response to the initial >>> query. I'm hoping that someone with session experience can help! >>> >>> I am using Apache httpd 2.4.7 on ArchLinux, and have questions about >>> mod_session usage. I'm using mod_auth_form and mod_session to provide >>> authenticated access to specific urls. The basic configuration is fully >>> functional. Authenticating through a hosted form works great, session >>> cookies and session encryption works fine. I can access a protected >>> resource by logging in, and logout either explicitly through a logout url >>> or through session timeout. This is on a virtual host. >>> >>> But, alas, there are two problems remaining. >>> >>> First, I need to access the server under authentication but without >>> updating the expiry of the session. I need this functionality for at least >>> two reasons so far. For one, some pages engage in auto-refreshing via ajax >>> calls. This auto refreshing should not necessarily keep the browser logged >>> in. But since each ajax call refreshes the expiry, the effect is a >>> permanent session as long as an auto-refreshing page is open. >>> >>> Second, I need the session cookie to have a "session" MaxAge -- that is, >>> to be deleted when the browser is closed/reopened. However, mod_session >>> always sets the cookie MaxAge to the same value as the expiry. >>> >>> I have found some but scant advice on this topic. It makes sense, but I >>> can't get it to work. One fix I found for MaxAge is to use >>> >>> Header edit Set-Cookie ;Max-Age=XXX ; >>> >>> Where XXX is the max age value set in the conf file. I have this line >>> placed below the primary session configuration: >>> >>> Session On >>> SessionEnv On >>> SessionCookieName session path=/ >>> SessionMaxAge 120 >>> >>> Header edit Set-Cookie ;Max-Age=XXX ; >>> >>> Alas the Header edit line did nothing. >>> >>> I have not found any advice for disabling session cookie updating, but I >>> figured that removing the response's Set-Cookie header field would >>> effectively prevent the cookie's update. So I added the header line: >>> >>> Header unset Set-Cookie >>> >>> Alas, this does nothing either. I've tested the same line for removing >>> cookie set with a "Header set Set-Cookie" which sets a test cookie, and >>> then later removes it with unset, and this worked as expected. >>> >>> I am figuring that perhaps mod_header runs before mod_session injects >>> the Set-Cookie header field. The document suggests that mod_header's late >>> hook is in the fixup phase, which is before content. mod_session must >>> inject the header after the content phase because it accepts a modification >>> of the session cookie through, at least, through SessionHeader (I'm using >>> scgi proxying). >>> >>> I am far far from knowing my way well around httpd module phases. I'm >>> hoping someone with experience in this area can help set me straight. >>> >>> >>> >>> >>> On Thu, Jan 16, 2014 at 10:54 AM, Erik Pearson <e...@adaptations.com>wrote: >>> >>>> Hi, >>>> I've just started using Apache sessions in 2.4.7, in combination with >>>> mod_auth_form. It is working great. It is fronting a web app running under >>>> SCGI and that part is working fine as well. >>>> On a page that is protected by authentication I have ajax calls to >>>> urls that are also under authentication. The page refreshes the data >>>> periodically (via a timer that reruns the ajax, rerenders the display). An >>>> untended side effect is that the session never expires, since the ajax >>>> calls cause the session expiration to be refreshed. I need the ajax calls >>>> to use the session for authentication, but not refresh the expiration time >>>> (well, I may need to provide an option to let the user keep the session >>>> alive, but by default I think it should eventually expire.) What I would >>>> like to do is supply, say, an http header that would inhibit the refreshing >>>> of the expiration time. I did not find such in the documentation, or the >>>> question posted on the list. >>>> My question is -- is there such an option that I may have missed, or >>>> has any one accomplished this behavior through some other means? >>>> I can work around it by using a separate timer on the page that will >>>> automatically log the user out after a certain amount of time, but would >>>> rather also have a method that works with the native httpd session. >>>> Thanks, >>>> Erik. >>>> >>> >>> >>> >>> -- >>> Erik Pearson >>> Adaptations >>> ;; web form and function >>> >> >> >> >> -- >> Erik Pearson >> Adaptations >> ;; web form and function >> > > > > -- > Erik Pearson > Adaptations > ;; web form and function > -- Erik Pearson Adaptations ;; web form and function
