Re: auth.User refactor: reboot

[Alex Ogier]

On Wed, Mar 21, 2012 at 2:41 AM, Clay McClure  wrote:
>
> I assume also that most changes would be relatively minor: dropping the
> username field, or "fixing" the email field (where the developer gets to
> define what that means), but not, say, removing all of the authorization
> attributes required by the admin.
>

Authorization and authentication are definitely orthogonal, and I would
hope that whatever proposal for pluggable auth.User models gets accepted
goes ahead and turns the current implementations of both into pluggable
pieces that can be reused separately.

There's another big use case for plugging into the User model: auth backend
per-app storage. There's currently no good way to distribute a backend that
stores access keys, openid identifiers etc. because profiles are
per-project. I think a pluggable User model will prove to be strictly
superior to profiles because of this.

To be clear on the ModelForm issue, though, is it correct to say that any
> LFK proposal must also provide LMFs (Lazy ModelForms)?
>

Anything that refers to the User class object has to be made lazy.
Pluggable models, if made general and used commonly, would basically
dictate a high-level architecture that consists of a lot of
meta-programming expressed through lazy references and class attributes,
resolving as the first requests make their way through the project.

-Alex Ogier

-- 
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: reboot

[Ian Lewis]

Hi,

On Tue, Mar 20, 2012 at 2:05 PM, Russell Keith-Magee
 wrote:
> On 20/03/2012, at 8:00 AM, Ian Lewis wrote:
>> Though we have had other times where there were multiple types of
>> users in a single project. i.e. users that signed up via some
>> affiliate program. username is unique so you wouldn't be able to use
>> the same username across user account types etc.
>
> I can see the use case here, but it seems to me that this is exactly what 
> UserProfiles (or a denormalized User model with multiple auth options) should 
> be used for.

With user profiles you have one single user and username/email
namespace whereas what I'm talking about are user namespaces and types
that are completely separate from each other. Sure you *could* make
everyone register once and then tack on user profiles based on what
things the user is signed up for or whatever but it seems like
something that the framework doesn't need to mandate. No argument
against it being the recommended way to do multiple users though.

> There's a very practical reason I say this -- If you have two separate user 
> models, aren't ForeignKeys a complete PITA?
>
> Lets say you have two different user types -- say, FacebookUser and 
> TwitterUser. Now, I create a comment model, and a comment has an Author which 
> is a User. How do I set up this foreign key?
>
> If FacebookUser and TwitterUser were set up as different subclasses/profiles 
> of User, then there's a common base class you can reference in a FK; but if 
> they're completely separate keys, you've either got to use 
> GenericForeignKeys, have two foreign keys every time you want to reference a 
> user, or maintain a third table that unifies the two user types.
>
> I feel like I must have missed something obvious here (either in your use 
> case or in your technical solution), because this seems like a pretty big 
> hurdle.

Hmm, I'm imagining different types of users with orthogonal spaces
rather than a two user types that can essentially do the same thing. I
suppose the use case I'm trying to describe isn't encountered very
often which is why it's hard to explain or visualize. If you had the
kind of user you are describing there is no doubt you would have a
user table and have profiles or a related model. This is part of the
reason it's at the bottom of the list of features I described earlier
(it was sorted by importance).

>> Granted separation
>> *may* be done by creating a whole separate project and isolating
>> common code into a library but auth/admin is currently making it so
>> you *have* to do it that way.
>
> One option is to allow auth to support multiple models, as you've done.
>
> A second would be to have a separate project, as you alluded to earlier.
>
> The third option would be to have multiple auth apps -- e.g., one for admin 
> users, and one for regular users. Yes, there's a configuration issue of 
> determining which auth app you want to use in different circumstances, but 
> that's going to exist anyway under your approach -- you're going to need apps 
> to know how to ask for the "right" User model.
>
> The problem I'm having with your newauth is that I'm not yet convinced that 
> the use case you present is enough to warrant adding a 'multiple user model' 
> capability to Django's base auth app -- especially if you can achieve the 
> same end by having multiple auth apps, or parallel projects.

