Hello, Diez.
Diez said:
> 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.
I didn't, either.
> 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.
I consider basic authentication, digest authentication, sending the
credentials in the XML-RPC body, etc, equally insecure because if you
intercept the connection you got the credentials. I'd just pick the easiest
method and make it work under HTTPS.
> > - 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.
The two suggestions I made initially (before HTTP authentication) would work:
1st suggestion: Sending the credentials in request arguments
------------------------------------------------------------
I suggested that because years ago I wrote a XML-RPC server which expected the
credentials to be in the query string, so it's the first thing that came to
mind.
There I (repeatedly) used "POST" by mistake, which is certainly impossible. If
you replace "POST" with "GET" in that code, that would be what I meant to
show.
Authentication would have to be done on every request but that's absolutely
fine. In fact, that's exactly how both basic and digest authentication work.
If you ask me these days, I wouldn't take that approach again because it's not
exactly the most elegant one. I personally find it better than including the
credentials in the call, though... I don't think they fit there: it's
generally meant for the authentication layer of the system, not the XML-RPC
server per se.
2nd suggestion: Sending the credentials in the XML-RPC request body
-------------------------------------------------------------------
This one is based on your third suggestion.
Although it is not mandatory to authenticate in the first request and identify
in subsequent requests, this method offered that functionality.
It also involves sending the credentials in the call, which means it'd need to
be parsed twice in the first request. But this is the only disadvantage,
AFAIK.
> >> 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.
Your 3rd suggestion is about sending the credentials in the call, which is the
only one of your suggestions that I explicitly commented on.
> 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).
That sounds good to me, and I suspect it wouldn't be that hard to do.
I'll give it some thought on how to make that work optionally without making
the library itself depend on thread locals, but yes, I think it's a good idea
for the next release.
> - 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.
That sounds like an excellent idea. It's a known limitation in repoze.who 1,
which fortunately is addressed in v2.
> 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.
Agreed.
> 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.
Also a good point.
> 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.
I assume that would be accomplished by making reusing the WSGI application
object passed to your middleware, and calling it with a copy of the environ
with some items changed (e.g., PATH_INFO).
If this correct, the problem I see is that the WSGI middleware defined before
yours wouldn't participate in the internal redirects, which may or may not
make a difference.
> - 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.
That's one of the first things I checked in the development branch. :) They're
really handy. I'll backport them to v1 eventually.
> - 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.
That sounds like a very different approach to predicates. Maybe I'd change my
mind if I see some code examples, but I think I prefer the current approach.
> 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.
You may be right, and also now may be too early to talk about that. I'd say we
both have clear ideas on what to do, but our implementations are work in
progress at the moment.
I'd love to have this discussion at some point later. Even if we decide not to
work together, we could always borrow ideas from each other.
Cheers.
--
Gustavo Narea <xri://=Gustavo>.
| Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about |
--
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.
