Re: [Repoze-dev] repoze.what - minor fix
> In TG2, you can add something like the following to
> "{yourproject}.config.app_cfg":
>
> app_cfg.sa_auth.mdproviders = [('foo', FooPlugin()), ('bar', BarPlugin())]
>
> See:
> http://turbogears.org/2.0/docs/main/Auth/Customization.html
Oh right, yes; I did in fact do that... I should just shut up about
mdproviders permanently ;) Thanks for making it clear though, I was
having a little trouble learning everything AND figuring out how to
apply the documentation in some cases.
> In that function, the plugins are grouped by type in a dictionary
> whose keys are the interfaces (i.e., classes) and the items are the
> plugins themselves *in the same order they were defined*.
You are correct, thanks for the clarification. I had to go back and
study closely; I had misinterpreted this line's behavior:
> L = interface_registry.setdefault(iface, [])
I don't remember the ordering details anymore, but I can figure it out
from here. I do think that the suggested change would be a good one,
so I'll leave that to you to consider - but I believe I can manipulate
the registry exclusively from my own code with this new understanding,
so I'm glad I'll be able to make it work whether or not repoze.who
gets updated...
Thanks for your time and patience.
Kris
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.what - minor fix
Hello, Kris.
On Thu, Jan 5, 2012 at 2:57 PM, Kris Reeves wrote:
> 3) You keep addressing my mistakes but not my points.
>
> 3a) I cannot provide any metadata providers to setup_sql_auth() with
> the default base TurboGears quickstart project, assuming it should
> only be called once. If it's okay to call it twice, or there's some
> way to inject my provider into the load environment, I'd love to know.
In TG2, you can add something like the following to
"{yourproject}.config.app_cfg":
app_cfg.sa_auth.mdproviders = [('foo', FooPlugin()), ('bar', BarPlugin())]
See:
http://turbogears.org/2.0/docs/main/Auth/Customization.html
> 3b) As shown in the source I linked last message, the groups and
> permissions environment variables do get overwritten, which I see as a
> problem whether or not any of the rest of this is true.
I think I now understand what you mean: repoze.what-quickstart puts
the repoze.what metadata plugin for repoze.who as the very last plugin
to be executed.
I think it'll be safe to put that plugin as the first one, which will
solve your problem. I can't see this change being backwards
incompatible, but it's probably better not to trust myself at midnight
so I'll change it over the weekend. I'll let you know when it's
changed.
> 3c) The providers are indeed stored in a dictionary, as linked in (2),
> so ordering cannot be relied on. (If {} is *not* a blank dictionary,
> then please tell me so I can facepalm!)
In that function, the plugins are grouped by type in a dictionary
whose keys are the interfaces (i.e., classes) and the items are the
plugins themselves *in the same order they were defined*.
Cheers,
--
Gustavo Narea.
Aspiring Software Craftsman.
http://gustavonarea.net/
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.what - minor fix
Ugh. I still didn't nail it down. I think the reason I was so hung up
on mdproviders is because that was my "way in" - but it apparently has
almost nothing to do with the problem, so please pretend I didn't
mention it :)
A few things:
1) repoze.who used by TurboGears is 1.0 not 2.0
2) The dictionary is actually the interface registry where the
contents of mdproviders get stored later:
https://github.com/repoze/repoze.who/blob/1.0.19/repoze/who/middleware.py#L434
3) You keep addressing my mistakes but not my points.
3a) I cannot provide any metadata providers to setup_sql_auth() with
the default base TurboGears quickstart project, assuming it should
only be called once. If it's okay to call it twice, or there's some
way to inject my provider into the load environment, I'd love to know.
3b) As shown in the source I linked last message, the groups and
permissions environment variables do get overwritten, which I see as a
problem whether or not any of the rest of this is true.
3c) The providers are indeed stored in a dictionary, as linked in (2),
so ordering cannot be relied on. (If {} is *not* a blank dictionary,
then please tell me so I can facepalm!)
4) The change suggested is small and sensible, as far as I can
determine. The only thing that changes is that two assignment
statements become update statements instead of direct assignments. I
can understand a desire not to change things when it's unnecessary,
particularly at the request of a Python newbie, but I would appreciate
it if you could make the distinction for me between "I(?) don't intend
to implement it" and "I'm just trying to help a newbie" so that I
don't spend my time arguing a useless case...
I understand that TG is not your purview, however it is a useful tool
that exists, and this small change would make the difference between
"I can write this to work with the default setup with only a few lines
of code" and "I have to rewrite all this stuff that was provided for
me from the ground up without understanding it completely" - I
obviously chose the former, but I'd like to do it nicely instead of
messily. If you have a clean solution that can avoid making the change
I suggest, I'd love to hear it; on the other hand, if there's a reason
that it shouldn't be changed, I would like to know that too - because
currently that is what I have done. I was mailing the dev list to
hopefully get the change added to the package so I wouldn't have to
either modify the package or monkey patch it.
Kris
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.what - minor fix
Hello, Kris.
On Thu, Jan 5, 2012 at 1:42 AM, Kris Reeves wrote:
> Anyway, it's a moot point because repoze.what overrides the groups and
> permissions dictionaries in the environment, and since mdproviders is
> a dictionary there is no real guarantee of the order the mdproviders
> are run in. If my mdprovider runs first, it adds to the environment
> and then repoze.what writes over my data. If my mdprovider runs last,
> there's no issue. I considered exploiting hashes to make this happen
> but in the end decided I wanted a clean solution ;)
mdproviders isn't a dictionary. It's a sequence of 2-item tuples like:
[("foo", FooPlugin()), ("bar", BarPlugin()), ("baz", BazPlugin())]
If you add a metadata provider plugin to setup_sql_auth(), it'll be
run after repoze.what's, which should solve your problem.
> I apologize for misspeaking last message, it had been a while and I
> needed to refamiliarize myself with the situation. Also it appears
> that I have addressed the subject incorrectly :)
That's OK! =)
Hope you'll get it to work now,
--
Gustavo Narea.
Aspiring Software Craftsman.
http://gustavonarea.net/
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.what - minor fix
Thanks for the reply, hope you had a good trip! I went back to read my post in light of this information and I can see why you are confused! I had to get out my notes to remember exactly what the deal is. You are correct, repoze.what-quickstart does not override mdproviders. What happens is this: https://github.com/repoze/repoze.what/blob/master/repoze/what/middleware.py#L99 https://github.com/repoze/repoze.what/blob/master/repoze/what/middleware.py#L105 Those two lines assign a value directly to the repoze.what.credentials dictionary, even if it already exists. If it doesn't exist they create a blank dictionary, but if it does it assigns directly instead of using, say, update. After all the source diving I did I am amazed that I managed to, at the last minute, mix up two different packages! I apologize for this error. As for setup_sql_auth, I'll have to look at it again. It gets defined in a chain of calls that are out of my direct control (unless I want to edit libraries!), but I'm not sure when it actually gets executed - my Python knowledge is a little thin still here. It looked like a function I didn't want to call twice, and after tracing all the calls backwards I found no simple way to insert an mdprovider into load_environment such that it would be included in this chain of calls. Anyway, it's a moot point because repoze.what overrides the groups and permissions dictionaries in the environment, and since mdproviders is a dictionary there is no real guarantee of the order the mdproviders are run in. If my mdprovider runs first, it adds to the environment and then repoze.what writes over my data. If my mdprovider runs last, there's no issue. I considered exploiting hashes to make this happen but in the end decided I wanted a clean solution ;) I apologize for misspeaking last message, it had been a while and I needed to refamiliarize myself with the situation. Also it appears that I have addressed the subject incorrectly :) Kris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
