Re: extra files in startproject

2012-04-13 Thread Aymeric Augustin 
On 12 avr. 2012, at 23:16, Aymeric Augustin wrote:

> Some people who had the habit of running "setup.py install" from a git clone 
> to keep up-to-date with the development version reported the problem.
> (Just to be 100% clear — this technique doesn't work because it doesn't 
> remove .py or .pyc files that are removed from Django.)

On 13 avr. 2012, at 06:49, Alex Ogier wrote:

> A reasonable
> way to track django trunk for example is to periodically pull and run
> "setup.py install" which is in most cases approximately idempotent.

No, this isn't a reasonable alternative, and installing software isn't an 
approximative operation.

Here's another example: this installation technique wouldn't reflect the 
changes in r17842 [1] properly — two files were removed. #18069 [2] was filed 
as a result.
The link between the problem and its cause was particularly tenuous in this 
case.

[1] https://code.djangoproject.com/changeset/17842
[2] https://code.djangoproject.com/ticket/18069

So a documentation fix might not be sufficient to eradicate the problem. Could 
we add this in a pre-install hook in setup.py?

try:
import django
except ImportError:
pass
else:
   print "It appears that Django %s is already installed." % 
django.get_version()
   print "If you want to upgrade Django, please remove the existing 
installation first."
   sys.exit(1)

To support pip install --upgrade, this code should be executed right before the 
new version is installed. I don't know very well what's possible with distutils.

Best regards,

-- 
Aymeric.

-- 
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: extra files in startproject

2012-04-13 Thread Luciano Pacheco 
On Fri, Apr 13, 2012 at 5:15 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 12 avr. 2012, at 23:16, Aymeric Augustin wrote:
>
[...]

> So a documentation fix might not be sufficient to eradicate the problem.
> Could we add this in a pre-install hook in setup.py?
>
> try:
>import django
> except ImportError:
>pass
> else:
>   print "It appears that Django %s is already installed." %
> django.get_version()
>   print "If you want to upgrade Django, please remove the existing
> installation first."
>   sys.exit(1)
>

This "import django" will work even when django is not installed, because
usually "python setup.py " is ran from checkout of django, that contains
the valid folder (python package) named "django". So, this "import django"
will import relative to current directory and will work.

[],
-- 
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: extra files in startproject

2012-04-13 Thread Alex Ogier 
On Apr 13, 2012 3:30 AM, "Luciano Pacheco"  wrote:
>
> This "import django" will work even when django is not installed, because
usually "python setup.py " is ran from checkout of django, that contains
the valid folder (python package) named "django". So, this "import django"
will import relative to current directory and will work.
>

And in fact, this behavior is relied upon. Django's setup.py imports the
relative django to get the version number.

Best,
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: the profile aproach

2012-04-13 Thread Tom Evans 
On Tue, Apr 10, 2012 at 6:04 PM, Alex Ogier  wrote:
> Hi Tom,
>
> The best rounded description with pros and cons is Solution 2a on
> https://code.djangoproject.com/wiki/ContribAuthImprovements
>
> You are correct that I am primarily thinking of pluggable authentication
> when I think of this new user model. The reason is that there is nothing
> stopping you from continuing to place app data outside the user model as has
> been standard for a while now. For example, there is nothing stopping you
> from using the following pattern in you app's view:
>
> if request.user.is_authenticated():
>     try:
>     prefs = GalleryPref.objects.get(user=request.user)
>     except GalleryPref.DoesNotExist:
>     prefs = None
>
> That is, unless you have a reason that your particular data should be
> eagerly loaded on every request there is no reason to require it on the
> user. In fact app developers are incentivized to keep their data separate in
> order to remain compatible with the default user.
>
> The solution isn't perfect, it does in fact provide some barriers to this
> pattern. The Gallery app must explicitly choose to foreign key to
> settings.USER_MODEL, and once they do *changing* which model the setting
> points to requires a migration of your table. These are both real issues,
> but I don't think that user model bloat will be because there is a
> straightforward way to work around it if it does prove to be an issue for
> any particular project.
>
> The only thing this proposal kills is magic proxying back from user
> attributes. If you really wanted to, you could roll your own proxy
> attributes to app fields, after all you control the entire user class.
>
> Best,
> Alex Ogier
>

Hi Alex, thanks for that. I think that a lot of this information
should end up in the revised docs, showing patterns on how to
(correctly) use the new features, when to add fields to user and when
not to, etc. and we should be fine.

I wasn't that interested in the magic proxying. Eventually, all magic
dies and has to be removed, so it is better to just be explicit about
what is happening.

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: django db library doesn't handle quoted table/field names

2012-04-13 Thread Craig Lucas 
I can attempt to merge his changes in and test it. Do people typically
merge these changes in manually? I see changes from a bunch of different
people over the last 4 years, should I just grab the last guys changes?

On Thu, Apr 12, 2012 at 9:16 PM, Ramiro Morales  wrote:

