Re: ModelForms and the Rails input handling vulnerability

On 13 kesä, 02:16, Luke Plant wrote: > For the record, I brought up the issue initially, and favour the most > secure of the options outlined below, but I'll try to summarise with as > little bias as I can! > = Option 1: Leave things as they are, just document the problem.

QuerySet refactoring

I am asking for directions about what to do about django.db.models.sql.query (actually sql.*). I would like to refactor the code in small incremental steps. However, this will bring internal API breakages, and will likely add some more bugs temporarily. While the ORM mostly works, it IMHO needs

Re: QuerySet refactoring

On 13 kesä, 09:50, Anssi Kääriäinen wrote: > I am asking for directions about what to do about > django.db.models.sql.query (actually sql.*). I would like to refactor > the code in small incremental steps. However, this will bring internal > API breakages, and will likely

Re: ModelForms and the Rails input handling vulnerability

Hallöchen! Luke Plant writes: > [...] > > == Options == > > There were three main courses of action that we talked about on > django-core. > > [...] > > = Option 2: Deprecate Meta.exclude, but still allow a missing > Meta.fields attribute to indicate that all fields should be > editable. For

Re: Should custom django-admin commands always explicitely close the db connection?

Hello I would like to bump this thread. Recently we stroke a similar problem. Are there any official changes in Django regarding this topic? Thanks in advance. Regards W dniu czwartek, 23 grudnia 2010 22:17:12 UTC+1 użytkownik Djoume napisał: > > Hi, > > Most django-admin commands that

Re: ModelForms and the Rails input handling vulnerability

(I apologize if this is a duplicate - my other account appears to have an issue sending to this group) I'm in the camp don't change it. ModelForms are doing what they are designed to do: providing a very handy short cut. It is a design decision to either use a ModelForm, or a a plain Form

Re: QuerySet refactoring

On 13/06/12 08:09, Anssi Kääriäinen wrote: > Accidentally clicked send... So, what I am asking is: Is there support > for ORM refactoring, and the "small step at time" way of doing it? If > the ORM refactorings are to be done, it will be hard to get reviews. > In practice I would need to commit

Re: ModelForms and the Rails input handling vulnerability

I personally think that a job of Django is to stop naive developers from doing stupid things. This is one of those things that a developer should understand, but it is substantially hidden and a real problem that bots exploit on the web. For this reason, option 3 would be my choice, but I think we

Re: ModelForms and the Rails input handling vulnerability

Hi Anssi, On 06/13/2012 12:08 AM, Anssi Kääriäinen wrote: > On 13 kesä, 02:16, Luke Plant wrote: >> For the record, I brought up the issue initially, and favour the most >> secure of the options outlined below, but I'll try to summarise with as >> little bias as I can! >

Re: ModelForms and the Rails input handling vulnerability

Hi Luke, Thanks for identifying this issue and continuing to push for a resolution. On 06/12/2012 05:16 PM, Luke Plant wrote: > == Option 1: This is the least secure, but most convenient - you have > several ways to specify which fields should be editable, you can use > whichever you like.

Re: ModelForms and the Rails input handling vulnerability

On Tue, Jun 12, 2012 at 7:16 PM, Luke Plant wrote: > > = Option 1: Leave things as they are, just document the problem. This > was the least popular view on django-core. > > = Option 2: Deprecate Meta.exclude, but still allow a missing > Meta.fields attribute to indicate

Re: ModelForms and the Rails input handling vulnerability

On 13 kesä, 20:58, Carl Meyer wrote: > > 2. The fix doesn't actually fix the issue for all cases. You are still > > allowed to use the same form in a way that renders additional fields > > based on user permissions or if the user is authenticated. If you > > reuse the same form

Re: ModelForms and the Rails input handling vulnerability

Hi list, as I use "exclude" most of the times (to hide sensible fields from the user) I don't like the idea of this beeing removed. Perhaps another solution might be to force developers to either define fields _or_ exclude, so you have to at least think about this..without going through too much

Re: ModelForms and the Rails input handling vulnerability

On 06/13/2012 12:57 PM, Anssi Kääriäinen wrote: > The point is the same form with the same fields can be used in > multiple places. There is no need for dynamic addition and removal of > fields in Python code. The dynamism is in which fields to display - > not which fields the form contains. You

Re: QuerySet refactoring

On 13/06/12 17:15, Luke Plant wrote: > I think this is a very necessary piece of work. The problem with that > layer of code is that it is very difficult to really grok and therefore > to review patches. It would take almost as much effort to do a review of > a substantial patch as the patch

Re: ModelForms and the Rails input handling vulnerability

Hi all, Can I throw in option 5: We leave ModelForms as they are, but emit a warning if you only partially render the form? I'm not sure how feasible this is, but presumably we could keep track of which fields have been rendered for a given form instance? That way, if you render the whole

Re: ModelForms and the Rails input handling vulnerability

Hi Peter, On 06/13/2012 02:55 PM, Peter wrote: > Can I throw in option 5: > > We leave ModelForms as they are, but emit a warning if you only > partially render the form? > > I'm not sure how feasible this is, but presumably we could keep track of > which fields have been rendered for a given

Re: ModelForms and the Rails input handling vulnerability

On Wed, Jun 13, 2012 at 5:05 PM, Carl Meyer wrote: > Hi Peter, > > On 06/13/2012 02:55 PM, Peter wrote: >> Can I throw in option 5: >> >> We leave ModelForms as they are, but emit a warning if you only >> partially render the form? >> >> I'm not sure how feasible this is, but

Re: ModelForms and the Rails input handling vulnerability

On 06/13/2012 06:12 PM, Doug Blank wrote: > On Wed, Jun 13, 2012 at 5:05 PM, Carl Meyer wrote: >> On 06/13/2012 02:55 PM, Peter wrote: >>> Can I throw in option 5: >>> >>> We leave ModelForms as they are, but emit a warning if you only >>> partially render the form? >>> >>> I'm

Re: ModelForms and the Rails input handling vulnerability

On Jun 13, 2012 8:12 PM, "Doug Blank" wrote: > > I, too, was thinking about this kind of solution. In fact, it came up > for me the other day because I had forgotten to exclude a field that I > did not have on the form, and so the value ended up getting wiped out > when I

Re: ModelForms and the Rails input handling vulnerability

Hi All, I can see two separate (but related) problems that need to be solved: 1. Ensure that sensitive fields are not accidentally exposed to users (e.g when a database model is updated to include one), and 2. Provide a means to confirm whether the fields as rendered and submitted exactly match

Ticket #18471: Add a localization field option in Model Fields.

Hi, I have opened the ticket #18471 to request the inclusion of a new option for localization to the Model Fields. Currently the localization of the Model Fields is a complex process that involves the utilization of ModelForms, it can be simplified

Re: ModelForms and the Rails input handling vulnerability

On 14 kesä, 03:12, Doug Blank wrote: > I, too, was thinking about this kind of solution. In fact, it came up > for me the other day because I had forgotten to exclude a field that I > did not have on the form, and so the value ended up getting wiped out > when I saved. So,

Re: ModelForms and the Rails input handling vulnerability

Hallöchen! Alex Ogier writes: > [...] > > That suggests an idea to me. Perhaps the best way to check this > isn't on the way out in the template renderer, but rather on the > way back in in the form validation. If the form doesn't get back > exactly those fields it sent out then you know that