Re: auth.user refactor: the profile aproach

[Jacob Kaplan-Moss]

On Friday, April 6, 2012 at 2:29 PM, Daniel Sokolowski wrote:
> How is the final approach chosen ?
> 
> 
> 
> 

Adrian made the call earlier this week - we're going with Alex's approach.

Jacob

-- 
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: auth.user refactor: the profile aproach

[Daniel Sokolowski]

How is the final approach chosen ?

From: Alex Ogier 
Sent: Friday, April 06, 2012 2:31 PM
To: django-developers@googlegroups.com 
Subject: Re: auth.user refactor: the profile aproach

Tai, read https://gist.github.com/2289395 for a summary of many reasons why I 
think profiles are a bad idea, and unifying multiple profiles is an even worse 
idea. 

Best,
Alex Ogier


On Fri, Apr 6, 2012 at 6:15 AM, Tai Lee  wrote:

  Alex Ogier,

  Is it really better to require users to create their own User model that 
behaves like an admin user, instead of just shipping with a self contained 
admin user (as a profile model) without the auth component?

  If the auth app was purely a stub to connect different profiles and 
authentication systems from different apps (or the project), but doesn't 
actually define any identity or authentication or profile models itself (not 
counting base abstract classes), isn't that effectively achieving the 
separation that you want? Being able to use admin without the current cruft in 
auth or with any completely different authentication credentials, and similarly 
using any other pluggable app without any cruft needed by the admin.

  In any case, I don't think it will actually be possible to use the admin or 
any other pluggable app that relies on the concept of a central user who might 
access to multiple apps (instead of every app having its own users and auth) 
without *an* auth app and a central User model.

  Like Adrian, I don't actually use the User model for auth or identity (name, 
email, etc.) anymore. But unless you have authored *all* the apps in your 
project and they know how to talk to *your* User model, you still need a User 
from Django, because that is what all 3rd party pluggable apps will need.


  If I want to use any 3rd party apps that use the central user, I will still 
need to create a Django User and fake or sync the that are only there for the 
admin, even if I don't use the admin. If you still require swapped in User 
models to assume a minimal interface and fields, people will still have this 
problem.


  This is why I think the central User should not contain any auth or identity 
data, so there is no cruft required only for apps you may not even be using, 
and so you are not tied to any particular auth system.

  Cheers.
  Tai.


  On 06/04/2012, at 3:44 PM, Alex Ogier  wrote:


I think this proposal will make more sense if people stop thinking "If 
someone wants to use contrib.auth, then why do we need another crufty interface 
to swap out auth.User?" Instead think of someone who wants to use contrib.admin 
but not be stuck with contrib.auth.

The point of this proposal isn't to make contrib.auth larger and better, 
it's to make it unnecessary. A lot of people find contrib.auth's models 
unsatisfactory. Adrian Holovaty stated that he hasn't used auth.User for 
several years. When you have a complex site with multiple authentication 
methods and requirements that don't fit django's idea of a user, it stops being 
worth it to bend yourself to django's will. The problem is that contrib.auth 
and contrib.admin are currently intimately linked. This proposal's purpose is 
to give an official way to break these two apart.

I don't know of a single framework out there besides Django that ships with 
a fixed model for its users. The reason is that authentication and identity are 
radically different for every site so it's tremendously important to support 
whatever people decide to do, and not force decisions on them.

So, stop thinking just in terms of contrib.auth.models.User. If you're 
already using that with a profile and it's all working fine, then this change 
isn't for you. This is for everyone who just wishes auth.User would go away 
without totally borking admin.

Respectfully,
Alex Ogier

On Apr 6, 2012 1:21 AM, "Donald Stufft"  wrote:

  Nothing about this proposal prevents this.

  And in that case, no those 2 apps would not be able to be used together. 
But this is hardly the first 
  time that 2 apps cannot be used together. because of choices made like 
that on the app owner.
  On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff wrote:

I very much share Tai's concerns about the swappable user model 
introducing incompatibilities. Imagine two apps, each of which requires an 
"age" attribute on the user model. But suppose one of those apps expects age to 
be the number of years since that user's birth and one of those apps expects 
the age to be the number of years since the user registered for the website. 
The user model must provide the same attribute to both apps, but it is supposed 
to have a different value for each app. A developer will be unable to use these 
two apps together without patching one of them. 

A bit of a contrived example, maybe, but I can imagine this 
same-name-different-purpose issue 

Re: auth.user refactor: the profile aproach

[Alex Ogier]