> On Thu, Apr 12, 2012 at 9:14 PM, Craig Lucas 
> wrote:
> > i actually didnt try the db_column attribute because I read about
> quoting it
> > before I started writing the code. But that wont solve the schema
> problem.
> >  It will still try to create the index and fk constraints with the dots
> and
> > quotes around the table name.
> >
> > i believe it is required to quote the schema and table name in the
> db_table
> > property as '"dim"."Application"', if you left it as 'dim.Application' it
> > would create the table as 'dim.application' and if it quoted it it would
> > still be wrong as "dim.Application"...that will fail also
> >
> > On the schema question, yes adding a db_schema property and all the
> > supporting code sounds like it would fit well...you can create fk's to
> > tables in diff schemas.
>
> This is ticket [1]#6148. There is some recent renewed energy and
> know how being put in addind that feature. Maybe you can help by
> testing the  proposed changes with your use case and giving
> feedback?
>
> Regards,
>
> --
> Ramiro Morales
>
> 1. https://code.djangoproject.com/ticket/6148
>
> --
> 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: extra files in startproject

2012-04-13 Thread Carl Meyer 
Hi Alex,

On 04/12/2012 10:49 PM, Alex Ogier wrote:
> The problem is that not everyone uses package managers. A reasonable
> way to track django trunk for example is to periodically pull and run
> "setup.py install" which is in most cases approximately idempotent. I
> have seen setup.py's that use remove_tree as part of a "clean" command
> to allow someone to run "setup.py clean && setup.py install" to obtain
> a pristine distribution idempotently, which I think is a good idea.
> The alternative is to have everyone remember to "rm -rf" their
> site-packages django every time they run setup.py install which is a
> bit unsavory in my opinion.

I do agree that asking newer users to go digging in site-packages with
"rm -rf" is sub-optimal. I think the first-line answer is to discourage
newer users (and anyone, really) from installing Django using "python
setup.py install", so they'll never have to. As a second-line answer,
I'm open to the idea of "python setup.py clean" as an alternative to
manual rm -rf in site-packages, if you can provide a reliable
implementation of it as a patch attached to #18115 (and no other core
developer vetoes the idea; James Bennett in particular has traditionally
been the guardian of Django's setup.py).

> The "real" solution to this problem is to stop treating the existence
> of files as implicit indication of their inclusion in Django. 

This is requesting a flat-out impossibility, since "existence of files
implies their inclusion" is simply *how Python module imports work*. If
a .py file exists somewhere under django/ in a directory with an
__init__.py, it can be imported as part of Django.

> would mean listing somewhere the files from
> django/conf/project_template/ that should be included, which isn't
> very DRY, but is the only 100% solution I think.

I think this is now the fourth or fifth time it's been pointed out that
the problem is not limited to startproject (and you yourself
demonstrated that with your own simplejson example!), so I'm a bit
mystified how you can still refer to this as a "100% solution."

> My recommendation is to make "setup.py clean" do everything possible
> to ensure idempotent installation across any version, document that,
> and call it a day. Yes, Django can't make up for people who circumvent
> their package manager, but we can make it a lot easier to fix than
> sending newbies off into their system libraries armed with superuser
> permissions and "rm -rf".

Agreed.

Carl



signature.asc
Description: OpenPGP digital signature

Re: extra files in startproject

2012-04-13 Thread Daniel Sokolowski 
People won’t always read all the docs – it’s a fact – so sooner or later some 
other new comer will experience this issue complain, gave up and worse even 
blog his/hers negative experience. We do want the newbie experience to be as 
painless as possible which means popularity and growth of the framework - and 
ultimately continuation of our paying jobs.

This thread was started by a newbie to the framework, putting aside the 
confrontational tone it stated some valid concerns from a beginners perspective 
– a very important perspective. 

I’ve been using django for a long time and had no idea about this ‘distutils’ 
caveat; I do not understand or know how django installs setup process works but 
am up for some kind of a warning/error directly to the console.

Thank you for reading my opinion.

Daniel
From: Florian Apolloner 
Sent: Friday, April 13, 2012 2:15 AM
To: django-developers@googlegroups.com 
Subject: Re: extra files in startproject



On Friday, April 13, 2012 6:49:32 AM UTC+2, Alex Ogier wrote: 
  I have seen setup.py's that use remove_tree as part of a "clean" command
  to allow someone to run "setup.py clean && setup.py install" to obtain
  a pristine distribution idempotently, which I think is a good idea.


No, they should work on fixing distutils instead of creating solutions which 
probably could break even worse.
 

  The alternative is to have everyone remember to "rm -rf" their
  site-packages django every time they run setup.py install which is a
  bit unsavory in my opinion.

Or just tell them to use either pip even for development installs or just set 
their PYTHONPATH.
 

  If someone has managed to get extra files in their site-packages,
  because at any point they followed a tutorial on how to build from
  source, then their django installation is basically caput until they
  manually "rm -rf" a deep library path. One option is to document this
  and explain what to do

