On Sunday, September 23, 2012 3:11:51 PM UTC+2, Chris McDonough wrote: > > On Sun, 2012-09-23 at 05:54 -0700, Florian Rüchel wrote: > > > > How about a script that's part of the framework itself? We > > have pserve, > > pcreate... how about > > > > pkeygen [-w <filename>] > > > > or > > > > pyramid-keygen [-w <filename>] > > > > I like this idea very much. I would like to either get this usage > > approved or I would just build a simple function inside pyramid. > > However, such a function belongs more into an installation than into > > application code. Can you tell me how to build such a script that runs > > on both Windows and Linux? I would like to see it implemented in this > > way if Chris approves. > > Who will use it and when would they use it? >
Well it will be used by the user deploying the application. This can be the developer or even multiple end-users (if the application itself is distributed). In both cases there would be a simple deployment instruction: "Upon installation you need to execute 'pyramid-keygen -w cookie_secret -b 256'" or similar. Then you have a secret file and can use it in your application. Otherwise each developer has to develop their own method of generating such a secret during the deployment process. Furthermore, we could then add a hint to the documentation to use this if they want a strong secret (see below). > > > On a seperate note: I have started on improving the documentation. As > > a first step, I have edited the `narr/authentication.rst` to include a > > note and have documented the API for > > `pyramid.authentication.AuthTktAuthenticationPolicy` (better > > documentation for secret, add documentation for hashalg). My question > > is now how would you handle this in regards to the documentation. I > > thought about adding this (or a similar) note everywhere this policy > > is used. This should raise the awareness everywhere the docs are read > > (e.g. tutorials). Furthermore, since we would clearly recommend to use > > something like SHA256 if MD5 is not explicitly needed, should we > > change the code examples to include a better hashalg (instead of just > > documenting it)? I would vote for a yes, since I don't see any > > disadvantage: If you build a new application, you should always use > > another algorithm and as shown above mod_auth_tkt can also easily > > handle other algorithms if configured correctly. > > I didn't know we already had a mergeable patch for the hashalg stuff. > The last patch I saw seemed maybe a little overwrought. Until we figure > that out, I'd hold off on changing docs. > Yeah, I took a step back, changed it to be only a callable and made it very simple again. Take look at the corresponding commit and tell me if it is still too much. If you approve, I would really recommend changing the docs at least in regards to a notice that the default behavior is at least not *that* secure. Regards, Florian > > > I would like to hear some opinions on this matter before I start to > > make big changes and only end up reverting them because you don't like > > it. My first version can be found here: > > > https://github.com/Javex/pyramid/commit/549db4b02cbff2c511eb026d3a5856b0b8fb3236 > > > > > I have also created a small `gensecret` function based on the ideas of > > Daniel and Domen (but with added Python3 compatibility): > > > https://github.com/Javex/pyramid/commit/d4f2943fa50e34f682f8097dccee2ce3ef1e998e > > > This function is not what I expect in the final version but it shows > > where I would like to go with this: Provide a function that makes it > > easier for a user to obtain a strong secret. Either we use it this way > > or the above mentioned seperate script, that really doesn't matter. > > > > Please tell me your thoughts on both topics. > > > - C > > > > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/pylons-devel/-/V-BMy3JNpkMJ. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