Tai, read https://gist.github.com/2289395 for a summary of many reasons why
I think profiles are a bad idea, and unifying multiple profiles is an even
worse idea.

Best,
Alex Ogier

On Fri, Apr 6, 2012 at 6:15 AM, Tai Lee  wrote:

> Alex Ogier,
>
> Is it really better to require users to create their own User model that
> behaves like an admin user, instead of just shipping with a self contained
> admin user (as a profile model) without the auth component?
>
> If the auth app was purely a stub to connect different profiles and
> authentication systems from different apps (or the project), but doesn't
> actually define any identity or authentication or profile models itself
> (not counting base abstract classes), isn't that effectively achieving the
> separation that you want? Being able to use admin without the current cruft
> in auth or with any completely different authentication credentials, and
> similarly using any other pluggable app without any cruft needed by the
> admin.
>
> In any case, I don't think it will actually be possible to use the admin
> or any other pluggable app that relies on the concept of a central user who
> might access to multiple apps (instead of every app having its own users
> and auth) without *an* auth app and a central User model.
>
> Like Adrian, I don't actually use the User model for auth or identity
> (name, email, etc.) anymore. But unless you have authored *all* the apps in
> your project and they know how to talk to *your* User model, you still need
> a User from Django, because that is what all 3rd party pluggable apps will
> need.
>
> If I want to use any 3rd party apps that use the central user, I will
> still need to create a Django User and fake or sync the that are only there
> for the admin, even if I don't use the admin. If you still require swapped
> in User models to assume a minimal interface and fields, people will still
> have this problem.
>
> This is why I think the central User should not contain any auth or
> identity data, so there is no cruft required only for apps you may not even
> be using, and so you are not tied to any particular auth system.
>
> Cheers.
> Tai.
>
>
> On 06/04/2012, at 3:44 PM, Alex Ogier  wrote:
>
> I think this proposal will make more sense if people stop thinking "If
> someone wants to use contrib.auth, then why do we need another crufty
> interface to swap out auth.User?" Instead think of someone who wants to use
> contrib.admin but not be stuck with contrib.auth.
>
> The point of this proposal isn't to make contrib.auth larger and better,
> it's to make it unnecessary. A lot of people find contrib.auth's models
> unsatisfactory. Adrian Holovaty stated that he hasn't used auth.User for
> several years. When you have a complex site with multiple authentication
> methods and requirements that don't fit django's idea of a user, it stops
> being worth it to bend yourself to django's will. The problem is that
> contrib.auth and contrib.admin are currently intimately linked. This
> proposal's purpose is to give an official way to break these two apart.
>
> I don't know of a single framework out there besides Django that ships
> with a fixed model for its users. The reason is that authentication and
> identity are radically different for every site so it's tremendously
> important to support whatever people decide to do, and not force decisions
> on them.
>
> So, stop thinking just in terms of contrib.auth.models.User. If you're
> already using that with a profile and it's all working fine, then this
> change isn't for you. This is for everyone who just wishes auth.User would
> go away without totally borking admin.
>
> Respectfully,
> Alex Ogier
> On Apr 6, 2012 1:21 AM, "Donald Stufft"  wrote:
>
>>  Nothing about this proposal prevents this.
>>
>> And in that case, no those 2 apps would not be able to be used together.
>> But this is hardly the first
>> time that 2 apps cannot be used together. because of choices made like
>> that on the app owner.
>>
>> On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff wrote:
>>
>> I very much share Tai's concerns about the swappable user model
>> introducing incompatibilities. Imagine two apps, each of which requires an
>> "age" attribute on the user model. But suppose one of those apps expects
>> age to be the number of years since that user's birth and one of those apps
>> expects the age to be the number of years since the user registered for the
>> website. The user model must provide the same attribute to both apps, but
>> it is supposed to have a different value for each app. A developer will be
>> unable to use these two apps together without patching one of them.
>>
>> A bit of a contrived example, maybe, but I can imagine this
>> same-name-different-purpose issue coming up over and over again, making
>> otherwise pluggable apps incompatible with each other.
>>
>> I think we should go with a pared down user 

Re: GSoC 2012: Security Enhancements

[Rohan Jain]

Hi Russel,

That is a good news for me. I have added a timeline and posted it over
melange.

Public Gist for the same: https://gist.github.com/2203174

-- Rohan