You made me lol, that approach is documented in the install guide: 
https://docs.djangoproject.com/en/dev/intro/install/#remove-any-old-versions-of-django
 -- If people would actually read the docs this issue wouldn't exist. FWIW the 
docs also mention to symlink a dev checkout and don't tell you to run setup.py
 

  That would mean listing somewhere the files from
  django/conf/project_template/ that should be included, which isn't
  very DRY, but is the only 100% solution I think.

Given that the documentation shows how to do it properly I don't see any point. 
Especially since this problem isn't related to the project_template alone -- 
that's just where it's most visible.

 
  So, that should give you some idea of the perils of not cleaning your
  output directories (or in this case, input directory).

We are aware of those, and fwiw: If you use git and switch branches it's up to 
you to know how python works and how git clean works, or do you want to suggest 
that django should rm al pyc files on startup?!
 
  My recommendation is to make "setup.py clean" do everything possible
  to ensure idempotent installation across any version, document that,
  and call it a day. 

What's wrong with the current documented approach? (Aside from the fact that 
people don't read it, but then again they won't read the setup.py clean 
either). 

Regards,
Florian

-- 
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/-/SbdWA7plRx4J.
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: extra files in startproject

2012-04-13 Thread Carl Meyer 
On 04/13/2012 08:30 AM, Daniel Sokolowski wrote:
> People won’t always read all the docs – it’s a fact – so sooner or later
> some other new comer will experience this issue complain, gave up and
> worse even blog his/hers negative experience. We do want the newbie
> experience to be as painless as possible which means popularity and
> growth of the framework - and ultimately continuation of our paying jobs.
>  
> This thread was started by a newbie to the framework, putting aside the
> confrontational tone it stated some valid concerns from a beginners
> perspective – a very important perspective.
>  
> I’ve been using django for a long time and had no idea about this
> ‘distutils’ caveat; I do not understand or know how django installs
> setup process works but am up for some kind of a warning/error directly
> to the console.

Thanks Daniel. I'm experimenting right now with a patch to setup.py that
would print a loud warning to console if it detects an existing django/
directory in the target site-packages.

Carl



signature.asc
Description: OpenPGP digital signature

Re: extra files in startproject

2012-04-13 Thread Daniel Sokolowski 

You sir are Epic!

-Original Message- 
From: Carl Meyer 
Sent: Friday, April 13, 2012 10:33 AM 
To: django-developers@googlegroups.com 
Subject: Re: extra files in startproject 


--
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: extra files in startproject

2012-04-13 Thread Jan Schotsmans 
Tbh, you can not go cater to this type of new users, that start badmouthing
the project right out the gate, with the first hint of trouble, either
becoming insulting, out right, on the developer list, or doing as you put
in your example, posting bad things on their blogs.

If Jason had sent a mail to the developers list stating, "this is the
problem I'm having, this is my installation, any idea's?", then we wouldn't
have had 10 people defend Django before one came up with "this may be a
longshot to be confirmed with further system information, but this seems to
be a problem that isn't related to Django itself, but to an unclean
installation environment with full or partial, duplicate Django
installations."

I did respond to him to post his installation base and details about the
system he is using, and so have others, but he hasn't responded since, even
though there has been quite a decent discussion going about the source of
the problem and a possible solution to protect installations against it
happening, even though it isn't really Django's fault that package
management systems cause the problem, nor is Django in the power to fix
"ALL" package management systems that can cause this to happen and most
certainly isn't able to protect against this behavior entirely, in case a
manual/custom installation is done.

Yes, you can make it as easy as as humanly possible for new users, but no,
you shouldn't have to go out of your way to cater to users that act like
this.


2012/4/13 Daniel Sokolowski 

