Re: Brute force attacks
On Mon, 7 Mar 2011 18:11:19 -0800 (PST), Rohit Sethi wrote: > Luke, I guess the real question is what's the risk of not including it > out-of-the-box? Well, it *is* not included out-of-the-box. The universe has not collapsed. While I appreciate your proposal, I don't see the immediate necessity to stop all other django development. As Russell wrote: Nothing will happen until somebody gets their hands dirty and writes some code. And the past has proved that this happens much better independently from the release cycle of the django core. When a good solution has been found, it might go into the core. It's simply easier to try out various concepts out of the core. Kind regards 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Storing language in session/cookie
Sorry for bumping the thread, but could somebody familiar with session subsystem anwer it? It is critical for my work to know if this issue is my problem or Django's. -- 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: Customizable Serialization
On Mon, Mar 7, 2011 at 4:28 PM, Vivek Narayanan wrote: > ... > In the run up to May 23rd, I'll be familiarizing myself with the > codebase and community practices of Django, examining all the > integration points and looking at the best practices of serialization. > > Week 1: I'll be implementing a basic skeletal structure for the > serializer, which will set the stage for the rest of the project. > Week 2: Implementation of the deserializer. > Week 3: I'll add support for the metadata methods as discussed above. > Week 4: Support for datatype conversion and the unicode conversion > class methods. > Week 5: Add support for string templates and output formats. > Week 6: Add support for 'modes' as in JSON, XML, YAML etc, complete > the deserializer. > Week 7: Implement serialization of related models, M2M fields, foreign > keys and nesting depth. > Week 8: Add support for ``extras`` and ``exclude`` parameters in the > call to serialize(). Modify ``fields`` parameter as described above. > Weeks 9-10: Check for bugs, fix them and write documentation with many > examples. > Weeks 11-12: Refine the project and its documentation. > > I'll be spending 40-45 hours a week on average. > > Sincerely, > Vivek Narayanan > No offence meant here Vivek, but when I'm speccing something out or reading a spec, if there is a block of work that says 'Implement , 1 week', then I know this hasn't been thought out completely, and that '1 week' could be anything from 45 minutes to 3 months. The reason why software projects take regularly take longer than anticipated is often because the design and thought behind the design was not complete. Ideally you can start breaking down into discrete tasks, each of which shouldn't take longer than 4 hours, which is the largest block of time you should deal with in my experience. Looking at it like that, and assuming a 40 hour week, and 12 weeks of GSoC, you've got 120 units to can account for. Splitting down your project into small chunks will also demonstrate to people reading your proposal that you understand the subject matter, and they can have a high confidence of the project being delivered. Weeks 9-10 made me smile though - no bug fixes allowed in the other weeks? :) 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: Customizable Serialization
On Mar 8, 3:14 pm, Tom Evans wrote: > Splitting down your project into small chunks will also demonstrate to > people reading your proposal that you understand the subject matter, > and they can have a high confidence of the project being delivered. Thanks, I didn't know this and I don't have much experience writing a spec, I'll keep this in mind when writing the final proposal. > Weeks 9-10 made me smile though - no bug fixes allowed in the other weeks? :) Well, there will be bug fixes every week, its just a final dash of fixing bugs. -- 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: Brute force attacks
You're right - let's not argue this anymore. We'll work on something and if it makes it into contrib, great, if not - well I guess we're no worse off than we are right now. In the interim I propose that we add a note to http://docs.djangoproject.com/en/dev/topics/auth/ to let users know that brute-force prevention doesn't come out of the box. Does that sound fair? On Mar 8, 4:10 am, Michael Radziej wrote: > On Mon, 7 Mar 2011 18:11:19 -0800 (PST), Rohit Sethi > wrote: > > Luke, I guess the real question is what's the risk of not including it > > out-of-the-box? > > Well, it *is* not included out-of-the-box. The universe has not collapsed. > > While I appreciate your proposal, I don't see the immediate necessity to > stop all other django development. As Russell wrote: Nothing will happen > until somebody gets their hands dirty and writes some code. And the > past has proved that this happens much better independently from the > release cycle of the django core. When a good solution has been found, > it might go into the core. > > It's simply easier to try out various concepts out of the core. > > Kind regards > > 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off
Hi, On Mar 5, 9:30 am, akaariai wrote: > on(primary_key) id, val1, ... from table order by primary_key this > would solve the problem. Is "DISTINCT ON" part of the SQL standard at all? Cheers, Florian -- 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: the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off
On 8 March 2011 14:01, Florian Apolloner wrote: > Hi, > > On Mar 5, 9:30 am, akaariai wrote: >> on(primary_key) id, val1, ... from table order by primary_key this >> would solve the problem. > > Is "DISTINCT ON" part of the SQL standard at all? > Quoting PostreSQL docs: > The DISTINCT ON clause is not part of the SQL standard and is sometimes > considered bad style because of the potentially indeterminate nature of its > results. With judicious use of GROUP BY and subqueries in FROM the construct > can be avoided, but it is often the most convenient alternative. It's also supported by Oracle, AFAIK. -- Łukasz Rekucki -- 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: the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off
2011/3/8 Łukasz Rekucki : > On 8 March 2011 14:01, Florian Apolloner wrote: >> Hi, >> >> On Mar 5, 9:30 am, akaariai wrote: >>> on(primary_key) id, val1, ... from table order by primary_key this >>> would solve the problem. >> >> Is "DISTINCT ON" part of the SQL standard at all? >> > > Quoting PostreSQL docs: > >> The DISTINCT ON clause is not part of the SQL standard and is sometimes >> considered bad style because of the potentially indeterminate nature of its >> results. With judicious use of GROUP BY and subqueries in FROM the construct >> can be avoided, but it is often the most convenient alternative. > > It's also supported by Oracle, AFAIK. > I forgot to mention there's a ticket to support it in ORM: http://code.djangoproject.com/ticket/14139. -- Łukasz Rekucki -- 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: the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off
On Sat, Mar 5, 2011 at 1:29 PM, Karen Tracey wrote: > On Fri, Mar 4, 2011 at 10:24 AM, Viktor Kojouharov > wrote: >> >> I'm testing my software with the new rc1 release of django 1.3, and I came >> onto a particularly nasty problem. >> I have a model which uses a Postgresql 'point' type, for which I've >> defined a field as: >> http://dpaste.com/472467/ >> >> I also have another model, which references this one with a foreign key. >> When saving an instance from this other model, django throws the following >> exception: >> http://dpaste.com/472475/ >> The exception is due to the new 'DISTINCT' part of the SELECT query. >> Because of the point field, there is no way to select 'unique' entries, >> because Postresql cannot compare points. >> So the question is, is there any way to turn off this distinct query, and >> just force django to assume that all entries are unique? > > Looks like the change that added distinct to this query is this one: > > http://code.djangoproject.com/changeset/15607 > > It's probably best if you open a ticket in trac > (http://code.djangoproject.com/newticket) for this. I can't think offhand > how to solve both the problem that changeset fixed and the one you are > encountering I can't see an obvious fix here either. Given the timeframe, we may need to roll back this fix, live with the older bug, and look at it again in the 1.4 timeframe. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inline formset exception
On Mon, Mar 7, 2011 at 3:17 PM, poswald wrote: > (Sorry Ramiro, I think I replied directly to you instead of to the > group. Resending here) > > Understood. I believed I was adding a testcase and expanding the scope > of the issue but it is certainly possible that they are two separate > causes. I will keep that in mind in the future and will certainly open > a new issue/revert this one here if everyone would prefer. > > For what it is worth I was able to reproduce the exception using the > original reporter's code but only if I follow the process I outlined > in my report. Actually I've just reproduced (using trunk) the situation reported by the OP: Simple two-model generic foreign key plus generic inlines setup in the admin app, activation and usage of the save as button and no need to add a second browser window in the mix. A very simple to prepare and reproduce setup. The other users that added comments to the ticket before loosely described their problem as not related to the admin inlines at all rather with more low level model formsets; in any case they don't provide enough details to be able to know if they are really contributing to the isolation of the original issue or simply landed in that ticket with a search and found something similar in its symptoms to their own issues. Because of this I'm going to revert your changes to the ticket and I'd like to ask you to open another ticket and move what you've found so far there. We might be in presence of he same issue but I think the divergence of initial conditions show it's too early to be sure of that. Thanks, -- Ramiro Morales -- 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: Brute force attacks
Hi Guys, This topic has me crawling out of the woodwork, I would like to contribute to the effort. Can't see this making it into django's core, although I would like to see it there, I think complexities would inhibit beginners and veterans alike, although, it would be nice if it could be configured and enabled. At a minimum, it's going to require a table or two in the auth realm, and additional hooks on the rack. What I would like to see is something akin to a bank's level of security that could be throttled to preference. -Joe -- 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: the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off
2011/3/8 Łukasz Rekucki : > It's also supported by Oracle, AFAIK. It is not, although it can be emulated using an analytic query. I tried adding this to the patch in #6422 some time ago, but I found that the structure of an analytic query was going to be rather complicated to shoe-horn that into the query compilation code. That was before the SQL compiler was factored out of the query code, and I haven't gotten around to trying again since. Cheers, Ian -- 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-open #7231: New "join" parameter for the "extra" QuerySet method
http://code.djangoproject.com/ticket/7231 I'd like to start a discussion on this since russelm closed the issue. There are a few other people that believe the issue should be left open. I've been using this patch for nearly two years, and have found it to be useful in several different cases. I disagree that the .raw() functionality is a sufficient alternative, as it is not possible to modify an existing queryset using .raw(). For example, if I have a function that accepts a queryset, I want to be able to modify that queryset by giving it a extra info for the JOIN and SELECT clauses. -- 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: Re-open #7231: New "join" parameter for the "extra" QuerySet method
On Tue, Mar 8, 2011 at 9:35 PM, bendavis78 wrote: > I'd like to start a discussion on this since russelm closed the > issue. There are a few other people that believe the issue should be > left open. I've been using this patch for nearly two years, and have > found it to be useful in several different cases. I disagree that > the .raw() functionality is a sufficient alternative, as it is not > possible to modify an existing queryset using .raw(). For example, > if I have a function that accepts a queryset, I want to be able to > modify that queryset by giving it a extra info for the JOIN and SELECT > clauses. .extra() was a kludge that existed because .raw() didn't. Frankly, I'm considering deprecating and removing .extra() entirely: I've rarely seen a case where using it didn't come back to cause problems in the future. I'm certainly going to be a strong -1 on adding any more "features" to .extra(). Remember, Django's ORM tries to hit an 80-90% point, but then you're *expected* to fall back to raw SQL past that point. Falling back to raw SQL when it's easier is a feature, not a bug. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Re-open #7231: New "join" parameter for the "extra" QuerySet method
On Wed, Mar 9, 2011 at 7:09 AM, Jacob Kaplan-Moss wrote: > On Tue, Mar 8, 2011 at 9:35 PM, bendavis78 wrote: >> I'd like to start a discussion on this since russelm closed the >> issue. There are a few other people that believe the issue should be >> left open. I've been using this patch for nearly two years, and have >> found it to be useful in several different cases. I disagree that >> the .raw() functionality is a sufficient alternative, as it is not >> possible to modify an existing queryset using .raw(). For example, >> if I have a function that accepts a queryset, I want to be able to >> modify that queryset by giving it a extra info for the JOIN and SELECT >> clauses. > > .extra() was a kludge that existed because .raw() didn't. Frankly, I'm > considering deprecating and removing .extra() entirely: Yes. Yes Yes Yes. Yes. Oh, and Yes. +1. > I've rarely > seen a case where using it didn't come back to cause problems in the > future. I'm certainly going to be a strong -1 on adding any more > "features" to .extra(). Agreed. From an engineering perspective, extra() is the single most fragile part of the ORM. Dumping extra would make me extraordinarily happy. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
