> How about a script that's part of the framework itself? We have pserve,
> pcreate... how about
> pkeygen [-w <filename>]
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:
I have also created a small `gensecret` function based on the ideas of
Daniel and Domen (but with added Python3 compatibility):
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.
> 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! ;)