>   People won’t always read all the docs – it’s a fact – so sooner or
> later some other new comer will experience this issue complain, gave up and
> worse even blog his/hers negative experience. We do want the newbie
> experience to be as painless as possible which means popularity and growth
> of the framework - and ultimately continuation of our paying jobs.
>
> This thread was started by a newbie to the framework, putting aside the
> confrontational tone it stated some valid concerns from a beginners
> perspective – a very important perspective.
>
> I’ve been using django for a long time and had no idea about this
> ‘distutils’ caveat; I do not understand or know how django installs setup
> process works but am up for some kind of a warning/error directly to the
> console.
>
> Thank you for reading my opinion.
>
> Daniel
>   *From:* Florian Apolloner 
> *Sent:* Friday, April 13, 2012 2:15 AM
> *To:* django-developers@googlegroups.com
> *Subject:* Re: extra files in startproject
>
>
>
> On Friday, April 13, 2012 6:49:32 AM UTC+2, Alex Ogier wrote:
>>
>> I have seen setup.py's that use remove_tree as part of a "clean" command
>> to allow someone to run "setup.py clean && setup.py install" to obtain
>> a pristine distribution idempotently, which I think is a good idea.
>>
> No, they should work on fixing distutils instead of creating solutions
> which probably could break even worse.
>
>
>> The alternative is to have everyone remember to "rm -rf" their
>> site-packages django every time they run setup.py install which is a
>> bit unsavory in my opinion.
>>
> Or just tell them to use either pip even for development installs or just
> set their PYTHONPATH.
>
>
>> If someone has managed to get extra files in their site-packages,
>> because at any point they followed a tutorial on how to build from
>> source, then their django installation is basically caput until they
>> manually "rm -rf" a deep library path. One option is to document this
>> and explain what to do
>>
> You made me lol, that approach is documented in the install guide:
> https://docs.djangoproject.com/en/dev/intro/install/#remove-any-old-versions-of-django--
>  If people would actually read the docs this issue wouldn't exist. FWIW
> the docs also mention to symlink a dev checkout and don't tell you to run
> setup.py
>
>
>> That would mean listing somewhere the files from
>>
>> django/conf/project_template/ that should be included, which isn't
>> very DRY, but is the only 100% solution I think.
>>
>> Given that the documentation shows how to do it properly I don't see any
> point. Especially since this problem isn't related to the project_template
> alone -- that's just where it's most visible.
>
>
>
>> So, that should give you some idea of the perils of not cleaning your
>> output directories (or in this case, input directory).
>>
> We are aware of those, and fwiw: If you use git and switch branches it's
> up to you to know how python works and how git clean works, or do you want
> to suggest that django should rm al pyc files on startup?!
>
>
>> My recommendation is to make "setup.py clean" do everything possible
>> to ensure idempotent installation across any version, document that,
>> and call it a day.
>>
> What's wrong with the current documented approach? (Aside from the fact
> that people don't read it, but then again they won't read the setup.py
> clean either).
>
> Regards,
> Florian
> --
> You received this message because you are subscribe

Django 1.4: session_key is None when calling a view with the test client

2012-04-13 Thread Kai Diefenbach 

Hi,

when I call a view with the test client (django.test.client.Client) 
like, for instance, so:


	self.client.post(reverse('lfs_login'), {'action': 'register', 'email': 
't...@test.com', 'password_1': 'password', 'password_2': 'password'})


with Django 1.3.1 the session_key of session is set:

(Pdb) request.session.session_key
'5ec9fd72978ec4ec4186fe7af59b905f'  

with Django 1.4 it is None:

(Pdb) request.session.session_key
(Pdb)

which breaks a lot of of my tests.

Now my questions:  Is this by intention? Can I get around that? Has 
this any meaning for the application in production?


Thanks
Kai







--
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: Django 1.4: session_key is None when calling a view with the test client

2012-04-13 Thread Aymeric Augustin 
On 13 avr. 2012, at 18:42, Kai Diefenbach wrote:
> Now my questions:  Is this by intention? Can I get around that? Has this any 
> meaning for the application in production?


Hello Kai,

This is most likely a consequence of r17155 [1].

I'd like to understand if it's possible to trigger a regression by using only 
the public APIs. Currently, the only reference to session_key in the docs is 
here [2]. It shows that you can use session_key after the session is saved (and 
nothing else).

Could you clarify how you use session_key (and maybe why you need to access it 
directly)?

Thanks,

-- 
Aymeric.

[1] https://code.djangoproject.com/changeset/17155
[2] 
https://docs.djangoproject.com/en/1.4/topics/http/sessions/#using-sessions-out-of-views

-- 
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: extra files in startproject

2012-04-13 Thread Carl Meyer 
On 04/13/2012 08:33 AM, Carl Meyer wrote:
> Thanks Daniel. I'm experimenting right now with a patch to setup.py that
> would print a loud warning to console if it detects an existing django/
> directory in the target site-packages.

