Unfortunately I stopped using apache as web server back in 2006, could someone else try that? Thanks!
On Mon, Sep 24, 2012 at 3:58 PM, Daniel Holth <dho...@gmail.com> wrote: > 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 <https://github.com/Pylons/pyramid/pull/695> >> >> On Sun, Sep 23, 2012 at 4:05 PM, Chris McDonough <chr...@plope.com>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. >>> To unsubscribe from this group, send email to pylons-devel...@** >>> googlegroups.com. >>> >>> For more options, visit this group at http://groups.google.com/** >>> group/pylons-devel?hl=en<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. > -- 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.
