Hi.
Got a brainstorming question for the repoze.zope2 folks.
Currently repoze.zope2 reuses the Zope2 ZPublisher request object pretty
much directly. This is nice for full backwards compatibility, which has
been a primary concern during its initial development.
At some point in the Zope2 or at le
2009/3/5 Hanno Schlichting :
> Opinions?
I think it's a good idea, since it's kind of a show-stopper for
all-unicode applications to deal with a non-unicode request object.
Non-unicode strings aren't here to stay :-)
\malthe
___
Repoze-dev mailing list
The way WebOb deals with this is by allowing users to supply a "default_charset"
attribute on requests (or during request construction). It'd probably be enough
to allow people to do the same for Zope requests (maybe as a zope2.ini
parameter); when it's non-None, use that as the charset to decode
Hello, everybody.
I just released repoze.what v1.0.6, a minor release which fixes a issue in the
deprecated repoze.what.authorize.check_authorization() function (predicates
were not correctly evaluated if the __nonzero__ method was defined), as
reported by Michael Brickenstein.
Note that it's
FTR, repoze.what-pylons users (includes TG2 users) have nothing to worry
about.
On Thursday March 5, 2009 18:38:36 Gustavo Narea wrote:
> Hello, everybody.
>
> I just released repoze.what v1.0.6, a minor release which fixes a issue in
> the deprecated repoze.what.authorize.check_authorization() f
Hello, *.
Some TurboGears 2 developers, including myself, are going to audit security-
related packages used in TurboGears 2 by default. It's going to be a one-day
sprint, on March 8th.
I'd say 90-95% of the audit will focus on Repoze packages and 5-10% will focus
on TG2 itself, so I'd like to
New submission from ken :
When you do:
1) login in "https"
2) all other in "http"
3) use Opera client
4) use non-standard port
5) use AuthTkt cookie plugin
then port left in the domain in the cookie prevent Opera client to send cookie
to other port (i.e. http).
Solution: just remove port from c
