Re: Composite Key at Europython
On Thu, Mar 15, 2012 at 01:02:24PM +0100, Simone Federici wrote: > I'd like speak at europython about a project on composite primary and > foreign key for Django. > > https://github.com/simone/django-compositekey > > This solution that I'm using on a very small realty. I've developed using > monkey some patch because the purpose was not forking django. Is more easy > introduce a small library in a project that a fork of django itself. > > So I was preparing the paper to submit to Europython when I saw the > konk (Michal Petrucha) fork of Django, that is envolved on "composite > key problem". [Hey Michal nice to meet you]. > > Now, I'd like meet someone at Europython to speak about this project, and > how the multiple primary/foreign key will be introduced in Django. Maybe in > 1.5? Do you think it will be possible? > > I think this is possible. > > Michal do you think to fly on florence next July? > someone else wants to join the idea? Hi Simone, I'll consider attending, there's a possibility I might get some support from my university; in that case I'm in, otherwise I'll have to explore other options. Concerning my fork, well, it's an approach more or less approved of by the core team which means there's a high chance it might get into trunk once it is done. The problem is, it requires some serious reworking of ForeignKeys which is almost done but I currently don't have the time to advance. That also means I don't have any estimate on when it might be done; I likely won't have much time until I finish my Bc. thesis. Unfortunately, currently I'm busy until Thursday; afterwards I'll try to find out whether it would be possible for me to attend. If you need my assistance before Sunday, unfortunately, I'm afraid I'll be of little help... Michal signature.asc Description: Digital signature
Re: Composite Key at Europython
On Friday, March 16, 2012 at 7:54 AM, Michal Petrucha wrote: > I'll consider attending, there's a possibility I might get some > support from my university; in that case I'm in, otherwise I'll have > to explore other options. > > The DSF has some funds set aside for precisely this purpose (getting developers in rooms together). If getting you to europython to hack with Simone helps make CPKs happen, I think you're a perfect candidate for a travel grant. Jacob (Sent from a phone; please excuse typos.) > > Concerning my fork, well, it's an approach more or less approved of by > the core team which means there's a high chance it might get into > trunk once it is done. The problem is, it requires some serious > reworking of ForeignKeys which is almost done but I currently don't > have the time to advance. That also means I don't have any estimate on > when it might be done; I likely won't have much time until I finish my > Bc. thesis. > > Unfortunately, currently I'm busy until Thursday; afterwards I'll try > to find out whether it would be possible for me to attend. If you need > my assistance before Sunday, unfortunately, I'm afraid I'll be of > little help... > > Michal -- 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: authentication by email
On Thu, Mar 15, 2012 at 4:49 PM, Carl Meyer wrote: > Hi Daniel, > > On 03/15/2012 09:24 AM, Daniel Sokolowski wrote: >> Why can we not just increase the length limit on the username field?, >> Why can't we just throw a validation error if data entered is to long >> and the schema has not been updated? I think the answer yes we can and >> easily. > > I don't mean to pick on you specifically, but to me this is an excellent > example of a casual assertion of something we can "easily" do that > doesn't hold up under real examination (for instance, if you tried to > write the patch to actually do it). > Why would anyone waste their time working on a patch that would be instantly rejected, as has been made patently clear throughout. The solution to these bugs is easy, it is just being ignored because it is 'too hard' to make these kinds of changes. Instead wishy-washy ways of completely rewriting authentication are dreamt up, planned, and then dropped. This is how I would fix it: 1) Fix the email length limit bug, and mark the field as a db index, but hide this by a settings hack, called CONTRIB_AUTH_EMAIL_FIX. If the settings hack is not set, raise a PendingDeprecationWarning 2) Add a management command 'auth_NN_inspectdb', NN being the version number, obviously. This command introspects the auth_user table, and determines if it needs changing, and prints out whether the table needs updating, which could include verbatim SQL statements for their engine. To cope with multiple databases, it takes a --database arg. 3) Add a management command 'auth_NN_updatedb'. This command introspects the auth_user table, and if it supports the engine, updates the DDL.To cope with mutliple databases, it takes a --database arg. 4) Add the following release notes: The contrib.auth.models.User model has increased the length of the email field to 254 characters, in order to allow all legal email addresses to be stored. In addition, the email field has been marked as a db index, in order to more easily allow email authentication. These changes are not made automatically by Django, sine they involve altering the structure of your database. Instead, you must enable this fix with by adding the settings.CONTRIB_AUTH_EMAIL_FIX. In addtion, there are two tools included to assist you inspect your database structure and migrate to the new structure. If you do not want to make these changes, you can instead keep using 1.4 behaviour by not adding settings.CONTRIB_AUTH_EMAIL_FIX=True. You will receive a PendingDeprecationWarning when starting up, as this fix will soon become default. 5) Since this scares you all so much, bump version to 2.0 6) Once released, reverse the hack in trunk so that settings.CONTRIB_AUTH_NO_EMAIL_FIX gets you 1.4 behaviour, and warns a DeprecationWarning. 7) Add the following relnotes to 2.1 The contrib.auth.models.User schema changes originally introduced in 2.0 are now the default. If you still do not wish to migrate your database structure, you can keep using the 1.4 behaviour for now, by adding settings.CONTRIB_AUTH_NO_EMAIL_FIX=True to settings.py If you do not either set settings.CONTRIB_AUTH_NO_EMAIL_FIX or update your database schema, then you will have problems when you encounter a user with an email address longer than 30 characters. The exact problem you will encounter depends upon your database: I feel the amount of work involved here for your average django end user is minimal, certainly compared to things like adding csrf tokens throughout. It has been made abundantly clear that this approach would not be considered - in particular, using settings hacks to pragmatically achieve change - so why bother pushing it any further? I love a clean design as much as the next person, but not fixing bugs that exclude users on grounds of 'aesthetics' is pedantic and wrong. > How do you propose to "throw a validation error" if "the schema has not > been updated"? How do we know whether it's been updated? Are you > proposing that Django should introspect the users database table every > time it starts up in order to check the length of the username field? > Where would you put this introspection check? Have you considered the > effects this would have on every user of contrib.auth (both those who do > and don't run the schema migration)? And the effect on Django > development (needing to run the tests with both an "old" and "new" table > to ensure that the backwards-compatibility handling is tested?) This is a bug, and fixing it will affect lots of Django users. I'm fed up of this excuse being used to avoid fixing it. You seem to take the view that change is too hard, and therefore we should not do this until we have a magical solution that is all things for all men. Personally, I take the view that every single django site out there is broken for 'maria.hernandez.gonza...@lar.longcorpname.com', has been for a long time, and sweet FA has been done to fix it. That view says fix it, fix it now,
Re: Composite Key at Europython
On Fri, Mar 16, 2012 at 13:59, Jacob Kaplan-Moss wrote: > The DSF has some funds set aside for precisely this purpose (getting > developers in rooms together). If getting you to europython to hack with > Simone helps make CPKs happen, I think you're a perfect candidate for a > travel grant. > That's very cool news! I've to study your fork because to use well the ForeignKeys you need to refactorng the join table system starting from a multicolumn field. If you have time see my solution. Actually it's work on ForeignKey, OneToOnefield and ManyToManyField. The other big problem I found is on resolve the generic relations, they are builded on a unique content_id, in my solution the library write the concatenation of pks (obvious escaped) in the content id and that's work for a lot os use cases, but django have a part where puts the generic content_id in a join with the ralated table, so our approch fail. As a first look in your branch the concatenation of pks are made like my way, in the python code. But for using well in the generic relation implementation, it will be better if we will found another way. Maybe, it's just an idea, the concatenation could be done by a database concat function, every db has its implementation. The value will be calculated and used in the same way how django do with the sequences, so also generic relations could be found a solution. -- 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: Composite Key at Europython
On Fri, Mar 16, 2012 at 13:54, Michal Petrucha wrote: > Unfortunately, currently I'm busy until Thursday; afterwards I'll try to > find out whether it would be possible for me to attend. If you need my > assistance before Sunday, unfortunately, I'm afraid I'll be of little > help... > If you are thinking to came and to propose a paper remember that the DEADLINE FOR PROPOSALS is MARCH 18TH, 23:59:59 CET :-) -- 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.
Ticket 16317 https://code.djangoproject.com/ticket/16317
The ticket 16317 has a very nice 4 months old patch (it's has a two lines fix, remainder are just test fixes). It was marked for 1.3 version but now it's better to change it to 1.4 version. As I really hate to patch django I think my only solution is "to lobby" this ticket here :-) Is there anything else I can do? Ciao. Marco. P.S. Someone said the putting your email in cc in a ticket isn't the way to go. -- 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.
Sporadic proxy deletion failures on mysql
Hello all, When running regressiontests.delete_regress.tests.ProxyDeleteTest and regressiontests.delete_regress.tests.ProxyOfProxyDeleteTest on mysql, sporadic IntegrityErrors would occur. This was caused by the proxy model's base model not having the proxy model as a dependency, and the sporadic nature was entirely the result of dictionary ordering going into Collector.sort() - sometimes it would be in an order that honored the constraints, sometimes it wouldn't. This was introduced, I believe, in revision 17664. I have only observed it on mysql, but it is hypothetically a universal issue. My proposed solution is simply to ensure that the proxy model's base class gets included as a dependency. I have created a ticket, https://code.djangoproject.com/ticket/17918 , and set the severity to "Release blocker", as well as supplied a patch that resolved the issue for me. If this issue is not a release blocker, or my patch is insufficient, please let me know. Regards, Nate -- 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.
auth.User refactor: reboot
Hi folks -- This discussion of user authentication by email is getting pretty nasty; can we start over? I know there's a lot of quite legitimate frustration here, but we really need to drop the personal stuff and focus on the problem at hand. I want to move this forward quickly, and I can commit to spending some time on it in the coming weeks, but I'm going to lose interest faster than than you can believe if the tone doesn't improve. Please: keep it professional, and focus on the tech. I promise things'll go smoothly if we all do. As I see it, there's two basic approaches we could take: 1. Incremental improvement: fix the most glaring issues with auth.User (starting with email addresses for login, clearly), and generally improve things a bit at a time. Once User's in a state where we're happy, move on the rest of the auth app -- again, a bit at a time. This approach would see the largest issues fixed more quickly, but would probably do so at the expense of code quality (e.g. requiring a one-off solution to schema migration of the User model) and would delay a more sweeping reform until later. 2. Complete improvement: recognize that the auth app is fundamentally flawed, and mercilessly refactor/replace/rewrite it, all in one go. The hypothetical results here would be better -- a modern auth system unencumbered by the decisions we made in 2005 -- but this would take far longer, and would block on things like the app refactor and schema migrations. There's also a middle-ground proposal from Clay: make the auth app swappable, thus making it possible for *users* to replace the auth app while leaving time for us to make either incremental or complete change, as we see fit. I think we need to come together and agree on an approach before we move forward, so I'd like to see some concrete proposals for each of these approaches. Since all options have merits and since I think it's unlikely we'll find consensus I'm prepared to make a BDFL ruling here. So if you feel strongly about one approach or another, please write a concrete proposal and post it here or on the wiki. I'll look these over -- and also review Clay's branch -- and (again, baring consensus) make a ruling next week. Just so my biases are clear: normally I'd lean more towards the completionist stance, but in this case I haven't seen an actual proposal to completely replace auth. Further, I think the fact that it's blocked on *other* pretty hairy issues means it'd be unlikely to see that much action that quickly. I'm also somewhat opposed to the "pluggable auth" idea since I think it dilutes the utility of having built-in auth. In other words, if we're going to make auth up to users, why not just get rid of the built-in auth altogether? So I'm leaning towards an incremental improvement approach, but only if I can see a concrete proposal that articulates what to change, and deals with the backwards-compatibility issues in a not-too-ugly way. Thanks! 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: reboot
A big +1 to this. I'm willing to help where I can as well if you can find some use for me :) I think one of the big problems is the lack of being able to modify the user model in any appreciable way. Regardless of incremental improvements or not I think one possibly decent method is that which is used by https://github.com/aino/django-primate It lets you specify a User model that is available at django.contrib.auth.models.User but can live anywhere. If we go with the incremental improvement kind of fix this could be done with a default option that maintains the current user model. If a rewrite option is in place then the default user model could be changed to better match a more generic model. On Friday, March 16, 2012 at 12:53 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > This discussion of user authentication by email is getting pretty nasty; can > we start over? I know there's a lot of quite legitimate frustration here, but > we really need to drop the personal stuff and focus on the problem at hand. I > want to move this forward quickly, and I can commit to spending some time on > it in the coming weeks, but I'm going to lose interest faster than than you > can believe if the tone doesn't improve. Please: keep it professional, and > focus on the tech. I promise things'll go smoothly if we all do. > > As I see it, there's two basic approaches we could take: > > 1. Incremental improvement: fix the most glaring issues with auth.User > (starting with email addresses for login, clearly), and generally improve > things a bit at a time. Once User's in a state where we're happy, move on the > rest of the auth app -- again, a bit at a time. This approach would see the > largest issues fixed more quickly, but would probably do so at the expense of > code quality (e.g. requiring a one-off solution to schema migration of the > User model) and would delay a more sweeping reform until later. > > 2. Complete improvement: recognize that the auth app is fundamentally flawed, > and mercilessly refactor/replace/rewrite it, all in one go. The hypothetical > results here would be better -- a modern auth system unencumbered by the > decisions we made in 2005 -- but this would take far longer, and would block > on things like the app refactor and schema migrations. > > There's also a middle-ground proposal from Clay: make the auth app swappable, > thus making it possible for *users* to replace the auth app while leaving > time for us to make either incremental or complete change, as we see fit. > > I think we need to come together and agree on an approach before we move > forward, so I'd like to see some concrete proposals for each of these > approaches. Since all options have merits and since I think it's unlikely > we'll find consensus I'm prepared to make a BDFL ruling here. So if you feel > strongly about one approach or another, please write a concrete proposal and > post it here or on the wiki. I'll look these over -- and also review Clay's > branch -- and (again, baring consensus) make a ruling next week. > > Just so my biases are clear: normally I'd lean more towards the completionist > stance, but in this case I haven't seen an actual proposal to completely > replace auth. Further, I think the fact that it's blocked on *other* pretty > hairy issues means it'd be unlikely to see that much action that quickly. I'm > also somewhat opposed to the "pluggable auth" idea since I think it dilutes > the utility of having built-in auth. In other words, if we're going to make > auth up to users, why not just get rid of the built-in auth altogether? So > I'm leaning towards an incremental improvement approach, but only if I can > see a concrete proposal that articulates what to change, and deals with the > backwards-compatibility issues in a not-too-ugly way. > > Thanks! > > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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: authentication by email
On Fri, Mar 16, 2012 at 10:05 AM, Carl Meyer wrote: [...] > I am not sure whether this should happen as a separate step or not. In > an ideal world, we would have a longer username field. In the real > world, we have to balance the benefit against the cost, and requiring a > schema migration from practically every Django installation on the > planet would IMO be the most significant backwards-incompatible change > Django has ever shipped, at least since Django 1.0. It is not at all > clear to me that the status quo, bad as it is, is worse than this cure. > I can't understand how bad is a database schema change. Almost all web site/applications need to change they database schema. Ok, in some cases there are people that don't update their databases, but I think this cases aren't willing to update their version of software as well. If the installed a web site/app is too small to be afraid to update, the database change will be fast enough to cause a minimal downtime. If the installed a web site/app is too big, the sysadmin/devops already know how to couple with database schema changes. And it's likely that they have a test/staging/validation environment to analyse the changes before production. This current limitation doesn't bother me, but all this concerned about database schema change does. :-) Regards, -- Luciano Pacheco blog.lucmult.com.br -- 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
On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > […] I'm not in favour of pluggable user models, as for me, they solve the wrong problem. A pluggable user model has to be set up by the project developer, whilst the attributes an app may need are specified solely by the app developer. If a project developer decides to add a 3rd party app to his project, where do the user preferences for that app live? Does the user model automatically get expanded with the extra fields required by that app? It all seems icky to me. To my mind, User + app specific user profiles are the correct approach, plus fixing the current minor issues with d.c.a., and providing tools and documentation to allow users to manage that change. Put another way, what does a pluggable user model get us? What is the big selling point, apart from being able to specify arbitrary columns to appear in auth_user rather than myapp_userprofile. 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.
Re: auth.User refactor: reboot
On Friday, March 16, 2012 at 1:29 PM, Tom Evans wrote: > I'm not in favour of pluggable user models, as for me, they solve the > wrong problem. A pluggable user model has to be set up by the project > developer, whilst the attributes an app may need are specified solely > by the app developer. > > If a project developer decides to add a 3rd party app to his project, > where do the user preferences for that app live? Does the user model > automatically get expanded with the extra fields required by that app? > It all seems icky to me. > > To my mind, User + app specific user profiles are the correct > approach, plus fixing the current minor issues with d.c.a., and > providing tools and documentation to allow users to manage that > change. > > Put another way, what does a pluggable user model get us? What is the > big selling point, apart from being able to specify arbitrary columns > to appear in auth_user rather than myapp_userprofile. > > > Well said; this is what I was trying to get at in my reservations about this approach. Thanks for more fully articulating it. I think the one thing we lose by deciding not to go with a pluggable user object is a bit of performance. That is, instead of a single "SELECT FROM user_table" we get a "SELECT FROM user_table" followed by a "SELECT FROM profile_table" (or a select_related-style join, best case). I'm OK with this, myself, but it's worth having on the record I think. 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: reboot
On Friday, March 16, 2012 at 1:29 PM, Tom Evans wrote: > On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss (mailto:ja...@jacobian.org)> wrote: > > Hi folks -- > > […] > > > > > I'm not in favour of pluggable user models, as for me, they solve the > wrong problem. A pluggable user model has to be set up by the project > developer, whilst the attributes an app may need are specified solely > by the app developer. > > If a project developer decides to add a 3rd party app to his project, > where do the user preferences for that app live? Does the user model > automatically get expanded with the extra fields required by that app? > It all seems icky to me. > > To my mind, User + app specific user profiles are the correct > approach, plus fixing the current minor issues with d.c.a., and > providing tools and documentation to allow users to manage that > change. > > Put another way, what does a pluggable user model get us? What is the > big selling point, apart from being able to specify arbitrary columns > to appear in auth_user rather than myapp_userprofile. > > In the current situation it would allow overriding the username field to be longer in order to use say an email address. But that particular issue is sort of a red herring to the larger issue that if what you want from the User model doesn't fit the current User model, your options are A) throw it out (which means you basically can't use any third party apps that deal with users), or B) monkey patch it/hack around the limitation. The model is completely inflexible. Which is fine when you just want to _add_ information, in those cases you can just use a profile. But what about when you want to modify one of the assumptions that the user model makes? (in the above example, what constitutes a valid username). In my mind unless the User model becomes nothing more than an intermediate model that other models FK back too (with no real attributes of it's own) you are always going to have an issue where someone wants to modify some part of it and can't without doing something really hacky. And I think that having a situation like that is far worse that pluggable user models. > > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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: auth.User refactor: reboot
Disclaimer: I was up really, really early this morning, so please bear with me if I sound somewhat incoherent... On March 16, 2012, at 12:29 , Tom Evans wrote: > On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss wrote: >> Hi folks -- >> […] > > I'm not in favour of pluggable user models, as for me, they solve the > wrong problem. A pluggable user model has to be set up by the project > developer, whilst the attributes an app may need are specified solely > by the app developer. > > If a project developer decides to add a 3rd party app to his project, > where do the user preferences for that app live? Does the user model > automatically get expanded with the extra fields required by that app? > It all seems icky to me. > > To my mind, User + app specific user profiles are the correct > approach, plus fixing the current minor issues with d.c.a., and > providing tools and documentation to allow users to manage that > change. > > Put another way, what does a pluggable user model get us? What is the > big selling point, apart from being able to specify arbitrary columns > to appear in auth_user rather than myapp_userprofile. I personally find the User/Profile mechanism in Django to be quite awkward, to be honest. It's certainly not the end of the world, but it'd be nice if it was...less contrived feeling. I have an interesting suggestion/compromise: What about a mechanism that allows the app developer to *add* fields to the User model, but not change (or remove) existing keys? From my vantage point, this would have nearly all of the benefits of a pluggable user model with almost none of the drawbacks, and it would feel much more straightforward than the current mechanism. There may be some reason that I'm missing as to why this is foolish, though. Here's my hit list of perceived benefits: 1. It regains the efficiency of a single table (which is minor, to be sure, but since Jacob already brought it up...) 2. It allows app developers who just need a little bit more than what the User model does to add their custom fields seamlessly. This would mean, for instance, a. That the admin would just magically have the new fields in the User form, instead of having to either plug in a custom form, set up a separate ModelAdmin for your profile, or whatever else. For registration, we could offer two stock forms (one minimalist one, and one complete one that just blindly uses every field we don't know we want to exclude (e.g. is_staff)). If neither form works for the end developer, then they write and use their own. b. That the end developers don't have to write repetitive glue code on every one of their projects to make their profile models work. (Why do I have to write a signal to auto-save a profile object on User object save every time, for instance?) 3. We don't have myapp_userprofile. This is kind of a big deal to me, because in most of my projects there is no "clear" / "correct" place for this model to live -- there's no single app that handles users, because that's what django.contrib.auth is supposed to do. Getting these arbitrary columns into auth_user is a nice categorization win. If I understand this correctly, we avoid the following drawbacks of a fully pluggable system: 1. Apps can still be written to expect certain fields on User to exist, because the customization only allows the addition (not alteration) of fields. 2. We aren't expecting nearly every Django installation to write their own User model just to make a small addition to what stock Django offers; if you want just an extra field for birthdate, you don't write an entire custom user model; you just add the field. Since "I just want a few extra fields" is (other than the email address / username snafu) probably the most common need for auth, making this easy is a big win. What this does *not* solve is a situation where there's a field on User that's somehow wrong, such as the 30/75 character limitations on usernames and email addresses. Presumably this is done as part of a completionist revamp where we also fix those problems. Best Regards, Luke P. S. I've lurked on the Django dev list for a long time, but never gotten my feet wet. That said, the improvements to auth being discussed are something I really want, and I want them enough to help out non-trivially if afforded the opportunity. I was planning on emailing Carl and Russell to pick their brains later, but maybe it's worth a public statement. -- 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
On Friday, March 16, 2012 at 2:08 PM, Luke Sneeringer wrote: > Disclaimer: I was up really, really early this morning, so please bear with > me if I sound somewhat incoherent... > > On March 16, 2012, at 12:29 , Tom Evans wrote: > > > On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss > (mailto:ja...@jacobian.org)> wrote: > > > Hi folks -- > > > […] > > > > > > > > > I'm not in favour of pluggable user models, as for me, they solve the > > wrong problem. A pluggable user model has to be set up by the project > > developer, whilst the attributes an app may need are specified solely > > by the app developer. > > > > If a project developer decides to add a 3rd party app to his project, > > where do the user preferences for that app live? Does the user model > > automatically get expanded with the extra fields required by that app? > > It all seems icky to me. > > > > To my mind, User + app specific user profiles are the correct > > approach, plus fixing the current minor issues with d.c.a., and > > providing tools and documentation to allow users to manage that > > change. > > > > Put another way, what does a pluggable user model get us? What is the > > big selling point, apart from being able to specify arbitrary columns > > to appear in auth_user rather than myapp_userprofile. > > > > > I personally find the User/Profile mechanism in Django to be quite awkward, > to be honest. It's certainly not the end of the world, but it'd be nice if it > was...less contrived feeling. > > I have an interesting suggestion/compromise: What about a mechanism that > allows the app developer to *add* fields to the User model, but not change > (or remove) existing keys? From my vantage point, this would have nearly all > of the benefits of a pluggable user model with almost none of the drawbacks, > and it would feel much more straightforward than the current mechanism. There > may be some reason that I'm missing as to why this is foolish, though. > > Here's my hit list of perceived benefits: > 1. It regains the efficiency of a single table (which is minor, to be sure, > but since Jacob already brought it up...) > > This issue isn't as minor as one might think I don't believe. I've recently started using the fetch_related thing (which would be the only way to prevent N queries when trying to select a bunch of users + their profiles) and on a table with 20k entries (this isn't User related) where the entries are fairly large the processing time to fetch them all was very significant. This effect would increase with Tom's per app profile issue. > > 2. It allows app developers who just need a little bit more than what the > User model does to add their custom fields seamlessly. This would mean, for > instance, The subclassable user model that django-primate uses solves this as easily as it does the base fields. > > a. That the admin would just magically have the new fields in the User form, > instead of having to either plug in a custom form, set up a separate > ModelAdmin for your profile, or whatever else. For registration, we could > offer two stock forms (one minimalist one, and one complete one that just > blindly uses every field we don't know we want to exclude (e.g. is_staff)). > If neither form works for the end developer, then they write and use their > own. > > b. That the end developers don't have to write repetitive glue code on every > one of their projects to make their profile models work. (Why do I have to > write a signal to auto-save a profile object on User object save every time, > for instance?) > > 3. We don't have myapp_userprofile. This is kind of a big deal to me, because > in most of my projects there is no "clear" / "correct" place for this model > to live -- there's no single app that handles users, because that's what > django.contrib.auth is supposed to do. Getting these arbitrary columns into > auth_user is a nice categorization win. > > If I understand this correctly, we avoid the following drawbacks of a fully > pluggable system: > 1. Apps can still be written to expect certain fields on User to exist, > because the customization only allows the addition (not alteration) of fields. > > This is somewhat of a red herring I think. With any pluggable system you'll have a minimal set of required attributes. This minimum set of required is going to depend greatly on what apps you have installed. Some sites the only minimum would be the fact that a user model exists at all, some would require username, email, first and last name. > > 2. We aren't expecting nearly every Django installation to write their own > User model just to make a small addition to what stock Django offers; if you > want just an extra field for birthdate, you don't write an entire custom user > model; you just add the field. Since "I just want a few extra fields" is > (other than the email address / username snafu) probably the most common need
Re: auth.User refactor: reboot
Yeah, a mechanism where you can subclass User **and use your subclass in lieu** is quite similar to what I suggested and, I agree, solves the problems I raise. A subclass is also going to be substantially cleaner than having a new special way to add fields. Then we just need a Django setting to specify the User subclass, and which would check to ensure that any expected fields/methods are appropriately set (e.g. that it really does subclass User, or if it doesn't, that it duck types it comprehensively). Best Regards, Luke On March 16, 2012, at 13:15 , Donald Stufft wrote: > On Friday, March 16, 2012 at 2:08 PM, Luke Sneeringer wrote: >> Disclaimer: I was up really, really early this morning, so please bear with >> me if I sound somewhat incoherent... >> >> On March 16, 2012, at 12:29 , Tom Evans wrote: >> >>> On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss >>> wrote: Hi folks -- […] >>> >>> I'm not in favour of pluggable user models, as for me, they solve the >>> wrong problem. A pluggable user model has to be set up by the project >>> developer, whilst the attributes an app may need are specified solely >>> by the app developer. >>> >>> If a project developer decides to add a 3rd party app to his project, >>> where do the user preferences for that app live? Does the user model >>> automatically get expanded with the extra fields required by that app? >>> It all seems icky to me. >>> >>> To my mind, User + app specific user profiles are the correct >>> approach, plus fixing the current minor issues with d.c.a., and >>> providing tools and documentation to allow users to manage that >>> change. >>> >>> Put another way, what does a pluggable user model get us? What is the >>> big selling point, apart from being able to specify arbitrary columns >>> to appear in auth_user rather than myapp_userprofile. >> >> I personally find the User/Profile mechanism in Django to be quite awkward, >> to be honest. It's certainly not the end of the world, but it'd be nice if >> it was...less contrived feeling. >> >> I have an interesting suggestion/compromise: What about a mechanism that >> allows the app developer to *add* fields to the User model, but not change >> (or remove) existing keys? From my vantage point, this would have nearly all >> of the benefits of a pluggable user model with almost none of the drawbacks, >> and it would feel much more straightforward than the current mechanism. >> There may be some reason that I'm missing as to why this is foolish, though. >> >> Here's my hit list of perceived benefits: >> 1. It regains the efficiency of a single table (which is minor, to be sure, >> but since Jacob already brought it up...) > This issue isn't as minor as one might think I don't believe. I've recently > started using the fetch_related thing (which would be the only way to prevent > N queries when trying to select a bunch of users + their profiles) and on a > table with 20k entries (this isn't User related) where the entries are fairly > large the processing time to fetch them all was very significant. This effect > would increase with Tom's per app profile issue. >> >> 2. It allows app developers who just need a little bit more than what the >> User model does to add their custom fields seamlessly. This would mean, for >> instance, > The subclassable user model that django-primate uses solves this as easily as > it does the base fields. >> >> a. That the admin would just magically have the new fields in the User form, >> instead of having to either plug in a custom form, set up a separate >> ModelAdmin for your profile, or whatever else. For registration, we could >> offer two stock forms (one minimalist one, and one complete one that just >> blindly uses every field we don't know we want to exclude (e.g. is_staff)). >> If neither form works for the end developer, then they write and use their >> own. >> >> b. That the end developers don't have to write repetitive glue code on every >> one of their projects to make their profile models work. (Why do I have to >> write a signal to auto-save a profile object on User object save every time, >> for instance?) >> >> 3. We don't have myapp_userprofile. This is kind of a big deal to me, >> because in most of my projects there is no "clear" / "correct" place for >> this model to live -- there's no single app that handles users, because >> that's what django.contrib.auth is supposed to do. Getting these arbitrary >> columns into auth_user is a nice categorization win. >> >> If I understand this correctly, we avoid the following drawbacks of a fully >> pluggable system: >> 1. Apps can still be written to expect certain fields on User to exist, >> because the customization only allows the addition (not alteration) of >> fields. > This is somewhat of a red herring I think. With any pluggable system you'll > have a minimal set of required attributes. This minimum set of required is > going to depend
Re: Composite Key at Europython
Hi, Your project is stable ? Le 15/03/2012 13:02, Simone Federici a écrit : I'd like speak at europython about a project on composite primary and foreign key for Django. https://github.com/simone/django-compositekey This solution that I'm using on a very small realty. I've developed using monkey some patch because the purpose was not forking django. Is more easy introduce a small library in a project that a fork of django itself. So I was preparing the paper to submit to Europython when I saw the konk (Michal Petrucha) fork of Django, that is envolved on "composite key problem". [Hey Michal nice to meet you]. Now, I'd like meet someone at Europython to speak about this project, and how the multiple primary/foreign key will be introduced in Django. Maybe in 1.5? Do you think it will be possible? I think this is possible. Michal do you think to fly on florence next July? someone else wants to join the idea? -- 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 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
Hi everyone, I'm a student at Brandeis University, and I'm actually interested in working on an 'enhanced auth.user' for GSOC 2012. I don't have a formal proposal yet, but I drafted up the main idea of what's I'm planning in a google doc: https://docs.google.com/document/d/1HOHAs-mzwyNuZR8tVjGFXkt5XI64l7sOL_ao5FqNRZc/edit?pli=1. Once I work out some more of the details, I'll propose it in a separate thread and see where the discussion takes it. From playing around with the current code and making slight modifications, it seems like the idea will work. Michael Keselman On Fri, Mar 16, 2012 at 2:23 PM, Luke Sneeringer wrote: > Yeah, a mechanism where you can subclass User **and use your subclass in > lieu** is quite similar to what I suggested and, I agree, solves the > problems I raise. > > A subclass is also going to be substantially cleaner than having a new > special way to add fields. Then we just need a Django setting to specify > the User subclass, and which would check to ensure that any expected > fields/methods are appropriately set (e.g. that it really does subclass > User, or if it doesn't, that it duck types it comprehensively). > > Best Regards, > Luke > > On March 16, 2012, at 13:15 , Donald Stufft wrote: > > On Friday, March 16, 2012 at 2:08 PM, Luke Sneeringer wrote: > > Disclaimer: I was up really, really early this morning, so please bear > with me if I sound somewhat incoherent... > > On March 16, 2012, at 12:29 , Tom Evans wrote: > > On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss > wrote: > > Hi folks -- > […] > > > I'm not in favour of pluggable user models, as for me, they solve the > wrong problem. A pluggable user model has to be set up by the project > developer, whilst the attributes an app may need are specified solely > by the app developer. > > If a project developer decides to add a 3rd party app to his project, > where do the user preferences for that app live? Does the user model > automatically get expanded with the extra fields required by that app? > It all seems icky to me. > > To my mind, User + app specific user profiles are the correct > approach, plus fixing the current minor issues with d.c.a., and > providing tools and documentation to allow users to manage that > change. > > Put another way, what does a pluggable user model get us? What is the > big selling point, apart from being able to specify arbitrary columns > to appear in auth_user rather than myapp_userprofile. > > > I personally find the User/Profile mechanism in Django to be quite > awkward, to be honest. It's certainly not the end of the world, but it'd be > nice if it was...less contrived feeling. > > I have an interesting suggestion/compromise: What about a mechanism that > allows the app developer to *add* fields to the User model, but not change > (or remove) existing keys? From my vantage point, this would have nearly > all of the benefits of a pluggable user model with almost none of the > drawbacks, and it would feel much more straightforward than the current > mechanism. There may be some reason that I'm missing as to why this is > foolish, though. > > Here's my hit list of perceived benefits: > 1. It regains the efficiency of a single table (which is minor, to be > sure, but since Jacob already brought it up...) > > This issue isn't as minor as one might think I don't believe. I've > recently started using the fetch_related thing (which would be the only way > to prevent N queries when trying to select a bunch of users + their > profiles) and on a table with 20k entries (this isn't User related) where > the entries are fairly large the processing time to fetch them all was very > significant. This effect would increase with Tom's per app profile issue. > > > 2. It allows app developers who just need a little bit more than what the > User model does to add their custom fields seamlessly. This would mean, for > instance, > > The subclassable user model that django-primate uses solves this as easily > as it does the base fields. > > > a. That the admin would just magically have the new fields in the User > form, instead of having to either plug in a custom form, set up a separate > ModelAdmin for your profile, or whatever else. For registration, we could > offer two stock forms (one minimalist one, and one complete one that just > blindly uses every field we don't know we want to exclude (e.g. is_staff)). > If neither form works for the end developer, then they write and use their > own. > > b. That the end developers don't have to write repetitive glue code on > every one of their projects to make their profile models work. (Why do I > have to write a signal to auto-save a profile object on User object save > every time, for instance?) > > 3. We don't have myapp_userprofile. This is kind of a big deal to me, > because in most of my projects there is no "clear" / "correct" place for > this model to live -- there's no single app that handles users, because > that's what django.contrib.auth
Re: auth.User refactor: reboot
Hi, sorry, if this was said before, I haven't read the latest user discussions. I'm in favor of enhancing the auth app step by step, as everything else seems unlikely (haven't happend for a long time, why should it now). What I dislike about the current auth app in general is that it solves differnt things. You either have to take it all or do everything yourself. So perhaps a first step towards a new and shiny auth implementation might be to split things up? What do you think? Currently auth consists of multiple things: * authentication * authorization / permissions * Users * Groups In any case, the current auth system isn't all bad. I like many things and it works well for most cases. The email-login issue may be solves with randomly generated usernames and a authentication backend that matches by email-field instead. This all isn't perfect, but small steps may be enough to get to a nearly perfect solution here. David -- 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
On Friday, March 16, 2012 at 3:59 PM, David Danier wrote: > Hi, > > sorry, if this was said before, I haven't read the latest user discussions. > > I'm in favor of enhancing the auth app step by step, as everything else > seems unlikely (haven't happend for a long time, why should it now). > What I dislike about the current auth app in general is that it solves > differnt things. You either have to take it all or do everything > yourself. So perhaps a first step towards a new and shiny auth > implementation might be to split things up? What do you think? > > Currently auth consists of multiple things: > * authentication > * authorization / permissions > * Users > * Groups > > In any case, the current auth system isn't all bad. I like many things > and it works well for most cases. The email-login issue may be solves > with randomly generated usernames and a authentication backend that > matches by email-field instead. This all isn't perfect, but small steps > may be enough to get to a nearly perfect solution here. > > There are numerable issues with this that are not simply solved by an authentication backend. Amgonst them that the email column isn't unique, isn't required, isn't indexed is limited to 75 characters and isn't used as the representation for a user. > > David > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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: Class based views: A standard hook for http-method-independent code
> I don't really see what difference another function makes. > Sayhttps://gist.github.com/1957251is implemented, what makes: > > def prepare_view(self, request, *args, **kwargs): > # the thing I want to do > super(ClassName, self).prepare_view(request, *args, **kwargs) > > preferable over: > > def dispatch(self, request, *args, **kwargs): > # the thing I want to do > super(ClassName, self).dispatch(request, *args, **kwargs) > > ? https://gist.github.com/1957251 would allow: def prepare_view(self, request, *args, **kwargs): super(ClassName, self).prepare_view(request, *args, **kwargs) # the thing I want to do - can use self.request, self.args, self.kwargs As things stand now, I don't know of a graceful manner to use self.request in a http-method independent way. FWIW, I've ran into this restriction a number of times, including today. If one of the core devs will nod approval on this, I'll open a ticket and attach this gist to it. Cheers, Mike On Mar 4, 9:45 am, Tino de Bruijn wrote: > I don't really see what difference another function makes. > Sayhttps://gist.github.com/1957251is implemented, what makes: > > def prepare_view(self, request, *args, **kwargs): > # the thing I want to do > super(ClassName, self).prepare_view(request, *args, **kwargs) > > preferable over: > > def dispatch(self, request, *args, **kwargs): > # the thing I want to do > super(ClassName, self).dispatch(request, *args, **kwargs) > > ? > > You'll still have a super call because otherwise you have to repeat the > > self.request = request > self.args = args > self.kwargs = kwargs > > part of prepare_view. > > What is wrong with overriding dispatch and calling super? (Or not, if you > don't want to progress in the view) > > Tino > > > > > > > > On Fri, Mar 2, 2012 at 18:15, Jonathan French wrote: > > That's not the case - get_context_data, get_queryset, are examples of > > hooks like this preprocess one, not places where more would be added. I'm > > not sure if there's a better analogy. > > > Overriding the dispatch method would be the correct solution if you wanted > > to behave the same towards all methods, but seems a bit heavy for factoring > > out validation or common code between methods where you still want your > > get/post/etc to be called (or not, as the case may be.) > > > - ojno > > > On 2 March 2012 15:22, Andre Terra wrote: > > >> Then that would also be the case for many other methods in generic > >> class-based views, like get_context_data, get_queryset, etc.. I hate > >> boilerplate code as much as the next guy, but I'm not sure I follow why > >> this single method would get a special hook. Correct me if I'm wrong, but > >> special cases aren't special enough to break the rules. > > >> Cheers, > >> AT > > >> On Fri, Mar 2, 2012 at 11:53 AM, Jonathan French > >> wrote: > > >>> That's true, but I agree it seems a useful enough hook to make it a > >>> hook, rather than needing to do it yourself like that. I would vote for it > >>> being called 'preprocess', to make it clear that it's both optional and > >>> run > >>> before the method-specific function. > > >>> - ojno > > >>> On 2 March 2012 13:40, Michael van Tellingen < > >>> michaelvantellin...@gmail.com> wrote: > > Hi, > > This should already be quite easy to implement, do something like: > > def dispatch(self, *args, **kwargs): > # Some code > return super(YourView, self).dispatch(*args, **kwargs) > > Regards, > Michael > > On Fri, Mar 2, 2012 at 11:58, Charlie "meshy" Denton > wrote: > > I would like to see something like this too. I my suggestion is > > here:https://gist.github.com/1957251 > > > This method has two advantages: > > 1. You can modify the request, args, and kwargs before they get saved > to the > > view. > > 2. You can execute code after request, args, and kwargs are saved but > before > > the dispatch handler is called. > > 3. You can save extra variables to self as required > > > I expect 2 is probably the most common use case. > > > Meshy. > > > On Thursday, March 1, 2012 6:38:08 PM UTC, Marc Tamlyn wrote: > > >> Hi all, > > >> Apologies if this has been raised before. I've had a look around and > can't > >> find a good way of doing this with the current code. > > >> I regularly have views which rely on some custom code which runs some > >> sanity checking on the request and is independent of method. As an > example, > >> consider a view which creates an object related to a parent. This is > easily > >> achievable by overriding the form_valid method of CreateView and > excluding > >> the foreign key from the form. However, the view should return a 404 > if the > >> related object specified by the url does not exist. Written as a non > class > >> based view, the natural flow is to try to load t
Re: auth.User refactor: reboot
Hello, I'm also interested in working on an enhanced auth.user as a GSoC project and I'm currently working on my proposal. My proposal is largely based on pluggable auth models. What I'm seeing is that most people are generally negative to the idea, including core developers and django-developers' regulars. I have also read through the comments of ticket #3011 and the linked Google spreadsheet[1] where the idea was eventually rejected for 1.1. Moreover, Django's GSoC 2011 page (but not the one for 2012) specifically mentions that the idea has been rejected. That said, I believe that my proposal, when completed, will address most of the issues people are raising against the idea of pluggable user models. My question is whether I should continue writing/developing my proposal or is this something that has no chance of being accepted? Thanks. Stratos Moros 1: http://spreadsheets.google.com/ccc?key=pSqnCvef6OXmGWQ9qbEVMeA -- 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: Composite Key at Europython
On Fri, Mar 16, 2012 at 10:42, polo wrote: > Your project is stable ? that's the right question! no it isn't. As the docs said it is in a alpha release, I think is a good moment to create a first stable release but I'm waiting to release it as 1.0 when django 1.4 will be definitly released is it working? I use it and it's working for me, I wrote a good composite test suite that can be joined with the django tests: https://github.com/simone/django-compositekey/tree/master/djangotests/composite_modeltests there are two issue opened, one is related on oracle return id function, that is not implemented, the other as I says before is an important decision, I wrote the library composing the pk using a python function, but some features of generic relation joins tables using content_id and the other relations, how we can create a SQL join query using a result of a python function in one side and two or more columns in the other side? (it is possible, but is totally crazy for the performance, you need to do a full table scan to retrieve all key components and with they build the array of composite keys, and with it run the 2nd query) the unique way for me is use a concat database dependent concat function to have a unique key to use in the generic relations. something like that: PGSQL quote_literal(column1) || '#' ||quote_literal(column2) SQLITE quote(column1) || '#' || quote(column2) ORACLE 'id_1' || '#' || 'id_2' MYSQL concat(quote(column1), '#', quote(column2) ) so the response on you question is: no it isn't, because it's work only if you dont use some features of generic relations. It's enought for my actual project, but I don't know if can be good for yours. But if you help me to take this design decision, we could open a branch and change the logic to have a string concatenation on db side. We need to decide for the performance of the framework. anyway, if with your question you want to know if django using this project is yet stable, this is the results of test suite. (compositekey)aldaran@romilda:/mnt/source/home/aldaran/workspaces/django/django_compositekey/compositekey/djangotests$ ./cruntests.py --settings=test_sqlite Creating test database for alias 'default'... Creating test database for alias 'other'... ..s.sss...ss..s.x.sss...s...ss.s.s...s..ss.s.s..ss...ss..s.sx..s..s...ss..s.s...s...ss.ss..ss
Re: Making sure Web APIs built with Django don't have CSRF vulnerabilities.
>> 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 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
Hello, I would like to share some early stage thoughts on this matter. On Fri, Mar 16, 2012 at 5:01 PM, Donald Stufft wrote: > On Friday, March 16, 2012 at 3:59 PM, David Danier wrote: > > ... > Currently auth consists of multiple things: > * authentication > * authorization / permissions > * Users > * Groups > > Maybe the problem is that we think an User as a person. The User model could be more like an Account, having only attributes related to authentication. In that case, even the email address could be placed somewhere else. I understand that the email address is important, but for registration purposes, not for authentication. It seems to me that what really describes an User is in fact the User Profile (as metadata about an account). If we could separate the user creation process from the User model and put it as part of a registration entity or something, a project could extend/override it to set the account content and create the auxiliary models properly. This would allow the use of an username, or an email or any kind of unique identifier. We still would need to fix the column length, but this would help to keep the authentication process consistent. This would have impact on the admin. But maybe the User attributes needed by the admin should be provided there, as a model with FK to the Account. All the best, -- HB -- 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
On Friday, March 16, 2012 at 11:51 PM, Henrique Bastos wrote: > Hello, > > I would like to share some early stage thoughts on this matter. > > On Fri, Mar 16, 2012 at 5:01 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote: > > On Friday, March 16, 2012 at 3:59 PM, David Danier wrote: > > > ... > > > Currently auth consists of multiple things: > > > * authentication > > > * authorization / permissions > > > * Users > > > * Groups > > > > > > > > > > > > > > > Maybe the problem is that we think an User as a person. The User model could > be more like an Account, having only attributes related to authentication. > > In that case, even the email address could be placed somewhere else. I > understand that the email address is important, but for registration > purposes, not for authentication. It seems to me that what really describes > an User is in fact the User Profile (as metadata about an account). The issue is that authentication can vary from site to site. For instance on some sites usernames don't make sense and it makes more sense to use as email address as your identification token instead of a username (Facebook does this, as do many other sites). The larger issue is that no matter the length or the properties you give that field, _someone_ is going to want something different, or _something_ will change in the future that makes those existing assumptions now bad assumptions. Allowing the user model to be pluggable allows apps to change things around so that they can adjust on a per site level what a "user", or an "account" is for them. For some sites that might be username + passwords, others email + password, and still others might not have either and might be identified soley by an SSL client certificate. > > If we could separate the user creation process from the User model and put it > as part of a registration entity or something, a project could > extend/override it to set the account content and create the auxiliary models > properly. This would allow the use of an username, or an email or any kind of > unique identifier. We still would need to fix the column length, but this > would help to keep the authentication process consistent. > > This would have impact on the admin. But maybe the User attributes needed by > the admin should be provided there, as a model with FK to the Account. > > All the best, > -- > HB > > > > > > > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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: auth.User refactor: reboot
On 17/03/2012, at 12:53 AM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> This discussion of user authentication by email is getting pretty nasty; can
> we start over? I know there's a lot of quite legitimate frustration here, but
> we really need to drop the personal stuff and focus on the problem at hand. I
> want to move this forward quickly, and I can commit to spending some time on
> it in the coming weeks, but I'm going to lose interest faster than than you
> can believe if the tone doesn't improve. Please: keep it professional, and
> focus on the tech. I promise things'll go smoothly if we all do.
>
> As I see it, there's two basic approaches we could take:
>
> 1. Incremental improvement: fix the most glaring issues with auth.User
> (starting with email addresses for login, clearly), and generally improve
> things a bit at a time. Once User's in a state where we're happy, move on the
> rest of the auth app -- again, a bit at a time. This approach would see the
> largest issues fixed more quickly, but would probably do so at the expense of
> code quality (e.g. requiring a one-off solution to schema migration of the
> User model) and would delay a more sweeping reform until later.
>
> 2. Complete improvement: recognize that the auth app is fundamentally flawed,
> and mercilessly refactor/replace/rewrite it, all in one go. The hypothetical
> results here would be better -- a modern auth system unencumbered by the
> decisions we made in 2005 -- but this would take far longer, and would block
> on things like the app refactor and schema migrations.
>
> There's also a middle-ground proposal from Clay: make the auth app swappable,
> thus making it possible for *users* to replace the auth app while leaving
> time for us to make either incremental or complete change, as we see fit.
>
> I think we need to come together and agree on an approach before we move
> forward, so I'd like to see some concrete proposals for each of these
> approaches. Since all options have merits and since I think it's unlikely
> we'll find consensus I'm prepared to make a BDFL ruling here. So if you feel
> strongly about one approach or another, please write a concrete proposal and
> post it here or on the wiki. I'll look these over -- and also review Clay's
> branch -- and (again, baring consensus) make a ruling next week.
>
> Just so my biases are clear: normally I'd lean more towards the completionist
> stance, but in this case I haven't seen an actual proposal to completely
> replace auth. Further, I think the fact that it's blocked on *other* pretty
> hairy issues means it'd be unlikely to see that much action that quickly. I'm
> also somewhat opposed to the "pluggable auth" idea since I think it dilutes
> the utility of having built-in auth. In other words, if we're going to make
> auth up to users, why not just get rid of the built-in auth altogether? So
> I'm leaning towards an incremental improvement approach, but only if I can
> see a concrete proposal that articulates what to change, and deals with the
> backwards-compatibility issues in a not-too-ugly way.
Ok - I've been keeping quiet on this; partially due to the same tone issues
that you've described, but also because I don't have a huge amount of spare
time at the moment, and I don't want to be the person who makes a bunch of
promises (expressed or implied) to work on something and then can't deliver on
those promises.
My biggest concern is that the middle-ground proposals that are on the table
are implementing a workaround for a problem when the starting point of a
long-term solution won't require that much more effort.
IMHO, rather than implement a bunch of settings to introduce an
auth.User-specific solution, we need to do two things:
* Merge the app-refactor from GSoC 2010.
This has a whole bunch of long-needed awaited benefits -- reliable hooks for
app startup, configurable app labels, predictable module loading, amongst
others -- but the one that matters for the purposes of auth.User is that it
allows Apps to be treated as items that need to be configured as a runtime
activity. In this case, we need to be able to specify, at a project level,
which model is your "User" model in the auth app.
* Add the concept of a LazyForeignKey.
LazyForeignKey is a normal foreign key, with all the usual foreign key
behaviors; the only difference is that the model it links to isn't specified in
the model -- it's a configuration item drawn from an application configuration.
So, ForeignKey('auth.User') creates a foreign key to django.contrib.auth.User;
LazyForeignKey('auth.User') asks the auth app for the model that is being used
as the 'User' model, and creates a foreign key to that. This isn't a huge body
of work -- it's just a matter of slotting into the existing model reference
resolution code (which is something that the app refactor cleans up).
What are the benefits of this approach?
* It solves the gener
Re: auth.User refactor: reboot
On 17/03/2012, at 1:34 AM, Jacob Kaplan-Moss wrote: > On Friday, March 16, 2012 at 1:29 PM, Tom Evans wrote: >> I'm not in favour of pluggable user models, as for me, they solve the >> wrong problem. A pluggable user model has to be set up by the project >> developer, whilst the attributes an app may need are specified solely >> by the app developer. >> >> If a project developer decides to add a 3rd party app to his project, >> where do the user preferences for that app live? Does the user model >> automatically get expanded with the extra fields required by that app? >> It all seems icky to me. >> >> To my mind, User + app specific user profiles are the correct >> approach, plus fixing the current minor issues with d.c.a., and >> providing tools and documentation to allow users to manage that >> change. >> >> Put another way, what does a pluggable user model get us? What is the >> big selling point, apart from being able to specify arbitrary columns >> to appear in auth_user rather than myapp_userprofile. > Well said; this is what I was trying to get at in my reservations about this > approach. Thanks for more fully articulating it. > > I think the one thing we lose by deciding not to go with a pluggable user > object is a bit of performance. That is, instead of a single "SELECT FROM > user_table" we get a "SELECT FROM user_table" followed by a "SELECT FROM > profile_table" (or a select_related-style join, best case). I'm OK with this, > myself, but it's worth having on the record I think. The thing is, there's two separate problems here. Problem 1 is the problem of identity. auth.User currently enforces a specific set of restrictions on the username, email and "name" fields -- the fields dealing with identity -- which are critical to the operation of a User object, but don't have a single, canonical set of correct settings. Some people want a unique email field with max_length=254, some want a single "full name" field, rather than "first name"/"last name", and so on. There's currently no way for developers to support these decisions without forking and/or monkeypatching contrib.auth.models. Problem 2 is that people want to put their profile information on their User model. I completely agree that this is the wrong solution, and app-specific profile models are the way to go here. The reason to look at pluggable User models isn't problem 2 -- it's problem 1. Problem 2 already has a solution, and a good one at that IMHO. However, there isn't currently a good solution for problem 1, which is the root cause of most of the frustration in this thread, AFAICT. 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.
