Am 30.07.2010 um 07:08 schrieb Michael Pedersen:
Granted, I'm no expert on this, but since authentication has yet to
complete, didn't you just grant an unauthenticated user access to a
session that may or may not turn out to belong to that user?
Of course there is a theoretical risk of exposing information or being
exploitable the deeper a request penetrates the WSGI-stack.
But with that argumentation, every unauthorized request should be
rejected on a much earlier level - say the IP stack or so...
And what risk is there with the session alone? You could argue that
because you don't have a session, the authentication layer
uneccessarily needs access to the DB - on every request. Instead of
just reading something from memory. Which has it's own risk potential.
So IMHO it should be either configurable, or even the default that
authentication in TG2 works with an active session. The "problem" here
is the componentization I'd say - repoze.wh* is designed as stand-
alone component, that doesn't make any assumptions about WSGI-apps
above it. Which is of course a good thing by itself, but it's usage in
TG2 could be different, as the OP suggests - below the beaker
middleware. So that one can piggy-back on the session-cookie.
On Thu, Jul 29, 2010 at 2:25 PM, Marc Munro <[email protected]>
wrote:
Can anyone explain why authentication and authorization are performed
before the cache and session middleware is invoked?
I want my identification mechanism to be able to use the Beaker
session but this is not available until after authentication has
completed.
As an experiment I modified AppConfig.make_base_app to add the
authentication middleware before the core middleware and now my
identification functions can see the Beaker session.
Someone please tell me why what I have done is wrong.
It isn't, if it works for you. It is a design decision, but if you
decide otherwise and it works, go for it.
Diez
--
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en.