To my mind it's the least important of the tenets of the design of
newauth, but I personally would like to use it at least for admin
users and normal site users. The issue for me is that the
functionality required of users of the admin will be different from
users of the site itself. Part of the problem with the current auth is
that it's forcing a number of fields and functionality on developers
that isn't necessary for their site for the sake of the admin. This is
probably my strongest argument and feeling for having multiple user
models, at least as far as the admin is concerned. I just don't really
see any reason why users on the site needed to share any data with
admin users so I separated them and (would) made them different models
(currently they are separated simply by the fact they are in different
apps).

>> I just think that the current auth app is mandating a certain way of
>> doing things that it doesn't necessarily need to and most users just
>> deal with it, in some cases bending over backwards, because they want
>> to use auth's API. That's the way I've always felt.
>
> I'm in complete agreement that the bits like username and email 
> size/uniqueness are completely arbitrary, and should be user-configurable. A 
> base implementation needs to exist so that things work out of the box, but 
> nothing Django ships should be bound to that base implementation (or, if it 
> must be bound, then we need to make the case that it truly is universal, or 
> near universal -- e.g., servicing the "Hi " requirement).

There are a lot of issues to consider as well as how fa

Re: auth.User refactor: reboot

[Ian Lewis]

Hi,

On Tue, Mar 20, 2012 at 10:37 PM, Russell Keith-Magee
 wrote:
> On 20/03/2012, at 8:38 PM, Tom Evans wrote:
>> User profiles solve the issue of app specific data in a better way
>> than specifying additional fields on a a base user object,
>> particularly as the number of apps increases. Whilst there is an
>> additional cost in joining to the user profile table, typically in
>> app1 you only need app1.UserProfile, and not appN.UserProfile.
>
> Go back and read my posts -- I've repeatedly said that I prefer UserProfile 
> as a pattern for *app specific* data. The only role that I see pluggable user 
> models solving is the issue of username and email length/uniqueness, and/or 
> the tracking of additional data required for the authentication process. 
> Anything else app specific should be kept in a UserProfile (or UserProfiles, 
> or some other model related 1-1 with User).
>
> A side effect of pluggable user models is that it would allow people to put 
> their profile data on their User model. However, as you point out, that has 
> all sorts of complications, and requires the User object to become a 
> monolith. I wouldn't recommend this approach, but as this thread has 
> revealed, many people prefer this approach for performance or aesthetic 
> reasons. The upside is that pluggable user models allows for this approach if 
> people want it. However, that doesn't mean that the Django docs should 
> encourage it.

I just wanted to state, perhaps obviously, that UserProfiles are
really just models that have a fk to the user table. Nothing in my
proposal says you can't do that, or even recommends against it. I
think app-specific data should go in these kind of models. The user
models in my proposal would be models where you define on the model
what is needed for authentication, what the pk is, and perhaps some
other common profile data that is commonly used (like the user's name
and email or something). I'm not saying you should put everything that
ever had anything to do with your user on the user model.

>> I would disagree with this. The immediate problem from my POV is that
>> a user who takes the latest release of django, installs the stock auth
>> app has an email field which cannot hold valid email addresses, and a
>> username field that cannot hold email addresses. It's unclear that
>> your proposal changes this at all.
>>
>> One issue that you have not mentioned at all is schema changes with
>> pluggable user models. If your average user is going to specify what
>> fields his User model has in it, what processes will be put in place
>> to allow the user to move from their current auth_user table
>> structure?
>>
>> What about fixing the stock model definition (which will still have an
>> email field, I assume)? Since schema changes have not been mentioned,
>> I'm inferring that this would not change, and the 'fixed' version of
>> django, by default, would still disallow a wide range of valid email
>> addresses.
>
> My proposal for this would be to treat the migration process the same as 
> we've done for any other feature that we've added to Django -- make it an 
> opt-in change with a documented migration path.
>
> For example, when we introduced localization, we set the default to USE_L10N 
> = False, and made the default behaviors unchanged from the older unlocalized 
> behavior. However, if you opted in to USE_L10N = True, you got all the nice 
> new localization features, and possibly a couple of migration headaches. 
> However, because it was an explicit opt-in, you're on the lookout for things 
> that might have changed or broken.
>
> Similarly, I would argue that we if we include this change, we have to ship a 
> concrete User model that is *unchanged* from it's current definition. We then 
> have three options:
>
>  1) Ship an updated User model (say, SimpleUser) with corrected email 
> max_length (and any other changes that pop up). We document the process for 
> opting in to using SimpleUser, including the ALTER TABLE statements that are 
> required to modify any existing databases.
>
>  2) Ship a range of sample User models representing common User model 
> patterns (e.g., using email as login, username but no email, etc) and provide 
> the migration path for each.
>
>  3) Punt on the entire issue, document the limitations with the built in User 
> model, and let the community manage User models; document what people need to 
> do in order to switch, but leave migration as an open question that people 
> providing new User models need to answer.
>
> Personally, I'd be in favor of option (3), mostly because what the last 6 
> years has taught us is that no matter what we pick as field names/sizes, 
> *someone* will be unhappy. However, I won't get too bent out of shape if 
> Django ends up shipping at least 1 new concrete User model -- at the very 
> least, it's a good way to prove we can eat our own dogfood.
>
> If we introduce 1-N new User classes, we could also take the opportunit

