mod_session and friends need some help

[Erik Pearson <er...@adaptations.com>]

Hi,
I recently began using mod_session, mod_session_cookie, mod_session_crypto,
and mod_auth_form (forgetting anyone?) in httpd 2.4.x to provide an
authentication front end to a web app. In my efforts to meet requirements
and solve session bugs I've needed to jump in and make a few changes to the
source for those modules. There are some fairly basic logic and programming
errors that need correction as well as enhancements. I am not a daily,
weekly, or even monthly c programmer but I've muddled my way through.

Some of those issues were raised recently by myself in bugzilla:

ap_session_load called multiple times for expired session creates new
session each time
https://issues.apache.org/bugzilla/show_bug.cgi?id=56052

should be able to disable session expiry increment
https://issues.apache.org/bugzilla/show_bug.cgi?id=56041

should be able to remove Max-Age cookie parameter to enable "session"
cookies
https://issues.apache.org/bugzilla/show_bug.cgi?id=56040

mod_session excludes not processed correctly
https://issues.apache.org/bugzilla/show_bug.cgi?id=56038

I am prepared to sooner than later submit the changes as patches, after
I've had a chance to make sure they work, clean up the code and comments,
and find some time. I for sure need these changes, otherwise mod_session
and friends are just not usable.

I understand all patches should be submitted through bugzilla. I really
have to jam through these changes for a current project, so it would be
difficult to submit a patch for each issue. Would it be acceptable to
submit a related set of patches to code and documentation, accompanied by a
comment or document that describes the whys and wherefores? Would that make
the process of patch evaluation too complicated?

If anyone is interested in discussing mod_session issues on this forum or
privately I'm happy to entertain. There was a recent thread on the list
"Re: unsetting encrypted cookies when encryption key changes" that is I
believe addressed by one the changes.

Thanks for your advice,
Erik.

Re: mod_session and friends need some help

[Erik Pearson <er...@adaptations.com>]

Hi Graham,

Thanks for giving me the opportunity to describe what I need to achieve.
Here is what I can glean from my recent trail of breadcrumbs:

1. Configure the session cookie to be deleted when a browser is restarted,
regardless of the session expiry.

2. Ability to utilize a session without renewing the expiry, and preferably
have this controlled by the request so that the same url can either case
the session to be renewed or not, and the client code can make that
decision.

3. Have session expiry value exposed to cgi application, similar to
HTTP_SESSION

4. Have a session cookie be immediately removed. (new)

5. Have a session be available if it already exists, but not be created if
it does not yet exist. More specifically, don't create a session or session
cookie if there is not already a session cookie. (new)

6. Solve the "double login problem" with mod_auth_session, in which
attempting to log in with an expired session requires two login attempts
for success.

7. Solve the "changed encryption key" problem, in which a changed
SessionCryptoPassphrase does not cause a session encrypted with the old key
to be replaced, thus preventing the use of the session.

I can provide more details. So far I have solutions to all of these, but
certainly may have gone about it the wrong way.

Thanks again,
Erik.


On Fri, Jan 31, 2014 at 2:16 AM, Graham Leggett <mi...@sharp.fm> wrote:

> On 30 Jan 2014, at 7:01 PM, Erik Pearson <er...@adaptations.com> wrote:
>
> On this specific sub-thread, you chose to single out a single topic. When
> you asked "I'm not following the problem you're trying to solve.", I
> chose to list the number of enhancements and bugs that I've encountered
> over a few days of working on the mod_session and friends code. I'm sorry,
> I didn't mean that to be taken as piling on, but merely to show that I've
> thought and worked hard on this issue,  that my concerns are not trivial,
> and that this single issue (where the "name" for a session is configured)
> is just one small part of a larger puzzle.
>
>
> The trouble is you've described various technical changes you want to
> make, but you haven't described in any way the problem you're trying to
> solve.
>
> You hinted at one - the ability to access the session but without
> refreshing it, for example during ajax calls. You'll very likely find what
> you want to achieve is very simple, but until we know what you want to
> achieve, we can't help you.
>
> Regards,
> Graham
> --
>
>


-- 
Erik Pearson
Adaptations
;; web form and function

Re: mod_session and friends need some help

[Graham Leggett <mi...@sharp.fm>]

On 30 Jan 2014, at 7:01 PM, Erik Pearson <er...@adaptations.com> wrote:

