The middleware stack
Marc Munro
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.
Thanks
__
Marc
Michael Pedersen
--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
--
Michael J. Pedersen
My IM IDs: Jabber/pede...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171
Yahoo/pedermj2002, MSN/pederm...@hotmail.com
Diez B. Roggisch
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 <marc....@gmail.com>
> 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
Marc Munro
> 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?
I don't think so. IIRC the beaker session for an authenticated user is
determined from a session cookie for that user, so no-one should be able
to steal the session without being able to duplicate the cookie. If
anyone can do that, the standard auth_tkt mechanism is also insecure.
With my changes I can replace auth_tkt with beaker_tkt which gives me
the ability to retain much more identity information, and to keep it all
within the server.
FWIW, here is the code I am now using (share and enjoy):
class AppConfigByWho(AppConfig):
"""
AppConfig subclass that allows repoze.who to be managed from
a config file (who.ini). To setup who.ini, simply define it as
follows in your development.ini file (in the app:main section):
who.config_file = %(here)s/who.ini
who.log_level = debug
who.log_file = stdout
As well as providing repoze.who configuration through an ini file,
it also changes the order of items in the middleware stack. By
defining the core middleware after the authentication middleware,
the authentication middleware, when it runs, can access Beaker
sessions. This allows authentication information to be cached
locally, rather than in a client-side cookie.
"""
def add_auth_middleware(self, app, skip_authentication):
if config.get('who.config_file', None):
# We have a who.ini file, so we do authentication based on its
# contents
app = make_who_with_config(app,
config,
config.get('who.config_file','who.ini'),
config.get('who.log_file','stdout'),
config.get('who.log_level','debug'))
# Add core middleware after the authentication stuff rather
# than the other way round. This is done so that the
# authentication stuff can see the beaker.
from routes.middleware import RoutesMiddleware
from beaker.middleware import CacheMiddleware, SessionMiddleware
app = RoutesMiddleware(app, config['routes.map'])
app = SessionMiddleware(app, config)
app = CacheMiddleware(app, config)
return app
else:
# Quickstart based authentication
return super(VPDppConfig, self).__init__(app, skip_authentication)
def add_core_middleware(self, app):
"""
Do nothing as the core middleware is now being set up in
add_auth_middleware.
"""
return app
And in app_cfg.py:
base_config = AppConfigByWho()
__
Marc