On 16:14 +0800 /  6 Apr, Russell Keith-Magee wrote:
> 
> On 06/04/2012, at 3:54 PM, Rohan Jain wrote:
> 
> > Hi Russel,
> > 
> > Thanks for the reply.
> > 
> > On 14:42 +0800 /  6 Apr, Russell Keith-Magee wrote:
> >> 
> >> Hi Rohan,
> >> 
> >> Apologies for the lack of response. Anyone who has put effort into writing 
> >> up a proposal certainly deserves a response of some kind, so we've dropped 
> >> the ball here.
> >> 
> >> In our defence, here's a couple of the reasons why your proposal probably 
> >> hasn't got a wild response:
> >> 
> >> * You've picked a project on your own, rather than one that is on the list 
> >> of suggested projects. Part of the GSoC process is mentoring, and you need 
> >> to have a mentor that can spare the time, and has the technical skills to 
> >> review your work. Most of the projects on the suggested list already have 
> >> champions inside the community, so if you pick one of them, you're likely 
> >> to get a response. If you pick your own project, you also have to find 
> >> someone to get sufficiently enthused about it. 
> > 
> > I had picked the project from the list of suggested projects
> > (https://code.djangoproject.com/wiki/SummerOfCode2012#SecurityEnhancements).
> > In fact, I have tried to take on each of the issues mentioned there,
> > point by point. I did talk to Paul over the IRC about this.
> 
> Ah. Now I look a little stupid :-)
> 
> That project has evidently been added to the list since I last looked at the 
> list. Apologies for not keeping up to date.
> 
> >> Regarding your project proposal itself: I can't really address the 
> >> technical merits, because I don't have any expertise on CORS, or the 
> >> subtleties of the CSRF changes your proposing. What you've proposed 
> >> certainly sounds interesting on the surface, but I'd really want to see 
> >> someone like Paul McMillan comment on the technical specifics. Ideally, 
> >> Paul would also mentor the project, since he's Django's resident security 
> >> expert, and he'd need to sign off on anything that was bound for trunk.
> > 
> > I had some discussions with Paul over this earlier, but since a week
> > days I haven't been able to find him online.
> 
> It's good that you've discussed this with Paul -- he's certainly the man to 
> speak to.
> 
> >> So - apologies for not responding sooner. Unfortunately, I suspect that 
> >> while your project probably has merit, the community isn't in a position 
> >> to support your ambition at the moment. If Paul wants to swoop in at the 
> >> last minute and prove me wrong, I'd be a very happy man -- I hate seeing 
> >> someone enthusiastic get turned away -- but absent of that, it's only fair 
> >> that we be honest to you about your chances.
> > 
> > No worries. I am at a blame too for my own activity. I myself have
> > learnt a lot of interesting stuff from this. I would anyway be glad to
> > give something back to django.
> 
> The fact that this project *is* in fact on our suggested projects list means 
> I probably have to alter my advice. 
> 
> If you're still interested in doing this project, it's worth submitting it. 
> You've clearly put in a bunch of effort already, and it would be a pity for 
> that to go to waste. As an organization, we have a certain amount of 
> discretion as to the projects we pick, and if someone is clearly working with 
> the community to improve API or sort out fine details, we may be able to 
> overlook small problems with an "official" application. However, the 
> "official" application still needs to be submitted in order for the GSoC 
> process to go ahead. What you've got here looks solid enough to demonstrate 
> you've thought about the problem and have an good idea of how you're going to 
> solve it.
> 
> That said, ultimate selection of the project will probably have more to do 
> with Paul's availability and enthusiasm to mentor than the technical aspects 
> of your proposal.
> 
> All I would suggest is:
> 
>  * Add a detailed work breakdown (granularity ~1 week)
> 
>  * Push the "merging" activities to the status of "stuff I'll do if the 
> schedule allows at the end of the project". That removes the emphasis from 
> the merging activity, making it look less suspect from the GSoC process 
> point-of-view.
> 
>  * Submit the proposal, and hope Paul is watching this thread :-)
> 
> Yours,
> Russ Magee %-)
> 
> -- 
> 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.
> 

-- 
You received this message because you are subscribed to 

Re: [GSoC 2012] Schema Alteration API proposal

[Andrew Godwin]

On 06/04/12 06:34, j4nu5 wrote:

Actually I am not planning to mess with syncdb and other management
commands. I will only refactor django.db.backends creation functions
like sql_create_model etc. to use the new API. Behaviour and functionality
will be the same after refactor, so management commands like syncdb
will not notice a difference.


Alright, that's at least going to leave things in a good working state, 
then.



Currently, I can only think of things like the unique index on SQLite and
oddities in MySQL mostly again from South's test suite, I will give another
update before today's deadline.


There's a few other ones that South handles - like booleans in SQLite - 
but a look through the codebase would hopefully give you hints to most 
of those.