I've filed a pull request (https://github.com/django/django/pull/136)
with this setup.py modification and some documentation edits (and also
linked it from #18115, of course). Review and comment welcome!

Carl



signature.asc
Description: OpenPGP digital signature

Re: django.contrib.sites.managers.CurrentSiteManager spanning more than one model

2012-04-13 Thread Rory Geoghegan 
Hi,

I have a patch for this on pastebin here: http://pastebin.com/u5g67iPP

Please tell me if it is worth integrating,
--Rory Geoghegan

On Thu, Apr 5, 2012 at 3:53 PM, Rory Geoghegan <
rory.geoghe...@ecometrica.com> wrote:

> The only hard part is modifying the _validate_field_name method.
> get_query_set uses the regular filtering mechanism, so it actually works
> out of the box with the __ field spanning. I will provided a patch (once I
> clean up the code), then you can see that it is quite a small fix and may
> be worth integrating.
>
> --Rory Geoghegan
>
>
> On Thu, Apr 5, 2012 at 3:46 PM, Adrian Holovaty wrote:
>
>> On Thu, Apr 5, 2012 at 11:46 AM, Rory Geoghegan
>>  wrote:
>> > We currently have that code written. Is it worth turning that into a
>> > patch for contrib.sites, with unit tests et al, and pushing upstream
>> > into django? Should I fill out a bug?
>>
>> I don't think this added complexity/functionality is worth adding to
>> the framework. It's easy enough to make your own custom manager that
>> does the same thing. If you'd like to share it with others, toss it
>> online somewhere.
>>
>> Adrian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

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

Re: auth.user refactor: the profile aproach

2012-04-13 Thread Hanne Moa 
On 3 April 2012 04:56, Alex Ogier  wrote:
> I get that Django's core is very accustomed to the relational database mode
> of thinking: "If a User might own a Twitter handle, then let's create a
> table of twitter handles in the twitter-auth app, and foreign key back to
> the default User model". It's really not that bad to go the other way for a
> moment, and say "If a User might own a Twitter handle, then let's add a
> twitter_handle field to Users."

What if the User owns more than one Twitter handle? I use six
different email-addresses regularly and several openids. The auth
backends I write use Foreign Key and not OneToOneKey back to User for
a reason.

> The reason being that the latter is *so much
> more flexible*. You can simulate the first with the second, but not vice
> versa. Twitter-auth might not need its own table (in fact, it shouldn't need
> its own table). If you really wanted to, you could make one, and foreign-key
> *from* the user model which gives you everything the first solution has,
> with no need to created magical .prof1, .prof2 proxy attributes. You could
> even let users sign in with multiple handles with a many-to-many. Heck,
> maybe your blog posts have their own twitter credentials, I don't know.

This would *only* be flexible with  a many-to-many. Then you wouldn't
have to ALTER TABLE to add an auth-backend.


HM

-- 
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: Django 1.4: session_key is None when calling a view with the test client

2012-04-13 Thread Kai Diefenbach 

Hi Aymeric,

On 2012-04-13 17:11:48 +, Aymeric Augustin said:


On 13 avr. 2012, at 18:42, Kai Diefenbach wrote:
Now my questions:  Is this by intention? Can I get around that? Has 
this any meaning for the application in production?


This is most likely a consequence of r17155 [1].


Okay, I see.

I'd like to understand if it's possible to trigger a regression by 
using only the public APIs. Currently, the only reference to 
session_key in the docs is here [2]. It shows that you can use 
session_key after the session is saved (and nothing else).


Could you clarify how you use session_key (and maybe why you need to 
access it directly)?


I'm using it to relate different models to a session (storing it in a 
char field). This code is old and I can't remember why I storing the 
session_key instead of using a foreign key to the session instance. 
Actually it seems wrong to me, now.


I think, I will clean up my code first and see what will happen then.

Thanks
Kai


--
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: extra files in startproject

2012-04-13 Thread Daniel Sokolowski 

Hi Carl,

Looks fine to me, and I think throwing the warning at the end is indeed a 
good idea.


-Original Message- 
From: Carl Meyer

Sent: Friday, April 13, 2012 2:20 PM
To: django-developers@googlegroups.com
Subject: Re: extra files in startproject

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

Re: GSoC 2012: Security Enhancements

2012-04-13 Thread Luke Plant 
Hi Rohan,

Sorry for the slow reply on this one, I've had a busy time recently.
Please see my comments on some parts of this proposal.

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

I'm very cautious about making the logic here more complex. It can be
done, but every additional code path increases the possibility of a
security hole. At the moment, it seems that few browsers send the
'Origin' header for normal HTML requests. (Recent versions of Chrome,
Firefox and Opera do not, I don't know about IE).

> I would also suggest making CSRF cookie as http only. There doesn't 
> seem a reason currently why the cookies would be needed to be
> accessed in browser.

Currently the CSRF cookie has to be accessible in browser if the AJAX
workaround in our docs is to work at all:

https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax



> ###Less restrictive secure requests
> 
> The current CSRF system is pretty much secure as it is. But CSRF 
> protection poses too much restriction to https. It says no to all
> the request, without honouring any tokens. It kind of has to, thanks
> to the way browsers allow cookie access. A cookie accessible through 
> subdomains mean that any subdomain secure or insecure can set the
> CSRF token, which could be really serious for the site security. To
> get around this, currently one has to comple

Re: Revised revised form rendering

2012-04-13 Thread Carl Meyer 
Hi Mikhail,

On 03/29/2012 01:31 PM, Mikhail Korobov wrote:
> GSoC'11 Gregor Müllegger's and Carl Meyer's project (Revised form
> rendering) seems to get stuck because of performance issues. 
> 
> Question 1. Am I understand this correctly and the limiting factor is
> the template rendering speed?
> Question 2. Is it true that templates are not going to become faster
> anytime soon? I made this conslusion based on Armin Ronacher's GSoC'11
> (Template Engine Compilation) results.

Yes, this is the situation.

