Re: [GSoC 2012] Enhanced contrib.auth

[Stratos Moros]

On Wed, 04 Apr 2012 19:25:26 +0300, Adrian Holovaty   
wrote:



Hi Stratos,

The core team is going to take the lead on the auth.User refactoring
-- specifically, yours truly. :-)

Given that the Summer of Code policy prohibits code contributions from
non-students (right?), I don't think the User refactoring would work
as a Summer of Code project. Sorry to break this news, as you've
clearly done a lot of preparation and thinking about the issue, but of
course we'd love to have you contribute to this particular feature
*outside* the Summer of Code.

Adrian



Ok. I'd love to contribute either way.

Thanks for the info.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: [GSoC 2012] Enhanced contrib.auth

[Adrian Holovaty]

On Wed, Apr 4, 2012 at 10:16 AM, Stratos Moros  wrote:
> I'm apologizing for replying to my own post, but there are only two days
> left before GSoC's submission deadline and my proposal has received very
> little feedback.
>
> Since other proposals about contrib.auth are being discussed, I was
> wondering if mine has any merit and whether I should submit it through
> google-melange.

Hi Stratos,

The core team is going to take the lead on the auth.User refactoring
-- specifically, yours truly. :-)

Given that the Summer of Code policy prohibits code contributions from
non-students (right?), I don't think the User refactoring would work
as a Summer of Code project. Sorry to break this news, as you've
clearly done a lot of preparation and thinking about the issue, but of
course we'd love to have you contribute to this particular feature
*outside* the Summer of Code.

Adrian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: [GSoC 2012] Enhanced contrib.auth

[Stratos Moros]

On Fri, 30 Mar 2012 17:35:16 +0300, Tom Evans   
wrote:


On Fri, Mar 30, 2012 at 10:39 AM, Stratos Moros   
wrote:

You can read the proposal nicely formatted here:
https://gist.github.com/8dd9fb27127b44d4e789


Hi Stratos

It's a long proposal, so this is a brain dump of bits that I find
interesting/worrisome.


Hi Tom.

I'm answering your 3 questions together because they are related to each  
other.


In my proposal, a user model represents an authentication/authorization  
scheme. This is why you have to mixin the authentication scheme directly  
in the model. All other information, such as first_name, last_name etc.  
should live in the user's profile.


The idea isn't to remove custom profiles, but to let developers control  
where they're used. The example I provided about adding custom profiles  
was rather bad. The way I expect most developers to add a fields to a user  
is:


class CustomUser(SomeMixins):
profile = models.ForeignKey(UserPorfile)

This way you can allow your frontend users to log in with, say, either  
with username & password or openid and have a single profile between them,  
while allowing your backend users to login with credentials from an LDAP  
server and have a different profile for them.


This is why authentication backends are deprecated. If you can't specify  
which authentication mechanism is used for each user model, you can't  
easily accomplish the above scenario. You would have to have a single  
table to represent the two different profiles and you would somehow make  
sure that a user trying to log in with facebook doesn't go through the  
LDAP server.


This is also why the identity in the user model is a method and not a  
field. If you want a single user to be authenticated in multiple ways, you  
can override the identity method and return the same value.


Perhaps the profile field should be made part of the user contract, but  
this would be an annoyance in cases where you don't want to store any  
additional information about the users, but use them only for  
authorization purposes (ie. I don't care about his info, I just want to  
know if he can access this page).


Having login and logout be part of the user model was one of the things  
that I wasn't sure about. The reason I put them in the user model is to  
decouple the whole process from the session. This way an authentication  
scheme that doesn't want to use the session to store a logged in user can  
do so. The common case would obviously be to store them in the session, so  
I included the SessionAuthenticationMixin.


The same goes for authorization. Inheriting from a mixin implementing the  
authorization contract would probably add a foreign key to the table  
storing the permissions plus a few methods to query it. This way you can  
handle different user models' permissions in completely different ways.


Thanks for the feedback. I hope I've answered your questions.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: [GSoC 2012] Enhanced contrib.auth

[Tom Evans]

On Fri, Mar 30, 2012 at 10:39 AM, Stratos Moros  wrote:
> You can read the proposal nicely formatted here:
> https://gist.github.com/8dd9fb27127b44d4e789

Hi Stratos

It's a long proposal, so this is a brain dump of bits that I find
interesting/worrisome.

I'm sure you've followed the recent threads on the topic. The (wildly)
different solutions garnered from those long threads are all listed on
this wiki page:

  https://code.djangoproject.com/wiki/ContribAuthImprovements

I don't think this proposal ties in with any of them? Your proposal
involves multiple user models, whilst none of them do.

Login:

Where have auth backends gone in your plan? Why do user objects have a
login method, login should be distinct from user objects, otherwise
login is coupled to a user object, and you cannot log in to the same
user using different authentication techniques.

