identity suggestion
jvanasco
after working quite a bit on my own, then taking some advice from the
folks on the cherrypy list, i'd like to suggest this improvement that
should be compatible with the current id system
it cuts down on the function calls by a great deal -- the secure
resource works by overriding the __getattribute__ builtin, then doing
some stuff that I think is kind of scary to figure out if it should run
or not. it also runs several times throughout the filter chain, so you
end up with many calls to it and numerous predicate checks.
this approach might not be suitable for all situations ( i didn't
integrate a secured object ), but i'm suggesting it as a stepping stone
to a more efficient system
=====
url_login_required= "/path/to/login"
class SecuredControllerFilter(object):
"""
This filter runs 1x on a before_main to make sure that our secured
resource has permissions
"""
def before_main(self):
if not get_request_privileged():
raise SecuredControllerFailure()
class SecuredController(tg.controllers.Controller):
"""
secured resources inherit from this controller.
The class is blank when we define it, as it needs some magic done
on startup
"""
pass
def _SecuredController_init():
"""
this is our magic startup hook
it copies the root filters from TG (not available earlier), and
appends our Secured filter to it
caveat: i have no idea how to integrate this better so we can
recognze diffferent _cp_filters per mounted tree element
"""
SecuredController._cp_filters= [i for i in
cherrypy.root._cp_filters]
SecuredController._cp_filters.append( SecuredControllerFilter() )
class SecuredControllerFailure(cherrypy.InternalRedirect):
"""
Our failure class
"""
def __init__(self):
cherrypy.InternalRedirect.__init__(self, url_login_required)
def get_request_privileged():
"""
code here for predicate checking by whatever you want
"""
pass
def page_user_startup():
"""called during TG startup. integrates our class into the
cherrypy request API"""
_SecuredController_init()
=====
Alberto Valverde
> i couldn't use the identity in tg, so i made my own implementation
I guess I'm not the only one then.
FYI, I'm working on an alternative authorization library for TG based
on PEAK security. It's goal is to provide a much more flexible
authorization system. mainly because one app I worked on badly needed
it, specially to handle user/group object ownership.
It delegates authentication to Paste's middleware (form & cookie) and
provides one layer of middleware to store the policy (loosely based
in peak.web). However, it can easily be adapted to delegate to
tg.identity and avoid all middleware for better 1.0'ness.
Just a suggestion, AFAIK, filters *might* dissappear altogether from
FirstClass in favor of middleware (like the rest of the WSGI
compliant frameworks are doing) so I wouldn't rely to heavily on them.
If interested, the SVN trunk is at http://svn.toscat.net/
TurboPeakSecurity/trunk. I'd gladly help out with any questions you
have about it and appreciate any interest and collaborations.
Alberto
Kevin Dangoor
> Just a suggestion, AFAIK, filters *might* dissappear altogether from
> FirstClass in favor of middleware (like the rest of the WSGI
> compliant frameworks are doing) so I wouldn't rely to heavily on them.
It's also worth noting that we can use middleware today (like we do
with EvalException).
Kevin
Kevin Dangoor
1.0) so that the idea doesn't get lost. I'm sure you're correct that
this can be made more efficient, and identity is in a critical path in
the code.
I do still want to see an identity provider at some point that doesn't
touch the database at all after initial authentication (by storing the
groups in a secure cookie).
Kevin
--
Kevin Dangoor
TurboGears / Zesty News
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
jvanasco
jvanasco
FirstClass in favor of middleware (like the rest of the WSGI
compliant frameworks are doing) so I wouldn't rely to heavily on them.
"""
does that mean that tg is moving away from cherrypy?
Jorge Godoy
>
> does that mean that tg is moving away from cherrypy?
TG is moving towards WSGI. CP will be one of the means to have a WSGI server.
--
Jorge Godoy <jgo...@gmail.com>
Kevin Dangoor
I'd say it's not 100% clear. The direction shown for CP3 looks
promising, but we'll ultimately need to make a decision about which
are the most important bits to us to see whether CP3 is the right way
forward.
WSGI middleware is *definitely* future-proof. CP filters are not 100%
certain. If, for some reason, lots of people suddenly start using CP
filters, we'd certainly take that into account. A few weeks ago I
asked, and they were not the kind of thing that most TG users were
doing.
Kevin
jvanasco
experience. I still develop in it a lot. What I REALLY like about it,
is that I get hooks into the entire Apache server and request cycles.
CherryPy filters are very similar to the apache request cycle (though
the apache request cycle has waaay more hooks).
>From everything I've heard about middleware, it should be possible --
but I've yet to see it in practice.
A lot of what I've been doing with TG is situated on cherrypy
internals. in fact quite a bit of tg itself seems situated on cherrypy
internals.
So for the sake of mye being able to be forward compatible I'll ask
this:
using middleware, how can I do the following:
a- store a per-request variable
b- run code during certain segments of the request
if there's going to be a change away from cherrypy, perhaps there
should be a per-request namespace/object in the next release of tg?
ie, have a tg.current_request wrap cherrypy.request, so that anyone who
is using that bit of cherrypy to manage per-request info will be
compatible
Kevin Dangoor
> a- store a per-request variable
There's a clean mechanism for doing this that's part of Paste, but the
name eludes me at the moment.
> b- run code during certain segments of the request
Middleware can be viewed as "around advice" in AOP terms. That means
it has access to the stuff going in and the stuff coming out but
doesn't really have the ability to do anything more granular than
that. However, that's not to say that there wouldn't be hooks.
So, if you need to be more granular than things going in and things
coming out, your best bet is to stick to CP filters.
> if there's going to be a change away from cherrypy, perhaps there
> should be a per-request namespace/object in the next release of tg?
> ie, have a tg.current_request wrap cherrypy.request, so that anyone who
> is using that bit of cherrypy to manage per-request info will be
> compatible
There's no need, since we live in the land of dynamic languages. IF we
were to not use CP, we would most definitely make cherrypy.request
continue to work (in fact, RhubarbTart already does this, IIRC).
Rather than forcing a transition to a potentially unnecessary
intermediate name, I prefer to leave it at cherrypy.request.
Believe me, backwards compatibility and a reasonable move to future
technology does matter. If filters are the only reasonable way to do
what you need to do, use filters and we'll figure out how migration
works when the time comes. (TG itself uses filters in a couple of
places, so we'd definitely have to consider it!)
Kevin
jvanasco
can you give a read user/pass for your svn?
Kevin-
i modeled my approach after digging through the internals of tg
i wrote a GIANT framework/app in mod_perl - there are about 400
classes spread across 200 database tables and 350 perl modules. i
think it clocks in at 40k lines of code right now. there were a bunch
of different apps that I needed to use which were unstable at the time,
so instead of calling any one CPAN module directly - I elected for the
more tedious/insane task -- i wrapped almost every CPAN module that was
likely to change or could have one or more options, into its own a
custom framework class , and became a huge fan of the approach. i'm
not saying that TG should do that exact thing, but it might make sense
to have a few abstracted classes that do absolutely nothing but provide
a persistant namespace should anything change. ie - create a
turbogears.request namespace that, right now, is just cherrypy.request
-- but should anything ever change, the only migration would occur in
in turbogears.request
some people have a problem with premature optimization , i have a
problem with premature backwards compatibility
Alberto Valverde
> Alberto-
> can you give a read user/pass for your svn?
It' public for read access... I think the url I posted got splited by
svn root and the repository path, the svn root isn't public so this
might be the problem. Trying again with a tinyurl:
http://tinyurl.com/owz9j
Alberto
Matt Good
> On 5/15/06, jvanasco <jvan...@gmail.com> wrote:
> > using middleware, how can I do the following:
> > a- store a per-request variable
>
> There's a clean mechanism for doing this that's part of Paste, but the
> name eludes me at the moment.
paste.registry
http://pythonpaste.org/module-paste.registry.html
Data can also be passed through middleware layers by putting it in the
WSGI "environ" dict. The Paste registry is actually stored this way
with some magic to access objects in it as package globals within the
request's call stack without direct access to the environ.
--
Matt Good <t...@matt-good.net>