Are you referring to the fake orm? Well if you are satisfied with my above
explanation, there would be no need for it, since we will be using django's
orm.


Well, the "fake ORM" is exactly what you described above - models loaded 
and then cleared from the app cache. I'm not saying it's a bad thing - 
it beats what South had before (nothing) - but there could be alternatives.



Well you said it yourself above that "the models API in Django is not
designed with models asmoveable, dynamic objects". That is why I used
a column-based approach. The advantage will be felt in live migrations.
As for using Django fields for type information, I frankly cannot think of a
major valid negative point for now, I will revert later today.



If you plan to continue using
Django fields as type information (as South does), what potential issues
do you see there?

The only issue I can think of is the case of custom fields created by the user.


That's one big issue; one of South's biggest issues today is custom 
fields, though that's arguably more the serialisation side of them. 
Still, I'd at least like to see how you would want something like, say, 
GeoDjango to fit in, even though this GSOC wouldn't cover it - it has a 
lot of custom creation code, and alteration types that differ from 
creation types (much like SERIAL in postgres, which you _will_ have to 
address) and room would have to be made for these kinds of problems.


Andrew

--
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] Schema Alteration API proposal

[j4nu5]

On Thursday, 5 April 2012 21:25:19 UTC+5:30, Andrew Godwin wrote:
>
> If you plan to continue using 
> Django fields as type information (as South does), what potential issues 
> do you see there?
>
The only issue I can think of is the case of custom fields created by the 
user. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/TTHMOOOFAhYJ.
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: auth.user refactor: the profile aproach

[Tai Lee]

Alex Ogier,

Is it really better to require users to create their own User model that 
behaves like an admin user, instead of just shipping with a self contained 
admin user (as a profile model) without the auth component?

If the auth app was purely a stub to connect different profiles and 
authentication systems from different apps (or the project), but doesn't 
actually define any identity or authentication or profile models itself (not 
counting base abstract classes), isn't that effectively achieving the 
separation that you want? Being able to use admin without the current cruft in 
auth or with any completely different authentication credentials, and similarly 
using any other pluggable app without any cruft needed by the admin.

In any case, I don't think it will actually be possible to use the admin or any 
other pluggable app that relies on the concept of a central user who might 
access to multiple apps (instead of every app having its own users and auth) 
without *an* auth app and a central User model.

Like Adrian, I don't actually use the User model for auth or identity (name, 
email, etc.) anymore. But unless you have authored *all* the apps in your 
project and they know how to talk to *your* User model, you still need a User 
from Django, because that is what all 3rd party pluggable apps will need.

If I want to use any 3rd party apps that use the central user, I will still 
need to create a Django User and fake or sync the that are only there for the 
admin, even if I don't use the admin. If you still require swapped in User 
models to assume a minimal interface and fields, people will still have this 
problem.

This is why I think the central User should not contain any auth or identity 
data, so there is no cruft required only for apps you may not even be using, 
and so you are not tied to any particular auth system.

Cheers.
Tai.


On 06/04/2012, at 3:44 PM, Alex Ogier  wrote:

> I think this proposal will make more sense if people stop thinking "If 
> someone wants to use contrib.auth, then why do we need another crufty 
> interface to swap out auth.User?" Instead think of someone who wants to use 
> contrib.admin but not be stuck with contrib.auth.
> 
> The point of this proposal isn't to make contrib.auth larger and better, it's 
> to make it unnecessary. A lot of people find contrib.auth's models 
> unsatisfactory. Adrian Holovaty stated that he hasn't used auth.User for 
> several years. When you have a complex site with multiple authentication 
> methods and requirements that don't fit django's idea of a user, it stops 
> being worth it to bend yourself to django's will. The problem is that 
> contrib.auth and contrib.admin are currently intimately linked. This 
> proposal's purpose is to give an official way to break these two apart.
> 
> I don't know of a single framework out there besides Django that ships with a 
> fixed model for its users. The reason is that authentication and identity are 
> radically different for every site so it's tremendously important to support 
> whatever people decide to do, and not force decisions on them.
> 
> So, stop thinking just in terms of contrib.auth.models.User. If you're 
> already using that with a profile and it's all working fine, then this change 
> isn't for you. This is for everyone who just wishes auth.User would go away 
> without totally borking admin.
> 
> Respectfully,
> Alex Ogier
> 
> On Apr 6, 2012 1:21 AM, "Donald Stufft"  wrote:
> Nothing about this proposal prevents this.
> 
> And in that case, no those 2 apps would not be able to be used together. But 
> this is hardly the first
> time that 2 apps cannot be used together. because of choices made like that 
> on the app owner.
> On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff wrote:
> 
>> I very much share Tai's concerns about the swappable user model introducing 
>> incompatibilities. Imagine two apps, each of which requires an "age" 
>> attribute on the user model. But suppose one of those apps expects age to be 
>> the number of years since that user's birth and one of those apps expects 
>> the age to be the number of years since the user registered for the website. 
>> The user model must provide the same attribute to both apps, but it is 
>> supposed to have a different value for each app. A developer will be unable 
>> to use these two apps together without patching one of them.
>> 
>> A bit of a contrived example, maybe, but I can imagine this 
>> same-name-different-purpose issue coming up over and over again, making 
>> otherwise pluggable apps incompatible with each other.
>> 
>> I think we should go with a pared down user model and allow each app to 
>> manage whatever data it needs on each user through profiles and signals. 
>> Developers will end up with some data duplication, but I think that is 
>> preferable to confusion about the source and purpose of data. Profiles are 
>> essentially a way for each 