> On this specific sub-thread, you chose to single out a single topic. When you asked "I'm not following the problem you're trying to solve.", I chose to list the number of enhancements and bugs that I've encountered over a few days of working on the mod_session and friends code. I'm sorry, I didn't mean that to be taken as piling on, but merely to show that I've thought and worked hard on this issue,  that my concerns are not trivial, and that this single issue (where the "name" for a session is configured) is just one small part of a larger puzzle.

The trouble is you've described various technical changes you want to make, but you haven't described in any way the problem you're trying to solve.

You hinted at one - the ability to access the session but without refreshing it, for example during ajax calls. You'll very likely find what you want to achieve is very simple, but until we know what you want to achieve, we can't help you.

Regards,
Graham
--

Re: mod_session and friends need some help

[Erik Pearson <er...@adaptations.com>]

Good Morning Graham,

On Thu, Jan 30, 2014 at 1:48 AM, Graham Leggett <mi...@sharp.fm> wrote:

> On 30 Jan 2014, at 3:32 AM, Erik Pearson <er...@adaptations.com> wrote:
>
> > Au contraire -- most of the changes I'm making are driven by the
> application need, not just to clean up the code. Of course I do also have
> an interest in the design of the modules, from a programmer's perspective.
> But isn't this the forum for such considerations?
>
> If you want to engage the community, you don't start with the position
> "everything's broken, and I demand you fix it for me". In this email alone
> you list functionality that you insist doesn't exist but does, you list
> feature requests, you list bugs that apparently exist but aren't
> articulated well enough to do anything to fix, and you're arguing that we
> should change the underlying design.
>
> Please identify one specific issue that reflects your need, and keep on
> topic with that issue until it is resolved.
>

I'm sorry if that came off with the wrong attitude! I thought I was
responding in a repartee fashion. The point I was first trying to make is
that there are some rather fundamental changes that I have made to
mod_session and friends, in order to fit my application requirements, and,
contrary to my instincts and the advice I had received on the list, I don't
think it can be handled (if it were to be contributed back to the project)
as piecemeal, single-issue diffs.

On this specific sub-thread, you chose to single out a single topic. When
you asked "I'm not following the problem you're trying to solve.", I chose
to list the number of enhancements and bugs that I've encountered over a
few days of working on the mod_session and friends code. I'm sorry, I
didn't mean that to be taken as piling on, but merely to show that I've
thought and worked hard on this issue,  that my concerns are not trivial,
and that this single issue (where the "name" for a session is configured)
is just one small part of a larger puzzle.

Really, seriously, I''m humbled by the entire Apache httpd project -- I am
merely stumbling along my path, stubbornly attempting to solve the
challenges between me and the successful implementation of this project.


>
> > All I really did was to recognize that there is a pattern in any storage
> module which uses a cookie to associate a browser with a session -- the
> session name. Rather than have each storage module mod_session_foo
> implement this config item as SessionFooCookieName, why not make it a core
> property of a session? And once you do that, why not just default that to
> some sensible string like "mod_session"? Is there, realistically, a session
> storage module that would not use cookies as a browser association method
> (at least as an option)?
>
> Yes there is, please familiarise yourself with per user sessions:
> http://httpd.apache.org/docs/2.4/mod/mod_session_dbd.html#peruser


I'm aware of the "per user" mode of mod_session_dbd -- my wording was
careful, since mod_session_dbd includes cookies as a strategy. Whereas I
was at first puzzled to discover per user mode, since it turns the session
on its head, I now think it is a clever and very specific type of session,
at the one extreme it is a lightweight user account. But I won't go off
topic -- I still don't see that any session storage submodule won't support
the session cookie as a method of sticking to a browser (while they may
also support other methods).

Cheers, Erik.



>
>
> Regards,
> Graham
> --
>
>


-- 
Erik Pearson
Adaptations
;; web form and function

Re: mod_session and friends need some help

[Graham Leggett <mi...@sharp.fm>]

On 30 Jan 2014, at 3:32 AM, Erik Pearson <er...@adaptations.com> wrote:

> Au contraire -- most of the changes I'm making are driven by the application need, not just to clean up the code. Of course I do also have an interest in the design of the modules, from a programmer's perspective. But isn't this the forum for such considerations?

If you want to engage the community, you don't start with the position "everything's broken, and I demand you fix it for me". In this email alone you list functionality that you insist doesn't exist but does, you list feature requests, you list bugs that apparently exist but aren't articulated well enough to do anything to fix, and you're arguing that we should change the underlying design.