Re: release blocker in 1.4rc2 ?

[Jannis Leidel]

On 21.03.2012, at 04:56, s wrote:

> Hi all,
> I just opened https://code.djangoproject.com/ticket/17944,  not sure it's 
> should be marked as release-blocker, please could some core-developer check 
> it ?
> 
> The ticked has 1.4beta1 release, there is no rc2 in the list
> 

I just added 1.4-rc-1 and 1.4-rc-2 to the list of versions.

Jannis

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Making sure Web APIs built with Django don't have CSRF vulnerabilities.

[Tom Christie]

I don't know how much of an issue it really is (or not), but I haven't 
really seen it being done right.
Of all the examples I've found of devs implementing session authentication 
on top of piston and tastypie, (See 
here,
 
hereand
 
here)
 
none have re-enabled CSRF protection. (As far as I can tell.)

Having said that, I really just wanted to:

1. Get the core devs opinion on if would ought to actively do anything 
about this in core, since it's pretty easy to shoot yourself in the foot.
2. Raise the issue, so that there's at least more awareness that devs 
really should be making sure that any same-site AJAX driven APIs *do* get 
CSRF protection. [*]

I fall into the camp of "you should understand what you're doing when
> you turn CSRF protection off". If the framework authors want to
> support session based authentication, I believe they're capable of
> doing it correctly. Until then, if users want to hack session based
> auth onto the frameworks, they should be careful and understand what
> they're doing.


I'm happy with that.

Thanks for the feedback,

  Tom

[*] Only relevant to APIs that support POST/PUT or DELETE operations of 
course.  Read-only APIs will be just fine.

On Saturday, 17 March 2012 03:24:04 UTC, Paul McMillan wrote:
>
> >> One idea to mitigating this in Django core that I've considered would be
> >> introducing a '@csrf_defered' decorator
>
> > Practically speaking, I think this might be ok and would cover the
> > majority of real cases. But at the very least it means that this
> > decorator should live in contrib.sessions, not in the core CSRF code.
>
> I would be opposed to this code in any shipped part of Django. It
> certainly could be built as a third party module (if we don't have the
> hooks necessary to do this, we can discuss them). My main objection is
> that CSRF is not a topic which should be deferred, or maybe on, or
> anything except absolutely positively explicitly on or off.
> Introducing a deferred format encourages developers to ignore it,
> until it causes problems, at which point they will do exactly the same
> thing as they do now, and turn it off. It's easy enough to screw up
> already - adding a "maybe on" is going to bite developers even more
> than the current format, since it will be even easier to write code
> that works most of the time, for most users, but not all of the time,
> for all users.
>
> I fall into the camp of "you should understand what you're doing when
> you turn CSRF protection off". If the framework authors want to
> support session based authentication, I believe they're capable of
> doing it correctly. Until then, if users want to hack session based
> auth onto the frameworks, they should be careful and understand what
> they're doing.
>
> For readers who have not inspected it yet, Django's CSRF
> implementation is quite instructive:
>
> https://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py
>
> -Paul
>
>

-- 
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/-/Dq4aUlP24nAJ.
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: Schema Alteration API proposal

[Kushagra Sinha]

One more thing:
The current creation API in django has methods like "sql_create_model"
which basically return sql and it is the caller's responsibility to either
call cursor.execute on it (syncdb) or output the sql itself (sql).

