Chris Darroch wrote:

  Great idea.  What would you think about converting from
the session_save hook to a provider-based mechanism?  I can
imagine that administrators might want/need to use one kind of
storage provider (dbd, say) for sessions on high-priority virtual hosts,
while using another less reliable storage provider on others.

  Maybe this is possible with hooks if the storage modules return
DECLINED unless they're the one that's most closely configured
with a particular request.  Still, it might be a little cleaner
if the caller just looks up the appropriate provider and calls it
directly.
>
  Again, great idea, thanks!

The session modules are all designed to go exclusively inside Directory and Location sections, which allow you to precisely target which URL space your session is valid for, and this can be repeated as many times as you like creating as many individual sessions as you like.

So for an online store, you might have example.com/store covered by a low security session keeping track of basic user details and a shopping cart, while example.com/checkout is protected by a separate high security session based on dbd or crypto.

Eg:

<Location /store>
  Session On
  SessionCookieName shopping
  ...
</Location>
<Location /checkout>
  Session On
  SessionDBDCookieName checkout
  SessionCryptoPassphrase secret
  ...
</Location>

Is this what you had in mind?

  Once more, with feeling, I'll plug the notion of a generic mod_shmap
that implements shared map (key/value pair) storage, using any of
various providers for each map: dbd, dbm, shared memory (w/ cyclic buffer),
distcache, maybe memcached, etc.

Definitely.

Something I would like to see for a future 2.4 or 3.0 release is to achieve the goal of consolidation:

Identify areas of the server where functionality is being reinvented over and over, and then create key modules, like mod_shmap and mod_session to replace the reinvented functionality.

Then: collapse the repeated code.

The ultimate goal will be a smaller, tighter, but significantly more flexible server.

Regards,
Graham
--

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to