Hi Graham, On Wed, Jan 29, 2014 at 2:51 PM, Graham Leggett <minf...@sharp.fm> wrote:
> On 29 Jan 2014, at 11:17 PM, Erik Pearson <e...@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