South's (and xtrqt's) design is to have functions like "create_table" which
execute the sql themselves. Makes little difference to commands like syncdb
when they will be rewritten but commands like sql will have to so something
like start_transaction, get_sql, rollback_transaction which is kinda
hackish according to me.

What should be the design of the new migrations api?

Any thoughts on this?

On Tue, Mar 20, 2012 at 3:47 AM, Andrew Godwin  wrote:

> On 19/03/12 20:33, Kushagra Sinha wrote:
>
>> Andrew's thread[1] also mentions  - "backends will always be able to
>> generate SQL for operations, but it won't necessarily be runnable
>> (things like index names can only be resolved at runtime, so you'd get
>> code like "DROP INDEX <> ON users;"."
>>
>> [1]
>> https://groups.google.com/**forum/?fromgroups#!topic/**
>> django-developers/usFXJvpelmI
>>
>> Am I correct to assume that the plan is to allow migration files in
>> python as well as pseudo-SQL like above?
>> In that case, I think will concentrate on just the core part of
>> migrations API and nothing else as far as GSoC is concerned.
>>
>
> The actual migration file loading/running system was never intended to be
> part of the GSOC (nor my port when I was planning it) - the idea was to get
> just the database API in for a release, allowing South to lose all that
> code, then work on a migration file/running/dependency API for the next one.
>
> There's a lot more potential bikeshedding and design issues with writing a
> migration-running API, so that's one of the reasons it's separated out. I'd
> highly recommend focusing just on the database API - what's in South
> currently can't be ported straight across, and it needs quite a bit of
> cleanup (especially in the SQLite code), so it's still a decent amount of
> work.
>
>
>
>  Another query:
>> Andrew's thread above also mentioned:
>> Some of these operations are already mostly implemented (add_table,
>> add_index, etc.) in backends' creation modules, but they'll need a bit
>> of rearranging and separating into a full public API. I also plan to
>> modify them to take model names and field names, instead of table names
>> and column names, so the API is exclusively using the Django model layer
>> to represent changes (there's a possibility that some changes make sense
>> for schemaless databases as well, specifically renames, so it's best not
>> to tie it directly to relational databases).
>>
>> As it happens xtrqt last year had implemented, documented and tested the
>> migrations API for at least SQLite[2]. However he used explicit table
>> and column names in his API methods. Obviously he put the task of table
>> name translation on the API caller. Is there any consensus on the API
>> design regarding this point?
>>
>
> I feel that table names should definitely be explicit, as models expose
> their expected name. Column names are harder if you accept Django fields as
> valid inputs for the type - South currently uses implicit column names in
> add_table (i.e. _id gets auto-added) and explicit elsewhere. I'd rather it
> was explicit everywhere, and the field's column information was ignored in
> the schema alteration API (it's the migration runner's job to feed it the
> right stuff, I'd say).
>
> Don't rely too heavily on xtrqt's work from last year - the work that was
> done was basically a copy of South's code into a new module with a few
> minor changes. We're looking for a more extensive, clean move, with some
> partial rewriting - in particular, I'd like to make the dry_run system more
> sensible (or possibly drop it in favour of having a SQL generation mode
> that would serve a similar purpose).
>
> SQL generation itself would be a nice feature - it's not always possible
> (delete_index, delete_unique), but something that tries where it can, and
> puts comments/invalid SQL where it can't, would be nice.
>
> 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+unsubscribe@**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 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://grou

Re: Improved Error Reporting in Django - GSoC

[Daniel Sokolowski]

FYI: for my development settings I set: TEMPLATE_STRING_IF_INVALID = 
'UNDEFINED_VAR: %s'  which tells me which variables are undefined. 

It has some quirks (password reset form in admin link fails or something) but 
it’s easy to live with during development. 

From: Sachin Gupta 
Sent: Tuesday, March 20, 2012 3:18 AM
To: django-developers@googlegroups.com 
Subject: Re: Improved Error Reporting in Django - GSoC

Hi Andrew 

As about the silent template failure I was not very sure if it was a deliberate 
design decision, but since it a deliberate design decision I would not like to 
change it. Since I did both the backend and template editing, it appeared to me 
that some error should have come.

But I would like to make the error reporting from signals a little better. What 
I would like to do is to trace the control flow and throw the error according 
to the context of the flow. About how I plan to do that, I need to go through 
the code base thoroughly and will try to come up with a method.

I went through the https://code.djangoproject.com/wiki/BetterErrorMessages 
page. 

Today I will go into the following errors 

Some of the django.db errors and also at Ticket:#15126, when a user forgets a 
trailing comma in a single-item tuple then the error message is quite 
misleading.

Could you guide me what number of error fixes would be good work for GSOC 
proposal. Also if there are any class of Django errors that are of greater 
concern (like django.db)

Regards
Sachin

-- 
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/-/cuYearvU_OoJ.
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 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: Schema Alteration API proposal

[Andrew Godwin]

On 21/03/12 13:27, Kushagra Sinha wrote:

One more thing:
The current creation API in django has methods like "sql_create_model"
which basically return sql and it is the caller's responsibility to
either call cursor.execute on it (syncdb) or output the sql itself (sql).

South's (and xtrqt's) design is to have functions like "create_table"
which execute the sql themselves. Makes little difference to commands
like syncdb when they will be rewritten but commands like sql will have
to so something like start_transaction, get_sql, rollback_transaction
which is kinda hackish according to me.

What should be the design of the new migrations api?


Choosing one of these options and justifying it is a decent part of the 
application :)


