On Fri, Mar 13, 2009 at 9:48 PM, Malcolm Tredinnick
<[email protected]> wrote:
> I'd go for something shorter:
>
> Performs any cleaning on the "username" prior to using it to
> create the user object. Returns the cleaned username.
>
> By default, returns the username unchanged.
>
> I've also added when the method is called, since that adds some context
> to the purpose of the method (it's post-input, pre-ORM handling). I'm
Changed docstring, using your example.
> ambivalent about whether the LDAP example goes there or in the docs, but
> I'd favour something shorter.
I've moved these mentions to the docs.
> 2. Regarding the middleware: How does this interact with WSGI-based
> systems? Can remote user data be passed in the environment via some
> standard wsgi.* variables, rather than a particular HTTP header there?
> It would be good to be able to reuse the same middleware (or make it
> minimally subclassable) for that case, rather than unnecessarily burning
> bridges.
>
> Not suggesting you necessarily implement WSGI authentication support,
> but it would be good to know if there's anything relevant we need to be
> aware of in the design. Mostly I was looking at the reliance on a
> particular HTTP header and wondering if that was the only way we might
> enter that path.
I'm pretty sure the middleware as it stands now would easily be able
to support WSGI authentication. The mod_python handler is actually
populating META['REMOTE_USER'] from the mod_python request object's
user attribute. The wsgi handler sets META to the the environ dict it
is passed:
class WSGIRequest(http.HttpRequest):
def __init__(self, environ):
...
self.META = environ
So if REMOTE_USER is in the environ dict then the RemoteUserMiddleware
will work unchanged. If the authenticated user is passed as some
other environment variable name, then one would just need to subclass
RemoteUserMiddleware and set the header attribute to whatever key to
lookup in META.
> 3. Not sure about howto/ vs. topics/ for the new document, in reference
> to Jacob's comment, since it's mixing both instructional / tutorial form
> with reference manual. Your call. Not worth sweating too much, since we
> need to spend some time editing in some separation there in general and
> the current stuff you've got looks very clear (I understood it).
Looking, at what's currently in each I can see how this might be a
better fit for howto. I'll move it, Jacob.
> Good stuff.
Many thanks are in order to those who worked on the patch before I touched it.
Gary
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" 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/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
