on Monday, October 27, 2008, 12:16:42 PM Hans wrote:
Hi Anton,
thank you for the patches. I have committed the CL+SSL patch both upstream and in my repository.
For the session secret update:
- The name *SESSION-SECRETIZER* really does not cut it. I would
suggest that *SESSION-SECRET-SALT* is more suitable.
Yes, that's better :)
- The docstring and documentation file should be clear about the
expected datatype of the variable (string?)
Yes, I forgot. It must be string.
- I don't like the warning if the only way to set up the salt is
setting the special variable.
- Maybe it would be better to supply the concerned user with a way to
override the ENCODE-SESSION-STRING function instead of having them mess with the internals of the current session secret encoding function.
Overriding ENCODE-SESSION-STRING is more complex responsibility for users - they must deal with four parameters: session-id, user-agent, remote-addres and session-start-time; and with *USE-USER-AGENT-FOR-SESSIONS*, *USE-REMOTE-ADDR-FOR-SESSIONS*; and they must understand that the result must unique and unguessable.
I also thought about providing a possibility to overrride RESET-SESSION-SECRET, as you suggested in the previous email (btw, how "overrride"? just redefine or clos-specialize on artificially introduced parameter). But in this case we need to export both RESET-SESSION-SECRET and *SESSION-SECRET* and explain people that generated secret must every time be not only unguessable but also unique, which is an extra responsibility for them.
Therefore, although I do not like too much introduction of the new special variable, it is the simplest way I see. The only thing we need is the salt, and users just provide it. Hunchentoot does all the remaining job.
I would like to know what Edi thinks about this before committing this or any other patch to the repository.
Ok.
Best regards, - Anton