> If answers for (1) and (2) are 'yes' then maybe we can explore
> non-template-based solutions that make form rendering easier to
> customize. Rendering simple  tag with dedicated django template
> is pure and clean approach but if it has critical performance penalty
> then I personaly totally ok with rendering 'input' tag in python if it
> is still customizable.
> 
> There is a working app (
> https://bitbucket.org/kmike/django-widget-tweaks ) that can customize
> field rendering like this:
[snip]
> What django itself needs to make this app (or similar apps) work better
> is a public Widget and SubWidget API. It should be possible to iterate
> over subwidgets (e.g. select's options or checkboxes or radio buttons or
> parts of multi fields) in consistent way and subwidgets should expose
> the same interface as widgets. Field labels also should be widgets.

I'm certainly open to looking at patches to refactor the widget API for
better consistency; this proposal is still a bit vague to comment on
specifically. One issue I see immediatelyis that widgets play a dual
role: they are responsible both for rendering an HTML input element, and
they are responsible for extracting their data from incoming raw form
data and massaging it as necessary for a form field to handle.

It seems to me, based on your proposal that "sub-widgets" and field
labels should "be widgets", that you are focused entirely on the former
role, rather than the latter, since neither sub-widgets nor field labels
would have any role in extracting and parsing form data. Which makes me
think that if you go this route with a refactor you may want to
introduce a clearer conceptual separation between those two
roles/interfaces.

> I haven't measured the speed of django-widget-tweaks vs template-based
> widgets vs existing django rendering, but it seems that even if the
> current implementation is slow (I don't know if it is slow or fast) with
> some core support it can be made fast.
> 
> By the way, there was a similar proposal several years
> ago: 
> https://groups.google.com/d/topic/django-developers/XzaUuKGfuaE/discussion
>  
> Does all this stuff has a chance to go somewhere (of course if answers
> to questions (1) and (2) are 'yes') or template-based widget rendering
> is a true way and we should wait until computers become faster or django
> templates become faster or python become faster?

I still hope that fully template-based form rendering can get into
Django in the future, though at this point I don't have a clear vision
of the path to get there. But I'm not interested in blocking
improvements in the existing system in the meantime.

Carl



signature.asc
Description: OpenPGP digital signature

Implementation of Object Permissions

2012-04-13 Thread Moritz S. 
Hi all,

I have been using django for a while and became happy by the time I 
discovered the auth module that supports permission handling. But this 
module turned out to only be able to handle model based permissions. I 
could not imagine django of not having such a basic functionality (in my 
opinion) despite of having so much other great abilities. So I started to 
search for it but eventually figured out that the auth model's code was 
prepared for implementing this but it haven't been done yet.
So I decided to write a patch for this on my own.
Currently I'm writing this patch but there are several design decisions to 
make so I wanted to share this with you and hear your opinions.

First of all: I think the main problem of this implementation is to link 
the objects with the corresponding permissions. With model based 
permissions that's easy because you only have to store a permission once 
with the models ContentType and relate with a ManyToManyField to them and 
that's it. The problem with object based permissions is that every object 
needs to have his own set of permissions and you can't just use ForeignKeys 
or ManyToManyFields from a permission model because in the process of 
creating the permission model (and table) you don't know about the models 
that will provide object permissions therefore you can't refer to them.
So I tried some different implementations.

At first I tried to used dynamic models (e.g. this project makes use of 
them: http://pypi.python.org/pypi/django-object-permissions): The idea is 
to create intermediate models like 'MyModel_ObjectPermissions' that stores 
the object permissions with foreign keys to the model itself, user and 
group.
But this has a huge disadvantage: the use of dynamic models.
In fact thinking as database specialist that is the easiest way of 
connecting the model instances to the permissions but dynamic models are 
very sensitive and kind of hacky in my opinion and I think that does not 
match well with django's ideas.

Then I found out about GenericRelations from the contenttypes framework. So 
you could possibly use a single model called 'ObjectPermissions' or 
something and link users, permissions and instances of all types of models 
and only had to use one GenericRelation. This solution eliminates the 
problem wit the dynamic models because it doesn't even make use of them. 
But the GenericRelations have another not negligible disadvantage: The 
databases behind django don't have native support for them. I thought of 
huge django projects handling thousands and thousands of object 
permissions. I think these GenericRelations wouldn't be such scalable to 
make use of them.

The only solution for me was to find a way to link the (unknown) model 
instances to the permissions in the reversed direction. So not use 
ForeignKeys, etc. in the permission model to refer to the unknown model but 
to refer from the model to the permission itself. That would fix the 
problem of not knowing the models while creating the permission model. So 
in the end I thought of following:
- there is a new model in the auth module called 'ObjectPermission' this 
model has ManyToManyFields to User and Group and a ForeignKey to Permission
- instead of ObjectPermission referring to the model using object 
permissions, a field called 'object_permissions' is added to the 
corresponding models (by use of the class_prepared signal) (dynamically 
adding fields is way better than use completely dynamic models in my 
opinion)
- the object_permissions field is a ManyToManyField, that refers to 
ObjectPermission. In fact, a 'ManyToOneField' would be sufficient but 
django only has one to many fields (the ForeignKeyField) and we can't just 
use this in the reversed direction, as I mentioned above
This picture illustrates the relations:




Furthermore I thought of slightly modifying the auth module (apart from the 
ObjectPermission model) in the following way:
- when the auth app is initialized a function is registered to listen to 
the class_prepared signal. This function adds the object_permissions field 
to each model, that has the Meta.object_permissions set to True (for this 
to work, this meta attribute has to be set in django.db.models.options)
- the User model gets the methods grant_perm and revoke_perm that takes the 
permission and as optional argument the object in order to simplify the 
process of handling permissions
- in the ModelBackend the methods has_perm, etc. have to be modified to be 
able to handle function calls with given objects (obviously)

So that was the technical part.

Now I want you to give feedback if this implementation is viable and maybe 
sometimes may get into django.


Thanks,
Moritz

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
h

Re: Implementation of Object Permissions

2012-04-13 Thread Mike Axiak 
How does it compare to the solutions that already exist listed here?

 http://djangopackages.com/grids/g/perms/

-Mike

On Fri, Apr 13, 2012 at 7:56 PM, Moritz S. wrote:

> Hi all,
>
> I have been using django for a while and became happy by the time I
> discovered the auth module that supports permission handling. But this
> module turned out to only be able to handle model based permissions. I
> could not imagine django of not having such a basic functionality (in my
> opinion) despite of having so much other great abilities. So I started to
> search for it but eventually figured out that the auth model's code was
> prepared for implementing this but it haven't been done yet.
> So I decided to write a patch for this on my own.
> Currently I'm writing this patch but there are several design decisions to
> make so I wanted to share this with you and hear your opinions.
>
> First of all: I think the main problem of this implementation is to link
> the objects with the corresponding permissions. With model based
> permissions that's easy because you only have to store a permission once
> with the models ContentType and relate with a ManyToManyField to them and
> that's it. The problem with object based permissions is that every object
> needs to have his own set of permissions and you can't just use ForeignKeys
> or ManyToManyFields from a permission model because in the process of
> creating the permission model (and table) you don't know about the models
> that will provide object permissions therefore you can't refer to them.
> So I tried some different implementations.
>
> At first I tried to used dynamic models (e.g. this project makes use of
> them: http://pypi.python.org/pypi/django-object-permissions): The idea is
> to create intermediate models like 'MyModel_ObjectPermissions' that stores
> the object permissions with foreign keys to the model itself, user and
> group.
> But this has a huge disadvantage: the use of dynamic models.
> In fact thinking as database specialist that is the easiest way of
> connecting the model instances to the permissions but dynamic models are
> very sensitive and kind of hacky in my opinion and I think that does not
> match well with django's ideas.
>
> Then I found out about GenericRelations from the contenttypes framework.
> So you could possibly use a single model called 'ObjectPermissions' or
> something and link users, permissions and instances of all types of models
> and only had to use one GenericRelation. This solution eliminates the
> problem wit the dynamic models because it doesn't even make use of them.
> But the GenericRelations have another not negligible disadvantage: The
> databases behind django don't have native support for them. I thought of
> huge django projects handling thousands and thousands of object
> permissions. I think these GenericRelations wouldn't be such scalable to
> make use of them.
>
> The only solution for me was to find a way to link the (unknown) model
> instances to the permissions in the reversed direction. So not use
> ForeignKeys, etc. in the permission model to refer to the unknown model but
> to refer from the model to the permission itself. That would fix the
> problem of not knowing the models while creating the permission model. So
> in the end I thought of following:
> - there is a new model in the auth module called 'ObjectPermission' this
> model has ManyToManyFields to User and Group and a ForeignKey to Permission
> - instead of ObjectPermission referring to the model using object
> permissions, a field called 'object_permissions' is added to the
> corresponding models (by use of the class_prepared signal) (dynamically
> adding fields is way better than use completely dynamic models in my
> opinion)
> - the object_permissions field is a ManyToManyField, that refers to
> ObjectPermission. In fact, a 'ManyToOneField' would be sufficient but
> django only has one to many fields (the ForeignKeyField) and we can't just
> use this in the reversed direction, as I mentioned above
> This picture illustrates the relations:
>
>
> 
>
>
> Furthermore I thought of slightly modifying the auth module (apart from
> the ObjectPermission model) in the following way:
> - when the auth app is initialized a function is registered to listen to
> the class_prepared signal. This function adds the object_permissions field
> to each model, that has the Meta.object_permissions set to True (for this
> to work, this meta attribute has to be set in django.db.models.options)
> - the User model gets the methods grant_perm and revoke_perm that takes
> the permission and as optional argument the object in order to simplify the
> process of handling permissions
> - in the ModelBackend the methods has_perm, etc. have to be modified to be
> able to handle function calls with given objects (obviously)
>
> So that was the technical part.

Re: Implementation of Object Permissions

2012-04-13 Thread Moritz S. 
I checked the four most used solutions.
The first three ones use GenericKeys (in my opinion not the ideal solution 
as I described above) and the fourth one as far as I can see does not use 
the auth permission backend but does permission handling on his own.

-Moritz

Am Samstag, 14. April 2012 02:14:35 UTC+2 schrieb Mike Axiak:
>
> How does it compare to the solutions that already exist listed here?
>
>  http://djangopackages.com/grids/g/perms/
>
> -Mike
>
> On Fri, Apr 13, 2012 at 7:56 PM, Moritz S. 
> wrote:
>
>> Hi all,
>>
>> I have been using django for a while and became happy by the time I 
>> discovered the auth module that supports permission handling. But this 
>> module turned out to only be able to handle model based permissions. I 
>> could not imagine django of not having such a basic functionality (in my 
>> opinion) despite of having so much other great abilities. So I started to 
>> search for it but eventually figured out that the auth model's code was 
>> prepared for implementing this but it haven't been done yet.
>> So I decided to write a patch for this on my own.
>> Currently I'm writing this patch but there are several design decisions 
>> to make so I wanted to share this with you and hear your opinions.
>>
>> First of all: I think the main problem of this implementation is to link 
>> the objects with the corresponding permissions. With model based 
>> permissions that's easy because you only have to store a permission once 
>> with the models ContentType and relate with a ManyToManyField to them and 
>> that's it. The problem with object based permissions is that every object 
>> needs to have his own set of permissions and you can't just use ForeignKeys 
>> or ManyToManyFields from a permission model because in the process of 
>> creating the permission model (and table) you don't know about the models 
>> that will provide object permissions therefore you can't refer to them.
>> So I tried some different implementations.
>>
>> At first I tried to used dynamic models (e.g. this project makes use of 
>> them: http://pypi.python.org/pypi/django-object-permissions): The idea 
>> is to create intermediate models like 'MyModel_ObjectPermissions' that 
>> stores the object permissions with foreign keys to the model itself, user 
>> and group.
>> But this has a huge disadvantage: the use of dynamic models.
>> In fact thinking as database specialist that is the easiest way of 
>> connecting the model instances to the permissions but dynamic models are 
>> very sensitive and kind of hacky in my opinion and I think that does not 
>> match well with django's ideas.
>>
>> Then I found out about GenericRelations from the contenttypes framework. 
>> So you could possibly use a single model called 'ObjectPermissions' or 
>> something and link users, permissions and instances of all types of models 
>> and only had to use one GenericRelation. This solution eliminates the 
>> problem wit the dynamic models because it doesn't even make use of them. 
>> But the GenericRelations have another not negligible disadvantage: The 
>> databases behind django don't have native support for them. I thought of 
>> huge django projects handling thousands and thousands of object 
>> permissions. I think these GenericRelations wouldn't be such scalable to 
>> make use of them.
>>
>> The only solution for me was to find a way to link the (unknown) model 
>> instances to the permissions in the reversed direction. So not use 
>> ForeignKeys, etc. in the permission model to refer to the unknown model but 
>> to refer from the model to the permission itself. That would fix the 
>> problem of not knowing the models while creating the permission model. So 
>> in the end I thought of following:
>> - there is a new model in the auth module called 'ObjectPermission' this 
>> model has ManyToManyFields to User and Group and a ForeignKey to Permission
>> - instead of ObjectPermission referring to the model using object 
>> permissions, a field called 'object_permissions' is added to the 
>> corresponding models (by use of the class_prepared signal) (dynamically 
>> adding fields is way better than use completely dynamic models in my 
>> opinion)
>> - the object_permissions field is a ManyToManyField, that refers to 
>> ObjectPermission. In fact, a 'ManyToOneField' would be sufficient but 
>> django only has one to many fields (the ForeignKeyField) and we can't just 
>> use this in the reversed direction, as I mentioned above
>> This picture illustrates the relations:
>>
>>
>> 
>>
>>
>> Furthermore I thought of slightly modifying the auth module (apart from 
>> the ObjectPermission model) in the following way:
>> - when the auth app is initialized a function is registered to listen to 
>> the class_prepared signal. This function adds the object_permissions field 
>> to each model, that has the Meta.object_

Change to order of Session creation in 1.4?

2012-04-13 Thread Justin Holmes 
I have a signal hook set on user_login.  I use this in order to
get_or_create a SessionInfo object, which I use to keep track of data
about users who may login from more than one computer at the same
time.

in 1.3, the Session object for the login that is taking place had
already been created at the time of the hook execution.

However, In 1.4, Session.objects.all() yields empty during the hook execution.

Am I seeing things?  Or did this change?

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