Please identify one specific issue that reflects your need, and keep on topic with that issue until it is resolved.

> All I really did was to recognize that there is a pattern in any storage module which uses a cookie to associate a browser with a session -- the session name. Rather than have each storage module mod_session_foo implement this config item as SessionFooCookieName, why not make it a core property of a session? And once you do that, why not just default that to some sensible string like "mod_session"? Is there, realistically, a session storage module that would not use cookies as a browser association method (at least as an option)?

Yes there is, please familiarise yourself with per user sessions: http://httpd.apache.org/docs/2.4/mod/mod_session_dbd.html#peruser

Regards,
Graham
--

Re: mod_session and friends need some help

[Erik Pearson <er...@adaptations.com>]

Hi Graham,

On Wed, Jan 29, 2014 at 2:51 PM, Graham Leggett <mi...@sharp.fm> wrote:

> On 29 Jan 2014, at 11:17 PM, Erik Pearson <er...@adaptations.com> wrote:
>
> > Actually, the more I've delved and actually used mod_session and
> friends, the more fundamental the changes have become. For instance, a lot
> of the code that lives in mod_session_cookie and mod_session_dbd seems more
> appropriate for mod_cookie -- including session name, session caching,
> session object creation. With such changes, it is quite difficult to
> isolate into single issue diffs.
>
> I'm not following the problem you're trying to solve.
>


- adding the ability to have "session" cookies (that die when the browser
is restarted)
- adding the ability to disable session renewal (i.e. leave the expiry
alone) - important for allowing things like ajax connections to not keep
the session alive artificially.
- add expiry to the env so that web apps can determine the amount of time
left in the session -- for user interface features.

- a bug in mod_session involving session decrypting after a changed key
- a bug in session caching that causes session consumers (e.g.
mod_auth_form) to receive the wrong session object (which just points out
the problem with having the storage modules manage session caching and
session object creation).

- simplifying session configuration: moving session name to mod_session
allows removing the name configuration altogether, simplify cookie
configuration by separating cookie attributes from cookie name.


> It seems you're trying to rearrange and group technologies together from a
> programmer's perspective, instead of grouping functionality together from
> an end user's perspective.
>

Au contraire -- most of the changes I'm making are driven by the
application need, not just to clean up the code. Of course I do also have
an interest in the design of the modules, from a programmer's perspective.
But isn't this the forum for such considerations?


>
> Right now, if an end user wants to store a session in a datastore of some
> kind, in the classic "application server" model, storing a reference to
> that session in a cookie, they enable mod_session_dbd. If instead the end
> user wants to store the whole session in the body of a cookie on the
> client, they enable mod_session_cookie. In future, should the end user want
> to store a session in memory, they might use a future mod_session_socache.
> What you seem to want to do is combine mod_session_cookie and
> mod_session_dbd, simply because a cookie is involved in both.
>

All I really did was to recognize that there is a pattern in any storage
module which uses a cookie to associate a browser with a session -- the
session name. Rather than have each storage module mod_session_foo
implement this config item as SessionFooCookieName, why not make it a core
property of a session? And once you do that, why not just default that to
some sensible string like "mod_session"? Is there, realistically, a session
storage module that would not use cookies as a browser association method
(at least as an option)?

This simplifies the storage modules, both in code and configuration.


> That doesn't make life easier for end users, who are only interested in
> getting a job done.
>

Aye, it has already simplified my configuration and made my life easier,
other than having to slog through the code. But, seriously, as an end user,
it is just a minor config change.

Frankly, I don't think most end users care to give the session a name at
all, and when they do, don't give a hoot whether it is SessionName or
SessionCookieName. They may well appreciate a standard name as a default,
like "mod_session", or "apache_session" or some such thing that would be
recognizable when inspecting cookies in a browser. The current
implementation requires the end user to provide a cookie name, and
conflates cookie name with cookie properties.

Of course, there may be use cases that the current implementation is
designed to address. That is what I'm hoping will come out of the woodwork,
for it is not documented in the code.

Cheers,
Erik.


>
> Regards,
> Graham
> --
>
>


-- 
Erik Pearson
Adaptations
;; web form and function

Re: mod_session and friends need some help

[Graham Leggett <mi...@sharp.fm>]

On 29 Jan 2014, at 11:17 PM, Erik Pearson <er...@adaptations.com> wrote:

> Actually, the more I've delved and actually used mod_session and friends, the more fundamental the changes have become. For instance, a lot of the code that lives in mod_session_cookie and mod_session_dbd seems more appropriate for mod_cookie -- including session name, session caching, session object creation. With such changes, it is quite difficult to isolate into single issue diffs.

I'm not following the problem you're trying to solve.

It seems you're trying to rearrange and group technologies together from a programmer's perspective, instead of grouping functionality together from an end user's perspective.

Right now, if an end user wants to store a session in a datastore of some kind, in the classic "application server" model, storing a reference to that session in a cookie, they enable mod_session_dbd. If instead the end user wants to store the whole session in the body of a cookie on the client, they enable mod_session_cookie. In future, should the end user want to store a session in memory, they might use a future mod_session_socache. What you seem to want to do is combine mod_session_cookie and mod_session_dbd, simply because a cookie is involved in both.

That doesn't make life easier for end users, who are only interested in getting a job done.

Regards,
Graham
--

Re: mod_session and friends need some help

[Erik Pearson <er...@adaptations.com>]

Actually, the more I've delved and actually used mod_session and friends,
the more fundamental the changes have become. For instance, a lot of the
code that lives in mod_session_cookie and mod_session_dbd seems more
appropriate for mod_cookie -- including session name, session caching,
session object creation. With such changes, it is quite difficult to
isolate into single issue diffs. On the other hand, the changes may be
fundamental and breaking enough that should I share them back it might be
better for them to become new modules. The incompatibilities are mostly in
configuration, but there is one element of the session load hook that would
be slightly different. The interface with session consumers is not changed,
of course. What do you think?


On Thu, Jan 23, 2014 at 10:41 AM, Plüm, Rüdiger, Vodafone Group <
ruediger.pluem@vodafone.com> wrote:

