Gustavo,
to begin this: I appreciate the non-ad-hominem response. I do not
agree with what you said and imply what I said, which you can read
below. But I hereby publically excuse myself for ramping up the tone
to a personal level. I shouldn't have done that.
And I hope this post - while certainly taking a stance towards things
you said - does not inflame the discussion further, but makes clear
what I perceived and what drove me.
Am 10.06.2010 um 00:18 schrieb Gustavo Narea:
Diez said:
You are exactly right Gustavo - the arrogant and attitude is
exactly the
problem here.
But obviously I see it the other way round. If I read something
like this
from you
"""
The point I'm trying to make is that this kind of things can
perfectly be
done with repoze.who, without bringing any hack to the authorization
controls like that @xrequire decorator or the other things you
suggested.
"""
when clearly you
- don't understand the problem
- disqualify proposed solutions as "hack"
- ignorantly insist that things are "that simple", when obviously
they
aren't, and this repeatedly so (I lined out the problem with the
subsequent calls not being authenticated several times..)
then that's an arrogant & ignorant attitude in my book. Which was the
reason why I changed my tone.
Don't you realize that you're actually describing yourself?
- You didn't understand the problem, based on the incorrect
statements you
made about repoze.who which I pointed out in other emails, and the
same for
XML-RPC, when you said that the credentials must be in the body
because
"XMLRPC works over HTTP, but it does NOT work with the whole browser-
semantics
of cookies and headers"... While it can perfectly use HTTP
authentication.
I never said they must be in the body. I said they can be in the body,
in the URL, or in headers. Regarding the latter, the XMLRPC standard
does not make any assumptions about headers except content type &
content length.
""
Header requirements
The format of the URI in the first line of the header is not
specified. For example, it could be empty, a single slash, if the
server is only handling XML-RPC calls. However, if the server is
handling a mix of incoming HTTP requests, we allow the URI to help
route the request to the code that handles XML-RPC requests. (In the
example, the URI is /RPC2, telling the server to route the request to
the "RPC2" responder.)
A User-Agent and Host must be specified.
The Content-Type is text/xml.
The Content-Length must be specified and must be correct.
"""
(http://www.xmlrpc.com/spec)
I grant you that it is common that XMLRPC implementations allow for
basic auth to be transmitted. I didn't know that. Now please, be so
honest and admit: YOU didn't know that either, otherwise this whole
discussion wouldn't have taken place. Because then you would have
mentioned it earlier, instead of producing code snippets that clearly
do not rely on basic auth.
And basic auth isn't excactly the most secure authentication-kid on
the block, so relying on it and saying everything is just golden isn't
exactly the truth either. A proper, XMLRPC-call-based authentication
with challenge/responses would be better - but then, one is back on
square one. I don't claim this was in my mind the whole time. But it's
nonetheless a fact.
- You disqualified my suggestion as something that wouldn't even
work, while
at least I acknowledged that your solutions would work ("His
suggestions don't
solve anything so far").
Which they didn't. They weren't basic auth, they relied on reading the
body either not xmlrpc-aware, or failed to provide means for
authenticating subsequent calls. So I stand by my statement: your
suggestions up to that point didn't solve the problem. And I really
mean your concrete suggestions in form of code snippets to illustrate
an idea, and not a general notion of repoze.wh* not being fit for the
job at all that I never uttered.
- You ignorantly said that there are three solutions and none of
them was
good ("So there are basically three ways of doing this, each of them
means
you got to die one particular death").
I didn't ignorantly say that. I said what is technically the pure &
simple truth regarding XMLRPC. I wasn't aware that Python's xmlrpclib
supported basic auth (which, btw, isn't even mentioned in the docs),
and thus assumed you'd have to write non-standard-lib code to support
setting headers. Which, incidentially, the OP did. And at that point
in time, it wasn't clear if he only used python, and thus I wrote
under the assumption of the simple, pure XMLRPC-standard. So that's
one death. The other two neither of us disputes.
And for the record, I mentioned that URL and header based auth were
perfectly fine suited for repzoz.wh*.
And what the heck are you talking about "arrogant attitude since
the very
first response"? How can you read this into that post totally
escapes me.
I laid out he various options, including ways how to actually use
repoze.who.
"I'm sorry, but this won't work. The fault here is certainly not on
repoze.wh* side, but what you presented so far is just working to
authenticate the login call itself. But obviously the OP wants a bunch
of authenticated (and possibly authorized) API-calls, not just one."
First of all, I fail to see how saying that "the fault here is
certainly not on repoze.wh*" qualifies as "arrogant/trolly", from that
very first repsonse.
Then the statement was in context of your post, which showed this:
"""
def identify(self, environ):
request = Request(environ)
if "login" in request.POST and "password" in request.POST:
credentials = {
'login': request.POST['login'],
'password': request.POST['password'],
}
else:
credentials = None
"""
Are you trying to tell me that this works even for the request going
on? No. It doesn't. Is this basic auth? No, it isn't.
And that was what I was clearly referring to when I said "presented so
far".
Again, I did *not* imply that repozew.wh* isn't capable of dealing
with the problem at all. I merely said that so far, no working
solution was presented.
Which IMHO is more complicated (and impacted by performance issues)
than
it's worth it, but I clearly stated that as an opinion, not as
advice to
fore go repoze.wh*. Which by now, I'm obviously willing to do.
That option is more complicated because you wanted it to be more
complicated.
The credentials don't necessarily have to go in the XML-based body.
Which I never implied. I said *if* one wants to use XMLRPC calls
themselves as authentication method, *then* one has to resort to parse
the body twice given the current design of repoze.who.
Again, I listed all three options from the very start. Pointing out
that one of them is problematic makes me "wanting it to be more
complicated"?
Which in turn I think is the real problem here: whenever one merely
suggests that repoze.wh* is anything since the greatest thing since
sliced bread, you get defensive. Instead of trying to see criticism
as
means to enhance it.
I love criticism, but in this case I think you failed to present a
valid
issue. There's no reason why repoze.who wouldn't be able to deal
with this.
I'm personally not 100% satisfied with repoze.what 1. I am aware of
limitations in these packages, and so are the other people involved.
That's
why repoze.who 2 and repoze.what 2 are being developed actively at
present.
If there's something that you don't like, now is a perfect time to
let us know
and possibly join us. Who knows, maybe the goals you have for that
auth
library you're working on are compatible with our goals for these new
packages.
Well, I appreciate the offer. Really. If you care, you can look at my
current implementation here:
http://bitbucket.org/deets/tgextsimpleauthorization
The few key points it does differently which IMHO you should consider
in your design are these:
- it does allow for predicates to be evaluated with an implicit
environ. Because it has a middleware that knows it's environ. So even
serveral nested apps safely can work, because each of them is shielded
by it's own auth-middleware, and thus knows about it's own auth-
context, not some global one (global in the sense of the environ, not
variables obviously).
- it allows application controller code to call it to log in or out
a given user. Something for example the current OP would have wished
for. And this I think is a huge advantage because people write
controllers all the time, where on the other hand writing repoze.who
plugins you do only every now and then, and thus getting it right is
harder. Harder, not impossible!
Think of e.g. the simple, but very desirable feature of passing
additional parameters to the login page to make it redirect to a
specific page after success. Being able to use standard TG/
ToscaWidgets code & validation for this instead of having to write a
bare-bone WSGI implementation.
Yes, I'm aware of friendlyform-plugin. But while it's good that it is
available, it might not fit all needs, and customization is harder
than to simply adapt the login-controller in your own application.
And the current discussion is an example as well, providing a user/
password based authentication for XMLRPC at controller level would be
much easier & not require double-body-parsing if one could modify the
current request's identity information easily from within the
application.
I could bring more examples, but I guess the point is clear.
- it provides convenience methods for dealing with redirects, both
internally ond externally. This again makes writing code much easier.
Consider your own example that wanted to return a token on successful
login. To do so, one has to go down a rather arcane road of passing an
WSGI-application to the middleware through an environ key, and then of
course use WSGI-standard to render a response. OTOH my framework in
that situation allows you for e.g. an internal redirect that renders
the result in whatever framework you are in.
- it uses operators "&" and "|" and "-" to create compound
predicates which work both in templates (being evaluated directly), or
in declarative situations like controller actions, so it overcomes the
limitations of "and" and "or" and "not" only being suitable for
templates, but not for controllers.
- it has rich exception based predicate evaluation + easy text-based
configuration for those, so you can e.g. make different predicates
raise different authorization errors, and the middleware will redirect
appropriately - even with GET-parameter-passing support, so e.g. the
MissingGroupError will not only redirect to a page, but also tell you
easily *which* group you don't belong to.
Regarding the working together on this: I don't see that. The reason
are previous discussions we had about feature wishes, that prodded me
into writing tgext.simplauth in the first place. We seem to have very
different opinions about what is good design and what is hackish...
and fighting these out all the time I fear isn't fruitful.
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.
