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,
>
> How about a script that's part of the framework itself? We have pserve,
> pcreate... how about
>
> pkeygen [-w ]
>
> or
>
pyramid-keygen [-w ]
>
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,
I have reworked my code with your comments. I now only support callables, I
changed the documentation and removed the now invalid tests. Everything
seems to run just fine, so I merged all commits into one which you can now
easily review. I hope this suits your needs more.
Please let me know if
Hi Domen,
I would agree with you if it would really complicate things much, but I
can't see why it would. All those cases are really simple to implement and
I don't see any security risks either as the configuration of the hash
algorithm is under full control of the application developer using
I have a question on tests:
Four tests in "pyramid.tests.test_authentication.TestAuthTktCookieHelper"
worry me: They do something like
values = self._parseHeaders(result)
val = self._cookieValue(values[0])
Which fails with
return eval(cookie.value)
{'secure': False, 'remote_addr': '0.0.0.0', 'co
78ed\
>>
>>
>> Cool. We should do something similar I guess.
>> >
>> > On Sun, Sep 9, 2012 at 4:56 PM, Chris McDonough
>> >
>> >
>> > wrote:
>> > On Sun, 2012-09-09 at 06:55 -0700, Florian Rüchel wrote:
>> &
I was getting interested in how Pyramid's authentication works and looked
through the commonly used AuthTktAuthenticationPolicy code. I found out it
uses MD5 and the only thing keeping the cookie from being forged is the
secret.
I see two different issues here:
First, MD5 is already known to ha