Re: GSoC 2012: Security Enhancements

[Russell Keith-Magee]

On 06/04/2012, at 3:54 PM, Rohan Jain wrote:

> Hi Russel,
> 
> Thanks for the reply.
> 
> On 14:42 +0800 /  6 Apr, Russell Keith-Magee wrote:
>> 
>> Hi Rohan,
>> 
>> Apologies for the lack of response. Anyone who has put effort into writing 
>> up a proposal certainly deserves a response of some kind, so we've dropped 
>> the ball here.
>> 
>> In our defence, here's a couple of the reasons why your proposal probably 
>> hasn't got a wild response:
>> 
>> * You've picked a project on your own, rather than one that is on the list 
>> of suggested projects. Part of the GSoC process is mentoring, and you need 
>> to have a mentor that can spare the time, and has the technical skills to 
>> review your work. Most of the projects on the suggested list already have 
>> champions inside the community, so if you pick one of them, you're likely to 
>> get a response. If you pick your own project, you also have to find someone 
>> to get sufficiently enthused about it. 
> 
> I had picked the project from the list of suggested projects
> (https://code.djangoproject.com/wiki/SummerOfCode2012#SecurityEnhancements).
> In fact, I have tried to take on each of the issues mentioned there,
> point by point. I did talk to Paul over the IRC about this.

Ah. Now I look a little stupid :-)

That project has evidently been added to the list since I last looked at the 
list. Apologies for not keeping up to date.

>> Regarding your project proposal itself: I can't really address the technical 
>> merits, because I don't have any expertise on CORS, or the subtleties of the 
>> CSRF changes your proposing. What you've proposed certainly sounds 
>> interesting on the surface, but I'd really want to see someone like Paul 
>> McMillan comment on the technical specifics. Ideally, Paul would also mentor 
>> the project, since he's Django's resident security expert, and he'd need to 
>> sign off on anything that was bound for trunk.
> 
> I had some discussions with Paul over this earlier, but since a week
> days I haven't been able to find him online.

It's good that you've discussed this with Paul -- he's certainly the man to 
speak to.

>> So - apologies for not responding sooner. Unfortunately, I suspect that 
>> while your project probably has merit, the community isn't in a position to 
>> support your ambition at the moment. If Paul wants to swoop in at the last 
>> minute and prove me wrong, I'd be a very happy man -- I hate seeing someone 
>> enthusiastic get turned away -- but absent of that, it's only fair that we 
>> be honest to you about your chances.
> 
> No worries. I am at a blame too for my own activity. I myself have
> learnt a lot of interesting stuff from this. I would anyway be glad to
> give something back to django.

The fact that this project *is* in fact on our suggested projects list means I 
probably have to alter my advice. 

If you're still interested in doing this project, it's worth submitting it. 
You've clearly put in a bunch of effort already, and it would be a pity for 
that to go to waste. As an organization, we have a certain amount of discretion 
as to the projects we pick, and if someone is clearly working with the 
community to improve API or sort out fine details, we may be able to overlook 
small problems with an "official" application. However, the "official" 
application still needs to be submitted in order for the GSoC process to go 
ahead. What you've got here looks solid enough to demonstrate you've thought 
about the problem and have an good idea of how you're going to solve it.

That said, ultimate selection of the project will probably have more to do with 
Paul's availability and enthusiasm to mentor than the technical aspects of your 
proposal.

All I would suggest is:

 * Add a detailed work breakdown (granularity ~1 week)

 * Push the "merging" activities to the status of "stuff I'll do if the 
