https://github.com/plone/plone.session/blob/master/plone/session/tktauth.py
Have you been able to use your patch with Apache's mod_auth_tkt? On Sunday, September 23, 2012 12:03:43 PM UTC-4, Domen Kožar wrote: > > Created pull request, changed the approach a bit: > https://github.com/Pylons/pyramid/pull/695 > > On Sun, Sep 23, 2012 at 4:05 PM, Chris McDonough > <chr...@plope.com<javascript:> > > wrote: > >> On Sun, 2012-09-23 at 06:54 -0700, Florian Rüchel wrote: >> > >> > >> > 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). >> >> There's currently no machinery in Pyramid that can use a "secret file". >> Instead, developers are expected to add a secret value to their .ini >> file and use it as input to the AuthTktAuthenticationPolicy constructor. >> So I'd be -1 on something that created a file, unless there's some other >> use case that this sweater-thread of a topic has convinced us must be >> implemented along the lines of "the secret must be in another file". >> >> If the purpose is only to output a "sufficiently random" string, then I >> personally don't think we need to get into the business of supplying >> software that does that, although we might supply documentation for UNIX >> and for Windows that helps people do that using third-party tools. If >> that turns out to be untenable for some reason, then I might reconsider >> writing software that helps. >> >> > > 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. >> >> I'll defer to Domen on this. >> >> > >> > 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. >> >> Proceeding one step at a time. >> >> - C >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-devel" group. >> To post to this group, send email to pylons...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> pylons-devel...@googlegroups.com <javascript:>. >> 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 view this discussion on the web visit https://groups.google.com/d/msg/pylons-devel/-/M3T4DuD1fKwJ. 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.
