Re: ModelForms and the Rails input handling vulnerability

[Doug Blank]

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 presumably we could keep track of
>> which fields have been rendered for a given form instance?
>>
>> That way, if you render the whole form ( {{ form.as_p }} ) you'll see
>> your new sensitive field appear in the page. If you manually render the
>> form, you'll get a warning.
>
> I've thought about this. The main problem is that the implementation is
> quite difficult in practice: at what point do you perform the check?
> There isn't any such thing as an "ok, I think I'm all done rendering
> this form now, tell me if I did it right" hook.

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, perhaps a solution that prevented others from adding
fields could also be a solution that checked to make sure that the
form was editing all fields it should be.

What about a {% validate %} tag in the form which would do a runtime
check to make sure that all non-excluded fields had been rendered?

-Doug

> There's at least one third-party app out there that does this
> (https://github.com/ulope/django-careful-forms), but it registers all
> forms in a thread-local and performs the check in a middleware; that's
> not something I think belongs in core Django.
>
>> One problem would be excessive warnings if you went further and hand
>> craft the HTML - does anyone do that?
>
> Yes.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>

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

Re: Admin interface not preventing simultaneous editing of the same record

[Doug Blank]

On Aug 12, 12:17 am, David  wrote:
> On Aug 12, 12:06 am, Russell Keith-Magee 
> wrote:
>
> > Another cause for hesitation is that it would be an admin-specific
> > solution to the problem. A generic solution that would work for all
> > ModelForms would be nice if it is possible.
>
> Agreed. I shall look at that first since it's more generally useful.

New Django user here, but also a developer on other Python projects: I
thought that I'd mention a couple of points.

For our use of his feature, we don't need to see what the data was,
but a diff of what we would like to save, and the way the data is now
would be useful. I imagine it might work like this: "The data you are
attempting to save has changed since you began your edit. You have the
option of a) using your version and overwriting the other data, b)
aborting your edit, or c) revising your edit based on the differences
below. Your data is: ... Current data is:..."

It would be nice if this were an option which could easily be added on
a view; however, there would be some fields that you wouldn't want/
need to check for changes. For example, an update that would timestamp
a field would not need to trigger this condition. So the view-level
options should include a list of fields to ignore. Perhaps it could
also take a function name for adding a custom saving conflict manager.

My $.02.

In any event, thank you all for a beautiful project!

-Doug

--~--~-~--~~~---~--~~
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: NDjango - .Net port of Django template langauage

[Doug Blank]

On Tue, Sep 22, 2009 at 2:20 PM, Michael Feingold wrote:

>
> That's what we started with. It did not work out. While IronPython (as
> well as some other implementations of Python) are available in .Net,
> integrating an app written in Python with anything else written in any
> other .Net language proved to be a big challenge. You can run a Python
> app on .Net platform, but it still lives in its own world
>
>
That is not so much the case any more... you can now call Python functions
from other DLR scripting languages. So, you could conceivable run the Django
template parser in IronPython from IronRuby, for example. And with the new
dynamic syntax in .NET 4, this could work from F# too.

In any event, good luck with your project.

-Doug



> On Sep 22, 1:11 pm, Dj Gilcrease  wrote:
> > I dont know all that much about .Net but isnt the point of it that all
> > the .Net languages can be used together? eg using C#.Net components in
> > a VB.Net app and such.
> >
> > So why not just use the django template language as is via IronPython
> > instead of trying to port it to another language?
> >
>

--~--~-~--~~~---~--~~
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: Multiple database support: Request for feedback and testing

[Doug Blank]

On Fri, Dec 4, 2009 at 6:31 AM, Russell Keith-Magee
 wrote:

[snip]

>  1) Do nothing special. This is the currently implement behaviour.

As the default, this seems to be the intended behavior only in rare
cases (overwriting a different object from the original) and will
indeed bite.

There is another option: leave in the hands of the user (as you say)
but make them explicitly say which behavior they want of the
following:

>  2) Set the primary key of the object to None so that the save on the
> new database is guaranteed to be an insertion, rather than a possible
> overwrite of an object with the same pk value on the second database.
>
>  3) Transform the save into a 'force insert' if the database changes.
> This will raise errors if the pk is already in use on
>
>  4) Use the PK on the old database and issue a deletion before saving
> to the new database.

If they didn't explicitly indicate which of these to do, then raise an error.

Just a thought.

-Doug

[snip]

> I'm open to any other suggestions - and for any offers to help out :-)
>
> Russ %-)

--

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.