schedule allows at the end of the project". That removes the emphasis from the 
merging activity, making it look less suspect from the GSoC process 
point-of-view.

 * Submit the proposal, and hope Paul is watching this thread :-)

Yours,
Russ Magee %-)

-- 
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: Security Enhancements

[Rohan Jain]

Hi Russel,

Thanks for the reply.

On 14:42 +0800 /  6 Apr, Russell Keith-Magee wrote:
> 
> Hi Rohan,
> 
> Apologies for the lack of response. Anyone who has put effort into writing up 
> a proposal certainly deserves a response of some kind, so we've dropped the 
> ball here.
> 
> In our defence, here's a couple of the reasons why your proposal probably 
> hasn't got a wild response:
>  
>  * You've picked a project on your own, rather than one that is on the list 
> of suggested projects. Part of the GSoC process is mentoring, and you need to 
> have a mentor that can spare the time, and has the technical skills to review 
> your work. Most of the projects on the suggested list already have champions 
> inside the community, so if you pick one of them, you're likely to get a 
> response. If you pick your own project, you also have to find someone to get 
> sufficiently enthused about it. 

I had picked the project from the list of suggested projects
(https://code.djangoproject.com/wiki/SummerOfCode2012#SecurityEnhancements).
In fact, I have tried to take on each of the issues mentioned there,
point by point. I did talk to Paul over the IRC about this.

> 
>  * You've picked a very gnarly problem. Security issues are the very model of 
> an 'anti-bikeshed'. If you read the original discussion about Bikesheds [1], 
> it's all about how everyone gives their opinion on "simple" topics, but 
> everyone leaves hard problems alone. In Django's context -- *everyone* has an 
> opinion about contrib.auth.User because it seems like a simple problem. 
> However, security is all about subtle issues and expert knoweledge. 
> Therefore, your pool of experts is much smaller.  
> 
> [1] http://bikeshed.com/

I recently generated some interest in this field, so picked up what I
would like to work on the best. For being in field of web development,
I believe it is necessary to have a good understanding of security.

> 
> Regarding your project proposal itself: I can't really address the technical 
> merits, because I don't have any expertise on CORS, or the subtleties of the 
> CSRF changes your proposing. What you've proposed certainly sounds 
> interesting on the surface, but I'd really want to see someone like Paul 
> McMillan comment on the technical specifics. Ideally, Paul would also mentor 
> the project, since he's Django's resident security expert, and he'd need to 
> sign off on anything that was bound for trunk.

I had some discussions with Paul over this earlier, but since a week
days I haven't been able to find him online.

> 
> What I can do is point at the things that look like problems from a GSoC 
> perspective. In particular, of the three sections to your project plan, two 
> of them (unified tokenization and django-secure) involve merging existing 
> projects into trunk. This is problematic, because one of the conditions of 
> GSoC is that the student writes the bulk of the code. While integrating these 
> two code pools may well be very valuable contributions to Django, they're not 
> good from the perspective of a GSoC project.

Yes, these two will be more calling out to my `git merge` skills. I
was assuming the most of my time would have spanned over CSRF
improvements, while using some functionality from centralized token
generation.

> 
> So - apologies for not responding sooner. Unfortunately, I suspect that while 
> your project probably has merit, the community isn't in a position to support 
> your ambition at the moment. If Paul wants to swoop in at the last minute and 
> prove me wrong, I'd be a very happy man -- I hate seeing someone enthusiastic 
> get turned away -- but absent of that, it's only fair that we be honest to 
> you about your chances.

No worries. I am at a blame too for my own activity. I myself have
learnt a lot of interesting stuff from this. I would anyway be glad to
give something back to django.

-- Rohan

> 
> Yours,
> Russ Magee %-)
> 
> On 06/04/2012, at 2:09 PM, Rohan Jain wrote:
> 
> > Hi again,
> > 
> > I really couldn't understand the response this post has got. It
> > deserved at least a little feedback, positive or negative. I guess I
> > wont be submitting this over melange.
> > 
> > Still, I have put some effort and research in the proposal. So if
> > possible I would like to know if it had anything of value. Maybe some
> > one could work over that, even me if I get the time.
> > 
> > --
> > Rohan
> > 
> > 
> > On 23:40 +0530 / 31 Mar, Rohan Jain wrote:
> >> Hi,
> >> 
> >> I am Rohan Jain, a 4th (final) year B.Tech undergraduate Student
> >> from Indian Institute of Technology, Kharagpur. I have been using
> >> django since over a year and generally look into the code base to find
> >> about various implementations. I have made attempts to make some minor
> >> contributions and if selected this would be my first major one.
> >> 
> >> More about Me: 
> >> IRC, Github: crodjer
> >> 
> >> I am interested in contributing some 