I'd suggest not having multiple functions to do the same thing, but 
rather a modification of the South API to allow it to output SQL 
(probably replacing the dry-run mode). It won't be possible for all the 
South functions, but crucially it will be possible for the functions in 
.creation you'd be replacing.


Of course, this method carries with it a high testing cost as you'll 
have to essentially remove .creation, migrate all the core code over to 
the new stuff, and add a new shim back into .creation for the bits you 
replaced. You'll also have to consider what happens to apps like 
GeoDjango throughout all this.


You may want to opt for the simpler method and just get .alteration 
working for now and mirror some of the methods. Just make sure that 
whatever you choose, it fits into the schedule, and you can justify it.


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: Improved Error Reporting in Django - GSoC

[Andrew Godwin]

On 20/03/12 20:33, Sachin Gupta wrote:

It seems most of the errors on this page
https://code.djangoproject.com/wiki/BetterErrorMessages are very old. It
states that if the attribute enctype="multitype/form-data" is not sent
then the following error comes up

TypeError at ...
string indices must be integers

However if this is the case then I am getting a form error, saying that
the file field is required. If the field attribute null is set True then
no error comes up at all.

Would it be a good idea to change this from a 'form' error to a
different kind of error that would state that the enctype attribute is
not set for the given form?


Well, is that error possible to detect sensibly? These tiny questions 
aren't what you should be asking now - we really want to see a 
well-rounded application with a list of what you plan to tackle (it 
doesn't have to be precise, just state the main problem areas), and a 
demonstration of some possible ways you might solve it.


Attempting to pick the errors and the correct solutions now is too 
fragile - if it turns out those errors are hard to fix, or the potential 
error you want to raise isn't working for whatever reason (perhaps it 
interrupts the call stack of something else), you'll need to work around it.


We want to see the ability to think independently in an application - 
your mentor isn't there to continually answer questions for you, they're 
there to check up on your progress now and again and answer the 
occasional design decision/gnarly core Django question. The ability to 
work independently, make good decisions and research/justify them well 
is a big part of GSOC, and something we're looking for.


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: auth.User: The abstract base class idea

[Alex Ogier]

I made a topic branch and refactored everything I thought was nicely
reusable from auth.User into abstract models in
django/contrib/auth/mixins.py. There are some good reusable pieces inside
auth.User, even if you want to entirely scrap Django's notion of identity
and the username and/or email fields. The change is transparent to Django's
test suite, and I did my best to leave the existing API identical.

My hope is that we can make, for example, contrib.admin only dependent on a
class implementing PermissionsMixin. Whether we do late binding to
auth.User with some jiggery-poker as described in the recent auth.User
reboot thread, load time plugging into the auth.User inheritance list as I
proposed in the first email in this thread, or just punt on the whole thing
and ask people to implement their own concrete classes, I think the
refactoring is a nice backwards-compatible way to expose pieces of
auth.User for people to reuse and/or depend on.

https://github.com/ogier/django/tree/auth-mixins

Does anyone have any opinions?

-Alex Ogier

-- 
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.