authentication doesn't update request with the actual user

[GoogleCodeExporter]

The request is never updated with the actual user information.  It is
important for WS requests to have the fine-grained Django permissions
available.

The current definition of the "authfunc" (for Basic) returns a simple
boolean result or (for Digest) returns a simple md5 password digest.

Currently, the authfunc is the place to which the
django.contrib.auth.models.User queries are isolated.  Clearly, this
responsibility assignment is important to preserve.

The authfunc interface could be expanded to be a callable object.  The
__call__ interface is the existing API:  it returns a simple Boolean (for
Basic) or String (for Digest).  This provides some backward compatibility.  

This object could, however, have three standard methods:
- basic( self, username, password ) returns boolean
- digest( self, username, realm ) return string
- updateReq( self, request ) updates the request with the
django.contrib.auth.models.User which was authenticated by basic or digest.

The various Authentication classes can simply call the object as they do
today, with few changes.

However, subclasses (or newer versions) can call the additional "updateReq"
method to update the request with the user information.  This subclass then
make additional tests in create, update and delete.  Something like the
following...

    permission_name= '%s.add_%s' % ( self.queryset.model._meta.app_label,
self.queryset.model.__name__.lower(), )
    if request.user.has_perm( permission_name ):
        return super( ThisClass, self ).create( request )
    else:
        raise Http404

Original issue reported on code.google.com by slot...@gmail.com on 14 Aug 2008 at 11:46

[GoogleCodeExporter]

Thank you for your report.

So i am trying to understand your use case here. What exactly were you trying 
to do?

I agree about the permissions issue. I believe that this app was written before
Django had permissions.(if i'm not mistaken) 

Original comment by alaasal...@gmail.com on 17 Aug 2008 at 12:20

[GoogleCodeExporter]

I need more than "authenticated == True". I need the actual User object so I 
can check fine - grained 
authorization for the User. This includes permissions and group membership. 
Additionally, I need to log the 
user making the REST requests. 

Original comment by slot...@gmail.com on 18 Aug 2008 at 4:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here's a potential patch for the authentication module.  This will update the 
request
with the user identification.  A subclass of Collection can use this 
information for
detailed permission checking and logging.

This appears to be completely backward compatible.  

I'm working on a more-or-less general solution to the authorization checks.

Original comment by slot...@gmail.com on 18 Aug 2008 at 12:09

Attachments:

• auth_patch.txt

[GoogleCodeExporter]

Here are today's lesson learned:

1.  Adding a user to the request is "logging them in".  I re-read the 
authentication
documentation.

2.  "To log a user in, in a view, use login(). It takes an HttpRequest object 
and a
User object. login() saves the user's ID in the session, using Django's session
framework, so, as mentioned above, you'll need to make sure to have the session
middleware installed."

3.  "When you're manually logging a user in, you must call authenticate() 
before you
call login(). authenticate() sets an attribute on the User noting which
authentication backend successfully authenticated that user (see the backends
documentation for details), and this information is needed later during the 
login
process."

And -- for digest authentication -- this is essentially impossible.  We don't 
have
the actual password required by Django's authenticate() function.

That scrubs my idea of updating the request.  What's left is using the 
authentication
"function" as a callable object that retains the current User for the REST 
request.

Original comment by slot...@gmail.com on 19 Aug 2008 at 1:38

[GoogleCodeExporter]

I would like to get the user in the request object as well, and can't really
understand why your patch wouldn't work, even if it does not relies on  the
authentication framework its result is still much closer to the expected 
outcome then
calling the auth object from the view functions directly.

Original comment by viktor.nagy@gmail.com on 9 Nov 2008 at 10:01

[GoogleCodeExporter]

Should we not use this patch?  The patch as-is is a little buggy (indentation 
error),
though it works as advertised, and I've yet to find another solution.

Thanks!

Original comment by nickserg...@gmail.com on 16 Dec 2008 at 4:47