Re: GSoC 2012: Security Enhancements

[Russell Keith-Magee]

Hi Rohan,

Apologies for the lack of response. Anyone who has put effort into writing up a 
proposal certainly deserves a response of some kind, so we've dropped the ball 
here.

In our defence, here's a couple of the reasons why your proposal probably 
hasn't got a wild response:
 
 * You've picked a project on your own, rather than one that is on the list of 
suggested projects. Part of the GSoC process is mentoring, and you need to have 
a mentor that can spare the time, and has the technical skills to review your 
work. Most of the projects on the suggested list already have champions inside 
the community, so if you pick one of them, you're likely to get a response. If 
you pick your own project, you also have to find someone to get sufficiently 
enthused about it. 

 * You've picked a very gnarly problem. Security issues are the very model of 
an 'anti-bikeshed'. If you read the original discussion about Bikesheds [1], 
it's all about how everyone gives their opinion on "simple" topics, but 
everyone leaves hard problems alone. In Django's context -- *everyone* has an 
opinion about contrib.auth.User because it seems like a simple problem. 
However, security is all about subtle issues and expert knoweledge. Therefore, 
your pool of experts is much smaller.  

[1] http://bikeshed.com/

Regarding your project proposal itself: I can't really address the technical 
merits, because I don't have any expertise on CORS, or the subtleties of the 
CSRF changes your proposing. What you've proposed certainly sounds interesting 
on the surface, but I'd really want to see someone like Paul McMillan comment 
on the technical specifics. Ideally, Paul would also mentor the project, since 
he's Django's resident security expert, and he'd need to sign off on anything 
that was bound for trunk.

What I can do is point at the things that look like problems from a GSoC 
perspective. In particular, of the three sections to your project plan, two of 
them (unified tokenization and django-secure) involve merging existing projects 
into trunk. This is problematic, because one of the conditions of GSoC is that 
the student writes the bulk of the code. While integrating these two code pools 
may well be very valuable contributions to Django, they're not good from the 
perspective of a GSoC project.

So - apologies for not responding sooner. Unfortunately, I suspect that while 
your project probably has merit, the community isn't in a position to support 
your ambition at the moment. If Paul wants to swoop in at the last minute and 
prove me wrong, I'd be a very happy man -- I hate seeing someone enthusiastic 
get turned away -- but absent of that, it's only fair that we be honest to you 
about your chances.

Yours,
Russ Magee %-)

On 06/04/2012, at 2:09 PM, Rohan Jain wrote:

> Hi again,
> 
> I really couldn't understand the response this post has got. It
> deserved at least a little feedback, positive or negative. I guess I
> wont be submitting this over melange.
> 
> Still, I have put some effort and research in the proposal. So if
> possible I would like to know if it had anything of value. Maybe some
> one could work over that, even me if I get the time.
> 
> --
> Rohan
> 
> 
> On 23:40 +0530 / 31 Mar, Rohan Jain wrote:
>> Hi,
>> 
>> I am Rohan Jain, a 4th (final) year B.Tech undergraduate Student
>> from Indian Institute of Technology, Kharagpur. I have been using
>> django since over a year and generally look into the code base to find
>> about various implementations. I have made attempts to make some minor
>> contributions and if selected this would be my first major one.
>> 
>> More about Me: 
>> IRC, Github: crodjer
>> 
>> I am interested in contributing some security enhancements to django
>> as my Summer of Code project. Below is the 1st draft of my proposal
>> regarding this. A pretty version of this is available at:
>> https://gist.github.com/2203174
>> 
>> 
>> #Abstract
>> 
>> Django is a reasonably secure framework. It provides an API and
>> development patterns which transparently take care of the common web
>> security issues. But still there are security features which need
>> attention. I propose to work on integration of existing work on
>> centralized token system and improved CSRF checking without any
>> compromises. If time permits I will also attempt on integration of
>> django-secure.
>> 
>> #Description
>> ##Centralized tokenization
>> There are multiple places in django which use some or other kinds of
>> tokens:
>> 
>> - contirb.auth (random password, password reset)
>> - formtools
>> - session (backends)
>> - cache
>> - csrf
>> - etags
>> 
>> Token generation is pretty common around the framework.  So, instead
>> of each application having its own token system, and hence needs to be
>> maintained separately. There should be centralized token system, which
>> provides an abstract API for everyone to loose. In fact, I have seen
>> that some apps use 

