Move tutorials to own page on DjangoResources?
Does anyone object/disagree if I move all the tutorials off the DjangoResources page (1), to a new page (2) to give them some more room to 'breathe'? I'll take a crack at categorising them too - pre- MR, components, etc. (1) http://code.djangoproject.com/wiki/DjangoResources (2) http://code.djangoproject.com/wiki/Tutorials --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
why manage.py sets sys.path to both . and ..
HI everyone, I'm getting into problems because manage.py sets sys.path to both its folder _and_ the parent folder. I find this kind of magic frustrating because of the following reasons: 1. I'm unable to have package name "project.project" When I build a simple project with a single app, I would like to name the app after the project. I don't like the idea of *different* names for a single concept. Therefore, I have to use "project.apps.project" naming even with a single app, which is redundant. 2. I'm unable to make package "project.django" or "project.", because, after that "from django import db" stops working (since "." is in sys.path before "..") 3. I don't like the fact that the root namespace is polluted with "settings", "urls", or even "apps". I would like to occupy one (and only one) root namespace element, named after the project). 4. I'm forced to name virtual host folder named after the project, which is not always what I would want. For example, I'm writing a project for "www.project.com", the folder name is "project.com", but I don't like the package to be named "project.com" (I'm not even sure that it's possible to have dots in the package name). I've found several threads in this group regarding this issue, but no decent solution or even comments. How do most of people organize their django webapps? No-one having the similar thoughts on their mind? Thanks, Ilya Semenov. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
{% url %} for generic views (proposal)
Hello!
I was lazily thinking about making {% url %} and "reverse" to work for
generic views ("GV"). The main problem why reversing doesn't work for GV
is that it relies on view's name to be unique while GVs obviously have
the same name for many URLs (that makes them "generic"). Hence a
signature of a GV consists not only of its name but also of some (but
not all) parameters from info_dict.
## A common case
I've failed to invent a good general way of dealing with this and
decided to go for 80 from 80/20 rule. It looks like in most cases people
need reversing for GVs pointing to object pages: "object_list" and
"object_detail". May be also for date based GVs but let's leave them
aside for a while.
So for "object_list" and "object_detail" I propose this syntax:
{% obj_url "appname.ModelName" id %}
{% obj_list_url "appname.ModelName" %}
Both GVs have their own tag that knows the actual name of a GV (like
"django.views.generic.list_detail.object_list"). Though I like it this
way it's not set in stone and may be some parameter would be better
(like {% url "object_detail" "appname.ModelName" %}).
Tags accept a model name as a first argument. This will require a
special version of "reverse" that checks for a view name and for a model
name that it knows how to get from a "queryset" parameter from info_dict.
This looks to me both simple for a template tag and useful for most real
cases.
## More special case
There is one special case that I feel is not that special to not be
addresses. Sometimes you have to URLs that have the same GVs _and_
querysets against the same model:
(r'/objects/$', object_list, {
'queryset': Model.objects.all(),
}),
(r'/objects/active/$', object_list, {
'queryset': Model.objects.filter(active=True),
}),
The distinction by model name won't work here. For this I propose an
optional fourth member to an urlconf pattern: view's given name:
(r'/objects/$', object_list, {
'queryset': Model.objects.all(),
},
'objects'),
(r'/objects/active/$', object_list, {
'queryset': Model.objects.filter(active=True),
},
'active_objects'),
And the tag will accept it as a first parameter:
{% obj_list_url "active_objects" %}
This will require additional configuration but I think it's okay since
it's not required for a common case and is simple enough.
This "view name" will also solve other problems: reversing for the rest
of GVs and may be a permalink decorator that James Bennett was talking
about in django-user recently.
Now I think that this proposal is better sounds like "introduce
view names, use model's name for this in known generic views"
So what do you think about it?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Move tutorials to own page on DjangoResources?
On 3/13/07, Simon G. <[EMAIL PROTECTED]> wrote: > > Does anyone object/disagree if I move all the tutorials off the > DjangoResources page (1), to a new page (2) to give them some more > room to 'breathe'? I'll take a crack at categorising them too - pre- > MR, components, etc. Sounds like a good idea to me. This would also give a good place to link to at the end of the last official tutorial. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Move tutorials to own page on DjangoResources?
On Mar 13, 6:10 am, "Simon G." <[EMAIL PROTECTED]> wrote: > http://code.djangoproject.com/wiki/DjangoResources Simon, It might also be worth giving greater prominence to http://www.djangosnippets.org. The site is almost hidden as the 22nd item listed under Open Source Django Projects. It might also be nice to have this resource mentioned on the Django Code page. -- Jeff Bauer Rubicon, Inc. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: {% url %} for generic views (proposal)
On 3/13/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> I was lazily thinking about making {% url %} and "reverse" to work for
> generic views ("GV").
I've been thinking about this a bunch myself. I came up with some
ideas similar to yours, but so far they're just in my head. I'll try
to write 'em up, but in the time being I'd love to see you (or
someone) start hacking on some code!
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Enforcing MySQLdb version(?)
On 3/10/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > However, the more I think about this the more I think we should be > throwing an error if they are using an older version, particularly in > the new (0.96) release. If you are using the older version you will see > bugs. There is no question about this. It's just dangerous in production > environments. So we should be up front about it. Indeed -- this is how I'd like to see it behave. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: {% url %} for generic views (proposal)
Jacob Kaplan-Moss wrote: > I've been thinking about this a bunch myself. I came up with some > ideas similar to yours, but so far they're just in my head. I'll try > to write 'em up, but in the time being I'd love to see you (or > someone) start hacking on some code! Ok! For the reference: http://code.djangoproject.com/ticket/3717 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Tickets on send_mass_mail functionality (multipart/encoding/TLS/BCC)
On 3/12/07, Gary Wilson <[EMAIL PROTECTED]> wrote: > I asked Jacob to take a quick look at this ticket during the PyCon > sprint. His comments were (1) the send method on EmailMessage is > kinda neat and (2) we would need to keep send_mail() and > send_mass_mail() functions around for backwards compatibility, but > could deprecate them for 1.0. From my standpoint, however, he made no > definite decision. Sorry for my radio silence on this; I've been busy elsewhere... This is a good summary of how I feel. I do agree with Malcolm that dicts are slightly more transparent than objects, but I think I like Gary's idea of letting message objects grow add_attachment(), etc. As an added bonus, letting the message object send() itself makes it easy to mock that function during testing (currently, testing email sending kinda sucks). The other nice thing about this is that the change can be made in a backwards-compatible way: we can keep send_mail() and friends around, but change the docs to reflect the new way of doing things (construct an EmailMessage and then send() it). 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Google Summer of Code 2007
While being interested in becoming a soc student for this year myself I would like to encourage you to enlist as mentors and continue the submission of project ideas on the wiki page [1]. Best, Jannis [1] http://code.djangoproject.com/wiki/SummerOfCode2007 Am 27.02.2007 um 05:05 schrieb Joseph Kocherhans: > > On 2/26/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: >> >> On 2/27/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: >>> >>> On 2/26/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: Specifically, I was referring to the has_*_permission() stuff in the new ModelAdmin class. Which is new functionality aside from the oldforms to newforms port. >>> >>> A lot of the generic-auth and RLP code is nasty stuff to try to >>> integrate with the admin system. The new methods are very much >>> welcome >>> by me both as someone very familiar with the per-object-permission >>> branch, and as the author of the generic-auth branch. The design is >>> much cleaner. >>> >> >> I agree that it is cleaner but it still limited to the admin system >> with no generic means available to other applications. I seems [1] >> that interest in doing this is also waning. > > I'm sorry you have the impression that it would be limited to the > admin system. It's certainly not something I meant to convey. When RLP > is integrated, it will be available to more that just the admin > system. My personal opinion is that most of the code in there is good > and will probably be used as is. The admin integration is a little > nasty, but that isn't Chris's fault. The admin system just wasn't > designed with extensibility in mind. At PyCon, we came up with a plan > to change that. After the new admin stuff done, I will probably end up > working on RLP myself if no one beats me to the punch. > >> I for one am very keen to see RLP branch integrated and I tested it >> months ago to my satisfaction. > > I understand that the branch works well for a lot of people, and if it > works for you, by all means continue using it. If you want to see new > features added to it from the trunk, speak up and ask for commit > access. The branch could probably use a maintainer. > > Joseph > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: why manage.py sets sys.path to both . and ..
Hi Ilya, I'll just speak about how I organize my django work. This diagram might help you: http://www.calixto.net/john/djangoproj_layout.txt It probably doesn't address your #1 (naming the app the same as the project). However, I think having an app called "site" would scale well should you decide to add another app into your simple project. I'm not totally sure I understand your #2, so I won't speak to that. As for your #3, you don't have to "pollute" Python's global namespace. All your modules can be contained in the "project" package. Then, all your apps are just sub-packages of that. In my opinion, this is a pretty clean namespace solution. Of course, if you're deploying with modpy, you'll need to SetEnv DJANGO_SETTINGS_MODULE to be yourproj.settings. You'll see that I also provide a setup.py for my projects to install them cleanly into site-packages as if they were "normal" Python packages (because they are!). Anyway, I hope that helps. John On 3/13/2007, "Ilya Semenov" <[EMAIL PROTECTED]> wrote: > >HI everyone, > >I'm getting into problems because manage.py sets sys.path to both its >folder _and_ the parent folder. I find this kind of magic frustrating >because of the following reasons: > >1. I'm unable to have package name "project.project" >When I build a simple project with a single app, I would like to name >the app after the project. I don't like the idea of *different* names >for a single concept. Therefore, I have to use "project.apps.project" >naming even with a single app, which is redundant. > >2. I'm unable to make package "project.django" or "project.common name>", because, after that "from django import db" stops >working (since "." is in sys.path before "..") > >3. I don't like the fact that the root namespace is polluted with >"settings", "urls", or even "apps". I would like to occupy one (and >only one) root namespace element, named after the project). > >4. I'm forced to name virtual host folder named after the project, >which is not always what I would want. For example, I'm writing a >project for "www.project.com", the folder name is "project.com", but I >don't like the package to be named "project.com" (I'm not even sure >that it's possible to have dots in the package name). > >I've found several threads in this group regarding this issue, but no >decent solution or even comments. How do most of people organize their >django webapps? No-one having the similar thoughts on their mind? > >Thanks, >Ilya Semenov. > > >> --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
newsessions
Anton Khalikov opened a new ticket pointing out a hole in the current session framework which can cause session id collisions. He's put together a newsessions package which could be good, but obviously needs some discussion (here). So, discuss away! http://code.djangoproject.com/ticket/3716 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
On 3/13/07, SmileyChris <[EMAIL PROTECTED]> wrote: > Anton Khalikov opened a new ticket pointing out a hole in the current > session framework which can cause session id collisions. The proposed solution for collision (more on that in a moment) seems good -- the bug seems to happen solely because we don't immediately instantiate and save a Session, so that'd work around it. I'm more wary of tying to an IP address, because I don't think that really buys any security; there are still ways to spoof or set up man-in-the-middle attacks, so the only real solution would be to tell paranoid people to use encrypted connections (which they should be doing anyway if they'd paranoid :)). Though I have to say that I'm rather shocked by the ease of session collision -- it requires the same pair of random numbers (out of a range of sys.maxint) to come up, in the same order, within a fairly short period of time, something that just doesn't seem likely to happen a lot (given sys.maxint on my MacBook, such a collision should happen roughly once for every 4.6 *quintillion* trials). I know the 'random' module isn't industrial-strength, but surely it's better than that? And if it's not, then let's start salting it with more stuff. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Hi, as far as I see, newsessions checks REMOTE_IP. Is this a good idea? a) the client can sit behind a NAT that might hand out different IPs b) the server can be behind NAT and not see the true IP at all. It might see different IPs for the same client over time. c) a crazy load balancer might get in the way I wouldn't use REMOTE_IP. In Ticket #1180, Anton said that users reported that they were able to get someone else's session. I wonder if that might be related to something quite different. Anton, was this by chance on a threaded server with a python-mysql < 1.2.1p2? Here's the (old) code that generates a session: def get_new_session_key(self): "Returns session key that isn't being used." # The random module is seeded when this Apache child is created. # Use person_id and SECRET_KEY as added salt. while 1: session_key = md5.new(str(random.randint(0, sys.maxint - 1)) + str(random.randint(0, sys.maxint - 1)) + settings.SECRET_KEY).hexdigest() try: self.get(session_key=session_key) except self.model.DoesNotExist: break return session_key The chance that two consecutive session creations generate the same session id is 1 : sys.maxint^2, on my system sys.maxint is 2^31. So we're at 2^62. If the internal state of the random generator is big enough, it might make sense to hash 4 randints instead of only 2. Or to check for collisions at the same time as you save the session. But the chances are good that Anton experiences a different problem. Michael --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Mentors still needed for Google Summer of Cod
Howdy folks -- We still need developers to be mentors for the Summer of Code. This essentially means helping a student as s/he implements some cool new feature, and making sure that s/he completes things on time. If you've been around here for a bit and want to *really* help us out, please sign up! To sign up, add your name to http://code.djangoproject.com/wiki/SummerOfCode2007, and then go sign up over at Google: http://code.google.com/soc/mentor_step1.html. If you have questions, I'd be happy to answer 'em, but note that student applications open *tomorrow*, so you'll need to sign up to be a mentor *today*. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
On 3/13/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > a) the client can sit behind a NAT that might hand out different IPs > b) the server can be behind NAT and not see the true IP at all. It >might see different IPs for the same client over time. > c) a crazy load balancer might get in the way (or any proxy, in which case REMOTE_IP will be the same for every request and you'd want to be looking at the 'X-Forwarded-For' header -- this is one of the problems with IP-based sessions) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
I actually passed this onto the security mailing address, as I thought it was better to be safe than sorry. Adrian's response was that tying things to the IP address is not a good idea (for the reasons that others have stated in this thread). One thing that I would like to suggest is that we do link the SID to a user-agent (see Chris Shiflett's excellent article on this at [1]), as this provides some protection (-via-obscurity) against these collisions, since the attacker not only needs to get a valid SID, but match it to the correct UA string. There's also no reason for a "normal" user to change UA strings without needing to login again. This can easily be added to the existing session framework by adding it to the hashing --Simon [1] http://shiflett.org/articles/the-truth-about-sessions --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
SmileyChris wrote: > Anton Khalikov opened a new ticket pointing out a hole in the current > session framework which can cause session id collisions. Could be easily fixed with providing Model._update() and Model._insert() as proposed here: http://groups.google.com/group/django-developers/browse_thread/thread/6ddfb7da8319c6df/c2d3671b6a6fec5f abstract example code: http://groups.google.com/group/django-developers/browse_thread/thread/6ddfb7da8319c6df/c2d3671b6a6fec5f#msg_56de2a0ef2b884cc (First code block, additional to having less queries this would prevent race conditions) SessionManager could then calculate a session and try to save an object with this session-key (allowing only INSERT, not UPDATE). If the key exists the DB-backend will raise an Exception as the key is unique (primary_key). If it is free, the INSERT will ensure that no other session may use the key. If I get this right the newsession-patch is trying to do so, but will fail, beuase s.save() (django/contrib/newsessions/models.py, line 29) will overwrite (SQL UPDATE) existing sessions instead of failing creating it. One tiny advantage remains: There is less code (=time) between calculation the session key and saving it, so less chances to get a race condition. But I don't see a real fix there. Simon G. wrote: > One thing that I would like to suggest is that we do link the SID to a > user-agent [...] I heard about some proxies or anonymizer services that actually do change the user agent. But I haven't seen this so far, nor searched for it. ;-) Greetings, David Danier --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
DateField and DateTimeField and auto_now, auto_now_add
Both have the behaviour that "the current date is always used". For auto_now, it meas it is impossible to set a custom timestamp. For auto_now_add it means you first have to create the object, save it, set custom stamp, save again. First it is odd that if it is intended for the timestamp to be written in stone, it can be circumvented for auto_now_add.. But at least the timestamp can be changed ;) I fail to see why supplying a custom timestamp to override the auto- timestamp is not allowed. While moving a site to django i import old articles, which have both a created and updated date. Using django's models to populate the db with the older data it is impossible to set the last updated date (Unless of course I temporary change the model definition). It's all nice for the timestamp to be updated if no data is given, but when I explicitly give a timestamp I expect it to be used. (Also think of the scenario when something with a timestamp is altered, then again it is undone, I would want to cheat and set the time back as well) I would propose to allow for overriding these timestamps. If the current behaviour is the intended behaviors perhaps one could add the option to explicitly allow for overriding, auto_* (e.g. add the argument auto_override for DateFields, which defaults to False, but when set to true allows for custom timestamps) (And I'd gladly add a patch for it) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
On 3/13/07, Simon G. <[EMAIL PROTECTED]> wrote: > There's also no reason for a > "normal" user to change UA strings without needing to login again. UA strings change on every minor rev of some browsers, plus various tool versions (.net, etc.). Having those users logged out would suck for my purposes. Perhaps a setting (sorry!)? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: DateField and DateTimeField and auto_now, auto_now_add
On 3/13/07, Norjee <[EMAIL PROTECTED]> wrote: > > Both have the behaviour that "the current date is always used". For > auto_now, it meas it is impossible to set a custom timestamp. For > auto_now_add it means you first have to create the object, save it, > set custom stamp, save again. > > First it is odd that if it is intended for the timestamp to be written > in stone, it can be circumvented for auto_now_add.. But at least the > timestamp can be changed ;) > > I fail to see why supplying a custom timestamp to override the auto- > timestamp is not allowed. While moving a site to django i import old > articles, which have both a created and updated date. Using django's > models to populate the db with the older data it is impossible to set > the last updated date (Unless of course I temporary change the model > definition). It's all nice for the timestamp to be updated if no data > is given, but when I explicitly give a timestamp I expect it to be > used. (Also think of the scenario when something with a timestamp is > altered, then again it is undone, I would want to cheat and set the > time back as well) for this use DateField( default=models.LazyDate() ), it will do exactly what you want: supply a default value of NOW() when no timestamp is given. It seems redundant to replicate this with the auto_* stuff, those are meant to be unchangeable... > > I would propose to allow for overriding these timestamps. If the > current behaviour is the intended behaviors perhaps one could add the > option to explicitly allow for overriding, auto_* (e.g. add the > argument auto_override for DateFields, which defaults to False, but > when set to true allows for custom timestamps) (And I'd gladly add a > patch for it) > > > > > -- Honza Kr�l E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Guys I would like to explain some things and decisions in my code. 1. REMOTE_IP. I think it is a good idea to check it. Load balancers acts as proxy servers. Every web server has a module that allow to restore REMOTE_IP from X-FORWARDED-FOR, for example apache's module is called mod_rpaf. And ofcourse it's very easy to make REMOTE_IP checking code to be disabled or enabled via settings.py, just like it is in php, such modification is quite simple. 2. In my installation I use lighttpd and django as preforked fastcgi server, python 2.4. It's hard to reproduce such things but they _do_ happen. One can say my installation is broken but I think it's rather a hole in django if it allows such things to be ever happened. 3. Perhaps, current sessions may be patched too, what is needed is to force django to try INSERT into table but it looks like dirty hack to me because documentation says: if object's pk evaluates to something else than True, django does checking if such row already exists in db and while django does it, another process may get the same session id and try it too and we get collision again. My way works rock stable because of different table design and this is the only reason why i used another package name (newsession) istead of just patching existing package. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Even more on remote ip checking: it can be done in a flexible way when user is able to set either don't ever use it, check remote ip, check user agent name or ever both remote ip and user agent for paranoids :) I think everyone understands that it's about 2-3 more lines of code. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
On 3/13/07, ak <[EMAIL PROTECTED]> wrote: > 1. REMOTE_IP. I think it is a good idea to check it. Load balancers > acts as proxy servers. Every web server has a module that allow to > restore REMOTE_IP from X-FORWARDED-FOR, for example apache's module is > called mod_rpaf. And ofcourse it's very easy to make REMOTE_IP > checking code to be disabled or enabled via settings.py, just like it > is in php, such modification is quite simple. I'm still wary of this -- again, it doesn't do anything to prevent man-in-the-middle, and it introduces complexity and -- if we're worried about session collisions -- introduces a whole new class of bugs when you have a bunch of people behind a NAT or firewall who all, from the POV of your server, have the same IP address. > 2. In my installation I use lighttpd and django as preforked fastcgi > server, python 2.4. It's hard to reproduce such things but they _do_ > happen. One can say my installation is broken but I think it's rather > a hole in django if it allows such things to be ever happened. I think we definitely need to tighten up the time between selecting a session key and shoving the session into the DB -- I'm thinking along the lines of using get_or_create and retrying until you get back a True creation value from it (that way you don't have to do anything else -- the session is already in the DB when get_or_create returns. But I'm still worried about the apparent fact that this is all coming from key collisions, because what it points to is not a race condition at the database level -- what it points to is bad randomness. Python's random-number generator uses the Mersenne Twister, and in Python 2.3 it seeds itself with the current system time (and in 2.4 it tries system-supplied randomness facilities first, then falls back to system time). I'm not an expert on randomness by any means, but the problem we have here is the same pair of random numbers being generated at the same time or within a very short time of one another, and my first inclination is to look at the fact that we're using a deterministic RNG seeded -- by default -- with the system time. So instead of trying to ensure safety at the database level (because, frankly, unless we go to extremes we're not going to manage that), why not look at better seeds for the RNG and solve the real problem? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
> I'm still wary of this -- again, it doesn't do anything to prevent > man-in-the-middle, and it introduces complexity and -- if we're > worried about session collisions -- introduces a whole new class of > bugs when you have a bunch of people behind a NAT or firewall who all, > from the POV of your server, have the same IP address. Well I don't agree with you here: 1. This option can be disabled by default and only enabled optionally by developer (like in php, as i said) 2. I have an ethernet connection @home and I sometimes log in to our private web apps from home. Any 'c00l hacker' is able to scan network traffic, get my session id and use it to join to my session too just because there is absolutely no checking who uses session. We added ip checking at our application level code but why don't implement this at django side as an option ? Noone says this is 100% guarantee of getting rid of man-in-the-middle, but at least it prevents from successful hacks from kiddies when using untrusted networks (ie public wi-fi, ethernet, etc). > I think we definitely need to tighten up the time between selecting a > session key and shoving the session into the DB -- I'm thinking along > the lines of using get_or_create and retrying until you get back a > True creation value from it (that way you don't have to do anything > else -- the session is already in the DB when get_or_create returns. > > But I'm still worried about the apparent fact that this is all coming > from key collisions, because what it points to is not a race condition > at the database level -- what it points to is bad randomness. Let's separate problems because there are 2 problems: 1. Somehow same ids are generated in a short period of time. So id generation needs to be improved. 2. Django allows session collisions. I am not an expert in the first problem but I definitely think that second problem must be solved in the way I suggested, instead of shortening time between checking and storing new record to db. Just imagine: you have a gun, that sometimes fires to it's holder. I suggest to change construction to make it impossible in any way, you suggest to change the way how holder should pull the trigger, hold the gun in arms etc but if we don't change the construction, whatever we do there still IS a possibility to shoot yourself :) Hope I explained well enough. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
On 3/14/07, ak <[EMAIL PROTECTED]> wrote: > 2. I have an ethernet connection @home and I sometimes log in to our > private web apps from home. Any 'c00l hacker' is able to scan network > traffic, get my session id and use it to join to my session too just > because there is absolutely no checking who uses session. We added ip > checking at our application level code but why don't implement this at > django side as an option ? Noone says this is 100% guarantee of > getting rid of man-in-the-middle, but at least it prevents from > successful hacks from kiddies when using untrusted networks (ie public > wi-fi, ethernet, etc). I guess I just feel that someone who's determined enough to sit around and sniff for your session ID is also going to be determined enough to defeat IP checking (which wouldn't be that hard -- again, the real solution to that is encrypted connections, not increasing numbers "sessions are tied to x, y and z"), so it doesn't get us any real improvement in security. But I'll bow out of that debate. > Let's separate problems because there are 2 problems: > 1. Somehow same ids are generated in a short period of time. So id > generation needs to be improved. > 2. Django allows session collisions. Problem 2 is a direct consequence of Problem 1. In fact, Problem 2 is, I think, just a symptom of problem 2 -- you can't have a DB race condition with sessions unless you're generating identical session keys for different people in the first place. I'm not saying I'm against separating insert and update in the ORM, though -- I'm just trying to think pragmatically: this is a nasty bug that needs to be fixed as soon as possible, and separate insert/update would be a non-trivial refactoring of the Django ORM and wouldn't solve the underlying source of this bug, which is duplicated session keys. Meanwhile, coming up with a better way to generate session keys -- probably through seeding the RNG -- is easy to do and solves the underlying problem. Which means my vote is going to be for better session keys now, and a design decision about insert/update when we do the QuerySet refactor post-0.96. > I suggest to change construction to make it impossible in any way, you > suggest to change the way how holder should pull the trigger, hold the > gun in arms etc but if we don't change the construction, whatever we > do there still IS a possibility to shoot yourself Again, for me it's a question of priority -- if we can solve the key-collision problem by seeding the RNG, that's a better solution for right now than overhauling the ORM's object-saving methods. To run with your analogy, we've already been shot and we're bleeding, and the gun is still going off. Our priority right now should be to stop the shooting and tend to our wounds, or at least to point it away form us, not to go shopping for a better gun. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
> so it doesn't get us any real improvement in security James, there is a concept of 'fool proof'. Real hackers may do many things. But current model allows even 10 year old kids to be hackers. This is just against them. There is no ability to protect all sites with ssl and I would not like a neighbor's son could read my email because he got my session id by running simple ethereal > I'm not saying I'm against separating insert and update in the ORM, > though Have you ever looked in my code ? There are no hacks of ORM, there is just a different sessions table design where session id is not anymore a primary key but just an unique key. Primary key is a separate field and this approach allows us to use existing ORM to do things correct way where session collision is impossible at table level, so impossible by design. And again: I am not voting against improving if IDs generation, I think these problems should be solved both. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Default django installation uses session lifetime equal to 2 weeks with no session expiration at browser close. Just calculate what should be a default strength of session id generator to successfully generate unique IDs within 2 weeks for a web app with 1 000 000 unique visitors per a day. As far as I understood, current generator was checked for duplicates on just 2 000 000 of iterations. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: How to use Django session without browser cookies support
On Mon, 2007-03-12 at 20:52 -0700, Sengtha wrote: > I am currently working on one project which needs to view page on > browser that doesn't support cookies. > By what I know, all Django sessions are based on browser cookies. And > Django sessions are save in django_session table. I wonder there is > any way to implement Django session like PHP session.use_trans_sid > without relying on client's browser cookies. This question is better asked on the django-users list. Please post any follow-ups there. However, the short answer is "no": if you want to use Django's standard session module, you need to use cookies. If you don't want to use cookies, you will need to write your own sessions app (or find somebody who may have already done the work). Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Server-side cursors in psycopg2
Hey Jeremy,
On Mon, 2007-03-12 at 23:15 -0500, Jeremy Dunck wrote:
> Over on the psycopg2 list, I saw a mention that psycopg2 supports
> optional server-side cursors, which is good for client-side memory
> usage but requires more network round-trips to fetch the whole
> resultset. (Apparently, by default, it fetches all results into the
> client process on the first fetch.)
>
> The short version is that when you do this:
>
> cur = conn.cursor(name=spam)
> cur.execute('select "eggs"')
> This is sent to the server:
> 'DECLARE spam CURSOR WITHOUT HOLD FOR select "eggs";'
>
> Is there any interest in supporting this in QuerySet when using
> postgres? If so, I'll add it (and benchmarking) to my todo list.
I'd be interested to see some performance numbers for this (with a
remote server, since network traffic times will be a non-zero portion of
the result in some cases). It probably shouldn't be too painful to hook
it up to use server-side cursors always and just time a few things.
I hadn't realised that existing cursors pulled everything over at once
-- I would have "guessed" (based on no information other than "that's
the way I would think of doing it") that they would pull a chunk of
results each time to find a balance between efficiency and memory usage.
I guess there's a bunch of questions to ask about how this performs,
such as whether destroying the cursor object correctly notifies the
server that the result can now be freed (otherwise you've transferred
any memory problems you might have to the server). It sounds interesting
for some high-volume cases, though.
Cheers,
Malcolm
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: i18n: newforms - label and help_text don't work with _('')
On Tue, 2007-03-13 at 06:45 +, Boris Erdmann wrote: > Hi, > > sorry for cross posting: > > > The __init__ method of the newforms.Field class normalizes labels and > help_text by using smart_unicode(). > > This seems to break gettext_lazy. The marked string gets evaluated to > early? > > When accessing a newly started http server with two browsers with > different accept-languages, both get to see the translation of the > first browser. > > If I remove the usage of smart_unicode() in Field class of newforms/ > fields.py > "everything" works as expected. Sounds like a bug and it looks like you've worked out the cause, too, which should make fixing it easier. Could you open a ticket about this please (put it in the "internationalization" component) so that we won't lose this information. I'm paying a bit of attention to i18n tickets at the moment, so this will get fixed. Regards, Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