It is common these days to provide multiple ways of authenticating to
your users, if I authenticate by smartcard, user/password, Facebook
auth, SAML federation, or a "remember me" signed auth cookie, I should
still get the same user object. The choice of authentication is
irrelevant.

More to the point, it should be *my* choice. Forcing authentication
into the user model removes that choice, or requires us to have N user
models per user, one per auth method.


Authentication mixins:

This goes to the above point; if I have to mixin an authentication
class to my user object (adding the required login() + others
methods), it means I can only have one authentication mechanism for a
particular user model.


Deprecating user profiles:

The purpose of user profiles is to provide a place for a pluggable app
to store its own information about a user. Adding a pluggable app
should not mean having to add fields to your user model, but with no
user profiles, that's what is suggested.

Once you have a significant number of pluggable apps, you could have a
User model with a crazy number of fields - I can envisage scenarios
where you have over 100 fields. This makes doing anything with the
user model slower. Furthermore, storage for each field is now required
for every user, whilst with a pluggable profile, it would only exist
if the user utilizes that app.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

[GSoC 2012] Enhanced contrib.auth

[Stratos Moros]

You can read the proposal nicely formatted here:  
https://gist.github.com/8dd9fb27127b44d4e789


GSoC 2012 Proposal - enhanced contirb.auth
==

Hello, my name is Stratos Moros and I am a Computer Science student in the  
University of Piraeus in Greece.


I would like to participate in Google Summer of Code with Django, working  
on an enhanced contrib.auth.


Goals
-

-   Long term solution

	The proposed replacement doesn't aim at just improving some of the  
current limitations of contrib.auth (e.g. increasing the email field  
size), but at providing a long term solution.


-   Backwards compatibility

	The new contrib.auth will be 100% backwards compatible with the current  
implementation. Developers updating their existing Django installation  
will have the same features available, without having to update their code  
or undergo a database migration.


-   Separation of concerns

	The concepts of identity, authentication and authorization should not be  
tightly coupled by default. Developers will be able to mix and match  
schemes if they want, or use a more integrated approach otherwise.


-   Extensibility

	It's impossible to cover all existing and future authentication /  
authorization schemes. Developers who have needs that aren't covered by  
Django should be able to extend contrib.auth by writing their own or using  
third party user models. Other apps that need to interact with users (e.g.  
a commenting app) will be able to interact with them without knowing the  
specific implementation.


-   Batteries included

	Developers will not be required to implement their own authentication or  
authorization schemes for the common cases. Contrib.auth will have one or  
more built in user models ready for production.


-   Admin compatibility

	Contrib.admin is one of the things that make Django great. It should be  
easy for developers to make their user models accessible through the admin  
interface.


Terminology
---

In order to distinguish between Django's users, a website's users and the  
proposed concept of a user, the terms "developer", "visitor" and "user"  
are used respectively.



Implementation
--

The new contrib.auth will serve three primary functions:

-   Assist developers in writing custom user models.
-   Provide built in user models.
-   Provide a way for developers to interact generically with user models.

The new contrib.auth will allow developers to specify multiple user  
models. A new setting will be introduced called `USER_MODELS` which will  
be a tuple of strings. Each string's format will be `'%(app).%(model)'`,  
similarly to how `AUTH_PROFILE_MODULE` is currently defined. This setting  
will look something like:


USER_MODELS = (
'auth.EmailUser',
'myapp.CustomUser',
# ...
)

### Separation of concerns and the user contract

A user model will be a regular model that fulfills a predefined contract.  
Developers will be able to write their own user models in their  
applications and register them through the `USER_MODELS` setting. Any  
model that fulfills the user contract and is specified in `USER_MODELS`  
will be considered a valid user model. The contract will be subdivided in  
three subcontracts that will be concerned with identity, authentication  
and authorization.


 Identity

The identity contract will answer the "who are you" question for a user  
model. This could be anything from a twitter handle to a biometric  
identifier, or anything else that can uniquely identify a user in a user  
model. To fulfill the identity contract the user model will have to:


-   Implement an `identity` method.

	This method must return a string that uniquely represents a user in a  
user model.


-   Implement a `get_by_identity` method on the model's default manager.

	This method must accept a string representing a user, as returned by the  
`identity` method, and return the either a user object, if it finds one,  
or `None` otherwise.


-   Implement a `__unicode__` method.

	This method must return a string representation of a user that is  
suitable for displaying on the frontend. This will not be required to be  
unique across all users in a user model.


 Authentication

The authentication contract will be concerned with verifying that the user  
is indeed who he claims to be. Again, this could be anything from a  
password to a hardware dongle. To fulfill the authentication contract the  
user model will have to:


-   Implement an `is_authenicated` method.

	This method must accept a request. Contrary to the current  
implementation, the `is_authenticated` method will not always return  
`True`. It is up to the implementation to decide whether the user is  
actually authenticated.


-   Implement an `is_authenticated_by` method.

	This method must accept any