Thanks Florian, I'll try to come up with a sane patch based on this :) For generating secret, I would just update documentation to use something like:
$ openssl rand -base64 32 On Sun, Sep 23, 2012 at 2:54 PM, Florian Rüchel <florian.ruec...@gmail.com>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. > > 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 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. > > Regards, > Florian > > >> >> >> I prefer those secrets to exist outside of the code anyway, in separate >> file loaded by the app on start. I don't want them visible by teh GitHub >> staff. :) >> >> >> -- >> >> >> .oO V Oo. >> >> >> Work Hard, >> Increase Production, >> Prevent Accidents, >> and Be Happy! ;) >> >> -- > 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/-/y-mh0zjghJIJ. > > 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. > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. 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.
