Revisiting the Defaulting of cookieProps, handlerSSL, etc.

Yuji Shinozaki ys2n at virginia.edu
Thu Jun 14 18:50:47 BST 2012


On Jun 14, 2012, at 1:01 PM, Nate Klingenstein wrote:

>> Probably the compromise would be to define some shorthand tokens that
>> represent baseline deployment assumptions and that would be more
>> self-evidently bad for production use, but it still implies somebody
>> making a change before production. But if you don't even do that to start
>> with, I'm not sure what I could do that would make that happen.
> 
> I like the suggestion of these tokens in addition to the current fully customizable model.  While you're right about still requiring active cogitation, I see value in making it easier for deployers to feel flip all of the relevant security bits(whose flipping could be consolidated) and feel confident they got them all; right now there are a few different changes and I could imagine people missing one.
> 
> I'm content to use the "initial testers" and "question deluge" answers as reason enough on the defaults, but would encourage others to weigh in.
> 

Could you have INFO or WARN-level logging indicating that a particular setting is not recommended for production?  Maybe with a reference to documentation?

yuji
----
Yuji Shinozaki
Technical Director, SHANTI
University of Virginia
http://shanti.virginia.edu
434-924-7171
ys2n at virginia.edu
----
"Computers are useless.  They only give you answers". --Pablo Picasso











More information about the dev mailing list