Re: GSoC 2012: Security Enhancements

[Rohan Jain]

Hi again,

I really couldn't understand the response this post has got. It
deserved at least a little feedback, positive or negative. I guess I
wont be submitting this over melange.

Still, I have put some effort and research in the proposal. So if
possible I would like to know if it had anything of value. Maybe some
one could work over that, even me if I get the time.

--
Rohan


On 23:40 +0530 / 31 Mar, Rohan Jain wrote:
> Hi,
> 
> I am Rohan Jain, a 4th (final) year B.Tech undergraduate Student
> from Indian Institute of Technology, Kharagpur. I have been using
> django since over a year and generally look into the code base to find
> about various implementations. I have made attempts to make some minor
> contributions and if selected this would be my first major one.
> 
> More about Me: 
> IRC, Github: crodjer
> 
> I am interested in contributing some security enhancements to django
> as my Summer of Code project. Below is the 1st draft of my proposal
> regarding this. A pretty version of this is available at:
> https://gist.github.com/2203174
> 
> 
> #Abstract
> 
> Django is a reasonably secure framework. It provides an API and
> development patterns which transparently take care of the common web
> security issues. But still there are security features which need
> attention. I propose to work on integration of existing work on
> centralized token system and improved CSRF checking without any
> compromises. If time permits I will also attempt on integration of
> django-secure.
> 
> #Description
> ##Centralized tokenization
> There are multiple places in django which use some or other kinds of
> tokens:
> 
>  - contirb.auth (random password, password reset)
>  - formtools
>  - session (backends)
>  - cache
>  - csrf
>  - etags
> 
> Token generation is pretty common around the framework.  So, instead
> of each application having its own token system, and hence needs to be
> maintained separately. There should be centralized token system, which
> provides an abstract API for everyone to loose. In fact, I have seen
> that some apps use `User.objects.make_random_password` from
> contrib.auth, which they can be sure of being maintained in the future
> for random generation. To me this looks kind of weird.
> In last djangocon, a lot of work regarding this was done over [Yarko's
> Fork][yarko-fork].
> 
> I had a discussion with Yarko Tymciurak regarding this. The work is
> nearly ready for a merge, only some tasks left. In the initial period
> my SoC I can work over these to insure that the already done
> significant work gets in django and is updated for 1.5.
> 
>  - Porting more stuff to the new system (README.sec in
>[yarko's fork][yarko-fork])
>  - Testing - See if the current coverage of the tests is enough, write
>them if not.
>  - Compatibility issues
>  - API Documentation
> 
> I will study the changes done at djangocon and then attempt the tasks
> mentioned above.
> 
> ##CSRF Improvements
> 
> Cross-Origin Resource Sharing (CORS):  
> W3C has a working draft regarding [CORS][w3c-cors-draft], which opens
> up the possibility for allowing client-side request cross-origin
> requests. This directly triggers in mind the capability to develop
> API which can be exposed directly to the web browser. This would let
> us get rid of proxies and other hacks used to achieve this.
> Currently all the major browsers support this: Chrome (all versions),
> Firefox (> 3.0), IE (> 7.0), Safari (> 3.2), Opera (> 12.0).
> Introduced it here as some further parts of the post refer to this.
> 
> ###Origin checking
> 
> With CORS around need for using CSRF token can be dropped, at least in
> some browsers. [Ticket #16859][orig-check-ticket], is an attempt for
> that. But this was rejected because of neglecting the case for
> presence of `CSRF_COOKE_DOMAIN` (Refer to the closing comment on the
> ticket for details). So to handle this we need to simulate checking of
> CSRF cookie domain as web browsers do it. Maybe:
> 
> ```python
> reqest.META.get('HTTP_ORIGIN').endswith(settings.CSRF_COOKIE_DOMAIN)
> ```
> 
> As the closing comment points it out, we can't do this with secure
> requests. They need to be essentially checked against the referrer or
> origin, at least for now. We can not be sure that some untrusted or
> insecure subdomain has not already set the cookie or cookie domain.
> d
> To deal with this, we have to consider https separately as it is
> being done now. So it will be something like:
> 
> 
> ```python
> def process_view(self, request, ):
> 
> # Same initial setup
> 
> if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
> 
> host = request.get_host()
> origin = reqest.META.get('HTTP_ORIGIN', "")
> cookie_domain = settings.CSRF_COOKIE_DOMAIN
> 
> if request.is_secure():
> good_referer = 'https://%s/' % host
> referer = origin or request.META.get('HTTP_REFERER')
> # Do the same