Opened 19 years ago

Closed 19 years ago

Last modified 17 years ago

#1242 closed enhancement (wontfix)

New ClientIP Fieldtype?

Reported by: chmod Owned by: Jacob
Component: Generic views Version: dev
Severity: normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Problem

Your model is simple enough to use the generic view create_update. However, it requires an IP address (comment form, forum post, feedback etc...).
Letting the template put something like
<input type="hidden" name="ip" value="{{ ip }}"/>
in your form is a big no-no. Anyone could easily download your page's form, change the "ip" field to something bogus, are then post the form. In a perfect world (where django is taking us), the ip is gathered server-side, after the post has been submitted, but before adding it to the database.

Proposed Solution 1

Add a new field type to core/meta/fields.py called ClientIPAddressField. This field would extend the existing IPAddressField class, and be the same in every way, except one. In create_update it would check if any fields were instances of ClientIPAddressField, and automatically populate them with request['META']['REMOTE_ADDR'] Then the ip of the submitter could be more trusted since it didn't come as a POST element. And you still get to use a generic view.

Proposed Solution 2

Modify IPAddressField to accept a keyword argument much like auto_now[_add] for the datetime fields. The keyword argument could be called "auto_fill_client" and maybe even "auto_fill_server". And would be handled in the generic views as described above.

Conclusion

I haven't worked on django's internals much as of yet. But I think this would be very useful, considering how many simple models there are out there that just need the client's IP address. Thank you for reading, and please offer other suggestions!

Change History (1)

comment:1 by Adrian Holovaty, 19 years ago

Resolution: wontfix
Status: newclosed

This couples the field type to the request, which is a no-no.

Note: See TracTickets for help on using tickets.
Back to Top