repoze.who configuration
Diez B. Roggisch
after getting a first TG2 sample app running with authentication, I found out
how tg.ext.repoze.who hooks the identity-stuff into the app.
I also read the repoze.who docs about AuthenticatorPlugins, and I need to make
my own.
Now the question: how to go about this? In tg.ext.repoze.who.middleware I
don't see any hooks that allow me to create my own AuthenticatorPlugin.
So the question is:
- do I actually de-activate identity as provided in TG2, and fully create my
own middleware wrapping, inside <myapp>.config.middleware? This would of
course mean to have quite a bit of boiler-plate inside
tg.ext.repoze.who.middleware doubled.
- is it planned to add some hooks to have most of the boilerplate reused?
Diez (who loves the WSGI-middleware-concept... coming from J2EE and it's
atrocities called Filters...)
percious
Most of the finagling you will have to do surrounds
RedirectingFormPlugin,
who's source you can find here:
http://repoze.org/viewcvs/repoze.who/trunk/repoze/who/plugins/form.py?rev=944&view=auto
of which you will probably want to modify the "Identify" method. I
created a hook in the template middleware.py so that you can pass your
own in. Simply instantiate your own Form plugin class and assign it
in your app_cfg.py:
of which you will probably want to modify the "Identify" method. I
created a hook in the template middleware.py so that you can pass your
in your own:
base_config.sa_auth.form_plugin = MyNewFangledFormPlugin()
I am thinking about providing hooks for other parts of
make_who_middleware, so let me know if this fancies you.
For ultimate control of the middleware, you are gong to need to copy
the middleware code from make_base_app in tg.middleware and customize
away.
Ok, enough "f" words.
cheers.
-chris
Diez B. Roggisch
> The quick answer is that it depends on how much control you want.
Extremely mucho :)
I should have elaborated a bit more. What I'm after is not a way to
customize the form (for now, I sure need that later), but instead the
way identity & meta-data are looked up. I need to make this based on an
existing XMLRPC-server.
> Most of the finagling you will have to do surrounds
> RedirectingFormPlugin,
> who's source you can find here:
>
> http://repoze.org/viewcvs/repoze.who/trunk/repoze/who/plugins/form.py?rev=944&view=auto
>
> of which you will probably want to modify the "Identify" method. I
> created a hook in the template middleware.py so that you can pass your
> own in. Simply instantiate your own Form plugin class and assign it
> in your app_cfg.py:
>
> of which you will probably want to modify the "Identify" method. I
> created a hook in the template middleware.py so that you can pass your
> in your own:
>
> base_config.sa_auth.form_plugin = MyNewFangledFormPlugin()
>
> I am thinking about providing hooks for other parts of
> make_who_middleware, so let me know if this fancies you.
If my current understanding is correct, I need hooks at least for
Authenticator Plugins
and
Metadata Provider Plugins
and so far these are missing, aren't they? I'm happy to contribute a
patch if you like. If I get TG2 installed from SVN, failed miserably the
last time :)
Diez
Diez B. Roggisch
Where do I actually find these changes? I looked into
http://svn.turbogears.org/projects/tgrepozewho/trunk/tgrepozewho/
but didn't find it.
Diez
Florent Aide
>
>> base_config.sa_auth.form_plugin = MyNewFangledFormPlugin()
>
> Where do I actually find these changes? I looked into
>
> http://svn.turbogears.org/projects/tgrepozewho/trunk/tgrepozewho/
>
Diez,
you'll find the tgrepoze code there:
http://code.google.com/p/tgtools/
But what you search certainly is located in repoze.who:
http://svn.repoze.org/repoze.who/trunk/
Regards,
Florent.
Diez B. Roggisch
> On Wed, Jul 9, 2008 at 12:00 PM, Diez B. Roggisch <de...@web.de> wrote:
> >> base_config.sa_auth.form_plugin = MyNewFangledFormPlugin()
> >
> > Where do I actually find these changes? I looked into
> >
> > http://svn.turbogears.org/projects/tgrepozewho/trunk/tgrepozewho/
>
> Diez,
>
> you'll find the tgrepoze code there:
>
> http://code.google.com/p/tgtools/
So is the above repository wrong? Shouldn't it be deleted then - it's
misleading. Or will it be updated in time?
> But what you search certainly is located in repoze.who:
>
> http://svn.repoze.org/repoze.who/trunk/
Nope, it actually was inside the above repository :
However, it's not exactly what I'd thought - having to pass the form-handler
as explicit variable is a bit strange. I can do that of course, but then I
totally have to bypass the code in tg.middleware. Which essentially means I
could as well just create my own wsgi-wrapping.
But there is a pylons.config object passed. I'm a bloody noob regarding
pylons - but why is it that the config parameters are explicitly passed
inside tg.middleware? Wouldn't it make more sense to pass a config and let
the extension decide which variables it actually cares about?
Diez
Florent Aide
>
> On Wednesday 09 July 2008 12:09:23 Florent Aide wrote:
>
> So is the above repository wrong? Shouldn't it be deleted then - it's
> misleading. Or will it be updated in time?
it has been moved and should be removed totally from turbogears projects svn.
> Nope, it actually was inside the above repository :
>
> http://code.google.com/p/tgtools/source/browse/projects/tg.ext.repoze.who/trunk/tg/ext/repoze/who/middleware.py?r=41#63
Ha! I though you wanted to form implementation. :)
> But there is a pylons.config object passed. I'm a bloody noob regarding
> pylons - but why is it that the config parameters are explicitly passed
> inside tg.middleware? Wouldn't it make more sense to pass a config and let
> the extension decide which variables it actually cares about?
This is perfectly right. There is some coupling in that code that
should be removed by inspecting the app config and then we should be
able to stuff our options in the .ini file under our own identity
section. This is part of the work we need to do to have some really
useable code for tg.ext.repoze.who
Cheers,
Florent.
chrism
wrong idea: it's better to write and use a new repoze.who plugin for
some specific purpose than it is to attempt to write the "one set of
plugins to rule them all". As a result, I'd guide folks towards
ditching any given existing plugin and implementing one that does
exactly what they need when their needs aren't serviced by the plugins
implemented in e.g. tg.ext.repoze.who.
Independently, there is also a declarative way to configure repoze.who
via a config file, as opposed to making folks configure who "by hand"
in Python code. It probably makes sense for TG2 to use this to do
repoze.who configuration. See "Middleware Configuration via Config
File" in http://repoze.org/viewcvs/repoze.who/trunk/README.txt?rev=1059&view=markup
.
Florent Aide
> via a config file, as opposed to making folks configure who "by hand"
> in Python code. It probably makes sense for TG2 to use this to do
> repoze.who configuration. See "Middleware Configuration via Config
> File" in http://repoze.org/viewcvs/repoze.who/trunk/README.txt?rev=1059&view=markup
that is the purpose. I think that once we use this configuration
method Diez will be able to specify his own form easily from config
file. And propose a sane default to be included in tg2's upcoming
release. ;)
Florent.
Diez B. Roggisch
By now, I'm also beginning to think that this would be better. I think TG2
customization should be more along the lines of e.g. login_handler_urls and
such.
Thanks for all the clarifications!
Next stop: prefixing a TG-application with a given path & fix serving static
content in that case :)
Diez
percious
http://svn.turbogears.org/projects/tg.devtools/trunk/devtools/templates/turbogears/+package+/config/app_cfg.py_tmpl
I can add the hooks for the elements you desire. Can you open a
ticket trac for this?
-chris
Diez B. Roggisch
> They can be found here:
> http://svn.turbogears.org/projects/tg.devtools/trunk/devtools/templates/tur
>bogears/+package+/config/app_cfg.py_tmpl
>
> I can add the hooks for the elements you desire. Can you open a
> ticket trac for this?
>
http://trac.turbogears.org/ticket/1897
Diez
Bryan Koroleski
infinitely easier than for the old Identity/Visit system, but that's
just my opinion. Anyway I just thought I would give you some examples
to run on, Diez, since I had to do exactly the same thing last week :)
My code is incredibly alpha right now, but here's a copy of my
middleware.py, which has the custom plugins defined inside.
http://paste.turbogears.org/paste/3287
These plugins work with a library I've written to interact with a
goofy authentication system written in PHP. It's a little hard to
follow, but all the base library does is pull XML resources based on a
few different keys that are set in the configuration. If you have any
questions about how my plugins actually work, I'd be more than happy
to answer them to the best of my ability.
To deactivate the SQLAlchemy identity stuff, all you have to do is
change base_config.auth_backend to something else, personally I set
this to correspond to my plugins for our auth system. From there you
can create a new variable in base_config and set it equal to a new
Bunch.
Honestly I want to thank the TurboGears and repoze.who guys for
building and integrating this awesome authorization and authentication
system into the framework. So, thanks guys :)
mark.mch...@gmail.com
think it do a better job of providing the hooks you need. And where
it doesn't it should be easy enough to overide the methods on the
config object that setup authorization stuff.
On Jul 10, 5:38 am, "Diez B. Roggisch" <de...@web.de> wrote:
> On Wednesday 09 July 2008 17:06:56 percious wrote:
>
> > They can be found here:
Diez B. Roggisch
> Diez, could you take a look at what's in TG2's config object now. I
> think it do a better job of providing the hooks you need. And where
> it doesn't it should be easy enough to overide the methods on the
> config object that setup authorization stuff.
Will do - but it would be cool if you could simply assign me the ticket.
Then I get notified of you wanting me to check something :) Reading this
mail wasn't exactly pure luck - but due to the thread being a couple of
weeks old, it was close to flying below my radar.
Diez
mark.mch...@gmail.com
guess I need to better understand what we want to make more
configurable.
I 4 our of 5 webapps to require nothing more than changing some config
variables, but I think that it's not unreasonable for some folks with
more complex needs to subclass AppConfig.
If someone can provide a quick list of things that ought to be super-
easily configurable, we can try to make this happen before the next
(and hopefully last) 1.9.7 alpha.
--Mark Ramm
On Jul 22, 2:15 pm, "Diez B. Roggisch" <de...@web.de> wrote:
> mark.mchristen...@gmail.com schrieb: