Re: Possible bug in messages framework?

[Luke Plant]

On Saturday 23 January 2010 14:29:55 Tobias McNulty wrote:

>  That said, I have reservations about any kind
>  of across-the-board encoding because it makes it necessary,
>  when/if the cookies need to be read by JavaScript, to implement
>  that same decode/encode on the client side.

We actually already encode many values - the SimpleCookie module does 
it for us:

>>> c = Cookie.SimpleCookie()
>>> c['test'] = 'He said "Voilà!"'
>>> c.output()
'Set-Cookie: test="He said \\"Voil\\303\\240!\\""'

Robust Javascript that uses cookies with any 'funny' characters 
already needs to be able to cope with these octal sequences, with 
backslashes for quotation marks, and the fact that quotation marks are 
added for any values with special chars (including space, comma and 
semi-colon). 

So, one method that would minimize damage would be to extend the 
existing octal escape mechanism to semi-colons and commas.  That way, 
javascript only needs to implement one unquoting mechanism.  I've 
implemented this and added the patch to #12470.

This still has the disadvantage that if people are storing comma or 
semi-colon separated lists in a cookie, and are reading that cookie 
from javascript, and haven't fully implemented the reverse quoting for 
our existing cookie quoting, then they will have problems.

Personally, I imagine that very few Django projects are storing 
complex values in cookies in Django - most people would just put stuff 
in the session, or do some AJAX these days.

If people *are* storing complex values, I imagine that many will be 
using base64 or something (it's very easy with builtin javascript 
functions atob, btoa).

So, currently I'm inclined towards committing the patch I just added 
to #12470, and adding a note in 'backwards incompatibilities'.

Thoughts?

Luke

-- 
The early bird gets the worm, but the second mouse gets the cheese. 
 --Steven Wright

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

I just thought of another way this might be possible: signals.

Just add them to the anonymous user functions.
The signal would get passed a variable holding the currently returned
result, and then returns it.
That way you can hook into it and modify the result without breaking
the current behaviour.


On Jan 20, 8:49 am, Harro  wrote:
> class User(models.Model):
>     permissions = models.ManyToMany('Permission',
> through='UserPermission')
>
> class UserPermission(models.Model):
>      user = models.ForeignKey('User', blank=True, null=True)
>      permission = models.ForeignKey('Permission')
>
> class AnonymousUser(models.Model)
>
>     @property
>     def permissions(self):
>        return UserPermission.objects.filter(user__isnull=True)
>
> On Jan 19, 10:12 pm, Luke Plant  wrote:
>
> > On Tuesday 19 January 2010 16:23:32 Harro wrote:
>
> > > And I guess making it truely awesome would require permissions for
> > > anonymoususers in the default backend too. :(
>
> > > If I have timeI'll see what I can come up with.
>
> > Ticket #9444 [1] is about that, and it had a lot of opposition.
>
> > It is hard or very hacky for the provided auth backend to support
> > object-level permissions for anonymous users, because there is no
> > obvious place to store permissions.  But making it *possible* for
> > custom auth backends to do this is a different matter, and is all we
> > should be aiming for I think.
>
> > Now for some out-loud thinking about the consequences of this patch:
>
> > Once you make it possible, it is likely that the authors of re-usable
> > apps will want to depend on this capability.  That means that writing
> > custom auth backends would now be much more common. The auth backend
> > already covers both authorization and authentication, but if the
> > authors of re-usable apps are encouraged to depend on it to handle
> > authorization even for anonymous users, then it will be much more
> > commonly required.
>
> > I don't see this as necessarily a problem, it's just a shift in
> > direction.  The more I think about it, the more it seems that
> > authorization questions really need to be decided on a per-site basis,
> > and this mechanism is a good place to do it. (Some people object to
> > mixing authorization and authentication, but it's a bit too late to
> > fix that, and in practice full decoupling is tricky and overly-
> > complex).
>
> > I've thought through some other scenarios, such as having multiple
> > types of login (on one site I use 'User' in the normal way for people
> > with access to the admin, and a completely separate 'Member' model for
> > completely different type of access), and I can see ways for all of
> > these to work, although you might have to supply a custom
> > AuthenticationMiddleware, and your own User objects which have the
> > same interface as the supplied one.
>
> > The other consequence of app authors depending on this is that apps
> > might become more restrictive by default, and harder to "open up".  
> > Whereas before you would allow an anonymous user to, say, write a
> > comment, or had a single setting to control it, now you will just
> > delegate to the auth backend, which by default has no permissions for
> > anonymous users.  Again, I don't see this as particularly bad - the
> > amount of spam these days means it's probably helpful to have things
> > locked down by default.
>
> > Regards,
>
> > Luke
>
> > [1]http://code.djangoproject.com/ticket/9444
>
> > --
> > "Pretension: The downside of being better than everyone else is
> > that people tend to assume you're pretentious." (despair.com)
>
> > Luke Plant ||http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Feedback: Syndication feed views

[Ben Firshman]

Is it too late to sneak this in in as a minor feature?

I have some time now, so I can write up some more documentation if it's needed.

Ben

On 4 Jan 2010, at 13:07, Ben Firshman wrote:

> Is there any more documentation that I should write before the feature  
> freeze tomorrow?
> 
> Thanks,
> 
> Ben
> 
> On 22 Dec 2009, at 00:39, Ben Firshman wrote:
> 
>> 
>> On 21 Dec 2009, at 20:06, Luke Plant wrote:
 I've documented it in some detail in the release notes. Is this
 painstaking enough?
>>> 
>>> Unless I'm missing something, it's not nearly there (but some of this
>>> may be the 'formal stuff' that Jacob doesn't mind being missing for
>>> now).
>>> 
>>> First, views.Feed.get_object() takes different arguments to
>>> feeds.Feed.get_object().  This is pretty confusing, and really needs
>>> to be *much* clearer in the documentation (not just the release
>>> notes). The same goes for the get_feed() method.
>> 
>> You're right. I've now given it a little versionchanged directive in  
>> the main documentation, but perhaps this needs to be clearer. Note  
>> that get_feed() isn't documented at all, but all the same, I've made  
>> it clear it has changed in the release notes.
>> 
>>> 
>>> The release notes imply that I can just switch from subclassing
>>> feeds.Feed to view.Feed and change get_object(), and it will all  
>>> work.
>>> I can't see how that is possible:
>>> 
>>> - I might have code that calls the constructor of feeds.Feed (or a
>>> subclass) directly.  But views.Feed has a different signature
>>> altogether, and feeds.Feed.__init__() does a bit of work that my own
>>> code is going to have to do once feeds.Feed disappears.  Obviously
>>> that code is doing something that will have to be done differently
>>> with views.Feed.  But how exactly?
>>> 
>>> - I might have code that calls the get_feed() method of feeds.Feed
>>> (or a subclass) directly.  That method does extra work compared to
>>> views.Feed.get_feed().  When feeds.Feed goes away, what does my code
>>> need to be changed to?
>>> 
>>> What I'm looking for is *step by step* instructions on how to update
>>> my code, and a list of *all* the differences between views.Feed and
>>> feeds.Feed, since the former is supposed to be the replacement for  
>>> the
>>> latter.  I shouldn't have to look at *any* of the code or previous
>>> documentation to work out what has changed.  *All* the hard work
>>> should have been done for me.  This is about maintenance programmers,
>>> who have been given a promise of backwards compatibility, who just
>>> want their application to carry on working.
>> 
>> I understand. I've added additional details in the release notes,  
>> but do we need step by step instructions on how to upgrade  
>> undocumented APIs? As far as the documented API is concerned, very  
>> little has changed. Under the hood though, Feed classes have changed  
>> significantly. It would require reams of documentation to take into  
>> account all the different ways people might be hacking with Feed  
>> classes.
>> 
>>> 
>>> I'm insisting on this, because until we see it, it's very difficult  
>>> to
>>> work out how "backwards compatible" this really is, and whether we
>>> should deprecate feeds.Feed at all.  Jacob was happy for this to go  
>>> in
>>> without the formal stuff of documenting all this, so I guess we can
>>> punt the decision about whether to deprecate feeds.Feed or not, but  
>>> we
>>> do need those docs at some point so we can see the implications of
>>> deprecating feeds.Feed.
>> 
>> I've gone through my changes and documented exactly what has changed  
>> as far as the user is concerned. The old API should be completely  
>> backwards compatible; the new Feed view certainly isn't.
>> 
>>> 
>>> So for now, maybe just update the release notes so they don't say  
>>> that
>>> the new LatestEntries class is identical to before, or a caveat like
>>> "if you are only using the high level feed framework (the feed()
>>> view)" or something.
>>> 
>> 
>> I've gone a little further than that in the patch I've just put on  
>> the ticket (1), but this probably needs documenting in more detail.
>> 
>> Thanks,
>> 
>> Ben
>> 
>> (1) 
>> http://code.djangoproject.com/attachment/ticket/12403/syndication-views-4.diff
>>  
>> (Why aren't my diffs showing? Are they too large for trac?)
>> 
>> --
>> 
>> 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-develop...@googlegroups.com.
> To unsubscribe from this group, send 

Feedback requested: One last time with multi-db

[Russell Keith-Magee]

Hi all,

This is a call for comments on what I hope will be the last two
modifications to multi-db support for 1.2.

Barring negative feedback, I aim to commit this at the start of next
week, just in time for the beta-1 feature freeze.

Change 1: Identifying which models are on which database
--

To date, we have avoided any housekeeping over which models are
available on which database. We have made the assumption that all
models are available everywhere, and left it up to the user to
manually configure their database if this isn't the case.

This has a couple of consequences:

 * If you want to restrict some models to certain databases, you can't
use syncdb - you need to take the manual route. This isn't a
show-stopper, but it is a lot more complication than Django usually
requires.

 * It is impossible to do completely generic metaprogramming - you
can't, for example, build an admin interface that only displays the
right models for the right databases, because there isn't an easy way
to determine if a model is available on a given database. Again,
manual configuration is possible here, but similarly complex.

 * The test system must assume that every model is on every database
(since there is no opportunity for manual synchronization). This means
you can't explicitly test behavior that relies on non-availability of
a model on a particular database.

I've opened #12672 to track the issue, and there is a candidate patch
ready for comment. This patch follows an idea originally from Johannes
Dollinger, and refined by Yuri Baburov - that we add a method to the
database routers that can answer whether a specific model is available
on a specific database. This method (allow_syncdb()) follows the same
pattern as allow_relation(); return True if a model should be on a
database, False if it shouldn't, and None if the router has no
opinion. The bucket behavior is to allow all models on all databases,
so there is no change to the current behavior if you don't have
routers installed.

The other benefit of this approach is that we can drop the --exclude
arguments from loaddata and syncdb. Personally, I was never happy with
the fact that we needed to introduce these arguments as part of the
first multi-db patch, but they were a necessary evil caused by the
lack of info about model database assignments. Since the need for
these flags is going away, I've taken the opportunity to remove them.

Code, tests and documentation is in the most recent (v2) patch on
ticket #12672. Comments?

Change 2: Test mirrors
--

The second change involves a change to the test system to handle
multiple database setups. I have introduced a new test setting --
'TEST_MIRROR' -- that redirects a particular database alias to point
at a different connection while in the test environment.

This is required for testing of master/slave setups. The short
explanation is that the temporary databases that the test environment
creates won't be created with any data replication strategy in place,
which will break any tests that expect replication to occur.

A full explanation, including an example is in the documentation
portion of the patch, attached to ticket #12542.

Comments?

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

Django_birth = datetime(1910, 1, 23)

[András Boroska]

>>> (datetime.today()-Django_birth).days/365
>>> 100

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Possible bug in messages framework?

[Tobias McNulty]

On Fri, Jan 22, 2010 at 10:45 PM, Luke Plant  wrote:

> On Saturday 23 January 2010 02:44:39 Luke Plant wrote:
>
> >  BTW, further research shows that we are not really RFC 2109
> >  compliant at all, but then again no-one is.  It seems virtually
> >  everyone (server side and client side) is using 'Netscape style'
> >  cookies with some things adopted from RFC 2109 and RFC 2965,
> >  including 'max-age' and the use of quoted-string, but not the all
> >  important "Version" attribute which turns on RFC 2109 cookies.
> >  Hardly anyone is using Set-Cookie2 from RFC 2965.  So specs of any
> >  kind are fairly meaningless here, it's a matter of what everyone
> >  does.
>
> Actually, to add a bit more:
>
> http://www.ietf.org/mail-archive/web/http-state/current/msg00078.html
> http://codereview.chromium.org/17045
>
> It's all pretty horrific, it pushes me back towards adding a layer of
> quoting to our cookie handling just to try to avoid it all - but a
> robust encoding which definitely avoids all problems.  We should note
> that the presence of semi-colons is more likely to cause problems than
> commas - Internet Explorer splits on semi-colons, irrespective of
> quotation marks.
>

Technically I imagine it is possible to come up with a way to encode all new
cookies in a safe way, but still support "decoding" old-style cookies.  That
said, I have reservations about any kind of across-the-board encoding
because it makes it necessary, when/if the cookies need to be read by
JavaScript, to implement that same decode/encode on the client side.  My
personal preference would be to fix the messages implementation and add a
note to the cookies documentation saying that it's "recommended to encode
cookies to avoid potential browser bugs," and list off a few of those bugs.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #9015 — signal connection decorator

[Brian Rosner]

On Jan 23, 2010, at 6:45 AM, Ulrich Petri wrote:
> Just an idea:
> 
> Wouldn't it be a bit nicer API to have receiver be a method on Signal?
> So you could do:
> 
> @pre_save.receiver(sender=MyModel)
> def my_receiver(sender, **kwargs):
>...
> 

This isn't a bad idea. It does reduce an import and does help make it more 
clear than using connect. I'd be in favor of changing it to this.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #9015 — signal connection decorator

[Ulrich Petri]

Hi,

Am 23.01.2010 um 14:01 schrieb Brian Rosner:


from django.db.models.signals import pre_save
from django.dispatch import receiver

@receiver(pre_save, sender=MyModel)
def my_receiver(sender, **kwargs):
   ...




Just an idea:

Wouldn't it be a bit nicer API to have receiver be a method on Signal?
So you could do:

@pre_save.receiver(sender=MyModel)
def my_receiver(sender, **kwargs):
...

Bye
Ulrich

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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.

#9015 — signal connection decorator

[Brian Rosner]

Hey all —

I wanted to get some feedback on a patch [1] I wrote for #9015. I am on board 
with the notion decorators can be used for registration patterns. Recently, 
I've been using signals a bit more which has spiked my interest in this ticket. 
Since Django 1.2 has a Python 2.4 minimum requirement and we're before the 
feature freeze I figured I'd take a stab at it.

The approach I took was slightly different than what zvoase took in his 
patches. I felt that using the connect method of Signal would be risky 
business. It is stable API that I didn't want to go modifying. Also, the idea 
of the decorator is to only connect which makes other methods on the signal 
useless. I appreciate the work zvoase did though, so thanks!

My approach introduces new API @receiver from django.dispatch. It takes the 
signal and kwargs and calls connect appropriately. Here's a quick example:

from django.db.models.signals import pre_save
from django.dispatch import receiver

@receiver(pre_save, sender=MyModel)
def my_receiver(sender, **kwargs):
...

Any thoughts or objections to committing?

[1]: 
http://github.com/brosner/django-svn/commit/970dcae959af16699b78ebca13ac878a6ffe86a7

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.