>  Looks good. If you like git more you can also use git (
> http://git.apache.org/httpd.git) create local branches for each patch and
> submit the diffs.
>
>
>
> Regards
>
>
>
> Rüdiger
>
>
>
> *Von:* Erik Pearson [mailto:erik@adaptations.com]
> *Gesendet:* Donnerstag, 23. Januar 2014 18:01
> *An:* dev@httpd.apache.org
> *Betreff:* Re: mod_session and friends need some help
>
>
>
> Thanks. That was what I was afraid of, but is sensible. From my point of
> view, I guess I could have a spare copy of 2.4.x to which I apply one patch
> at a time, purely for the purposes of patch submission? I probably can't
> hold up my work by waiting for 5 or 6 patches to be processed sequentially.
>
> Since patches are not submitted via svn, here is how I understand the
> process of patch submission:
>
>
>
> 1. obtain copy of 2.4.x via svn checkout
>
> 2. edit files involved in one change
>
> 3. create patch files with svn diff
>
> 4. submit patch files via bugzilla
>
> 5. via bugzilla engage with httpd developers to get the patch accepted (or
> not)
>
> 6. after patch is accepted and applied, the local copy needs to be
> reverted and updated (or just deleted and checked out again) so that future
> edits are against the newly patched codebase.
>
>
>
> For multiple patches, just repeat.
>
>
>
> Is that about it?
>
>
>
> On Thu, Jan 23, 2014 at 4:11 AM, Eric Covener <co...@gmail.com> wrote:
>
> On Thu, Jan 23, 2014 at 1:35 AM, Erik Pearson <er...@adaptations.com>
> wrote:
> > Would it be acceptable to submit a related set of patches to code and
> > documentation, accompanied by a comment or document that describes the
> whys
> > and wherefores? Would that make the process of patch evaluation too
> > complicated?
>
> Generally, that makes things harder on the potential reviewer and
> slows things down.
>
>
>
>
>
> --
> Erik Pearson
> Adaptations
> ;; web form and function
>



-- 
Erik Pearson
Adaptations
;; web form and function

AW: mod_session and friends need some help

[Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>]

Looks good. If you like git more you can also use git (http://git.apache.org/httpd.git) create local branches for each patch and submit the diffs.

Regards

Rüdiger

Von: Erik Pearson [mailto:erik@adaptations.com]
Gesendet: Donnerstag, 23. Januar 2014 18:01
An: dev@httpd.apache.org
Betreff: Re: mod_session and friends need some help

Thanks. That was what I was afraid of, but is sensible. From my point of view, I guess I could have a spare copy of 2.4.x to which I apply one patch at a time, purely for the purposes of patch submission? I probably can't hold up my work by waiting for 5 or 6 patches to be processed sequentially.
Since patches are not submitted via svn, here is how I understand the process of patch submission:

1. obtain copy of 2.4.x via svn checkout
2. edit files involved in one change
3. create patch files with svn diff
4. submit patch files via bugzilla
5. via bugzilla engage with httpd developers to get the patch accepted (or not)
6. after patch is accepted and applied, the local copy needs to be reverted and updated (or just deleted and checked out again) so that future edits are against the newly patched codebase.

For multiple patches, just repeat.

Is that about it?

On Thu, Jan 23, 2014 at 4:11 AM, Eric Covener <co...@gmail.com>> wrote:
On Thu, Jan 23, 2014 at 1:35 AM, Erik Pearson <er...@adaptations.com>> wrote:
> Would it be acceptable to submit a related set of patches to code and
> documentation, accompanied by a comment or document that describes the whys
> and wherefores? Would that make the process of patch evaluation too
> complicated?

Generally, that makes things harder on the potential reviewer and
slows things down.



--
Erik Pearson
Adaptations
;; web form and function

Re: mod_session and friends need some help

[Eric Covener <co...@gmail.com>]

ideally, trunk. If they're accepted

On Thu, Jan 23, 2014 at 12:01 PM, Erik Pearson <er...@adaptations.com> wrote:
> Thanks. That was what I was afraid of, but is sensible. From my point of
> view, I guess I could have a spare copy of 2.4.x to which I apply one patch
> at a time, purely for the purposes of patch submission? I probably can't
> hold up my work by waiting for 5 or 6 patches to be processed sequentially.
> Since patches are not submitted via svn, here is how I understand the
> process of patch submission:
>
> 1. obtain copy of 2.4.x via svn checkout
> 2. edit files involved in one change
> 3. create patch files with svn diff
> 4. submit patch files via bugzilla
> 5. via bugzilla engage with httpd developers to get the patch accepted (or
> not)
> 6. after patch is accepted and applied, the local copy needs to be reverted
> and updated (or just deleted and checked out again) so that future edits are
> against the newly patched codebase.

ideally work based on trunk.  This will also shorten how long it takes
to get rid of your local changes.

You can back them out after you create the diff and accept what gets
committed, which might have minor changes that would conflict with
your stuff

>
> For multiple patches, just repeat.
>

yes, and send an email if not getting any attention in bugzilla.

Re: mod_session and friends need some help

[Erik Pearson <er...@adaptations.com>]

Thanks. That was what I was afraid of, but is sensible. From my point of
view, I guess I could have a spare copy of 2.4.x to which I apply one patch
at a time, purely for the purposes of patch submission? I probably can't
hold up my work by waiting for 5 or 6 patches to be processed sequentially.
Since patches are not submitted via svn, here is how I understand the
process of patch submission:

1. obtain copy of 2.4.x via svn checkout
2. edit files involved in one change
3. create patch files with svn diff
4. submit patch files via bugzilla
5. via bugzilla engage with httpd developers to get the patch accepted (or
not)
6. after patch is accepted and applied, the local copy needs to be reverted
and updated (or just deleted and checked out again) so that future edits
are against the newly patched codebase.

For multiple patches, just repeat.

Is that about it?


On Thu, Jan 23, 2014 at 4:11 AM, Eric Covener <co...@gmail.com> wrote:

> On Thu, Jan 23, 2014 at 1:35 AM, Erik Pearson <er...@adaptations.com>
> wrote:
> > Would it be acceptable to submit a related set of patches to code and
> > documentation, accompanied by a comment or document that describes the
> whys
> > and wherefores? Would that make the process of patch evaluation too
> > complicated?
>
> Generally, that makes things harder on the potential reviewer and
> slows things down.
>



-- 
Erik Pearson
Adaptations
;; web form and function

Re: mod_session and friends need some help

[Eric Covener <co...@gmail.com>]

On Thu, Jan 23, 2014 at 1:35 AM, Erik Pearson <er...@adaptations.com> wrote:
> Would it be acceptable to submit a related set of patches to code and
> documentation, accompanied by a comment or document that describes the whys
> and wherefores? Would that make the process of patch evaluation too
> complicated?

Generally, that makes things harder on the potential reviewer and
slows things down.