What are some possible uses for Django's IPAddressField?

Question

What are some common reasons, or example cases, in which storing the user's IP address in a model instance would be useful? I can't think of any off the top of my head.

Reading through Django's now-deprecated Comments framework, I see that they stored the commenter's IP address in a GenericIPAddressField within the Comment model. Why? What's the point of storing it?

Answer 1

In the case of the Comments app, or apps like it, it is often useful to know the IP address of commentators for spam or abuse reasons. You may also want to know if someone is pretending to be someone else by posting under different usernames but using the same IP address. Or if they post something abusive or illegal you can ban their IP address. It is sometimes used to detect spam. If you are running a forum that caters to a small group in one part of the world it may be surprising to receive comments from the opposite side of the world. They can also be gathered for statistics and logging purposes.

Answer 2

Several uses come to mind:

1. Banning IP address of uncompliant users.
2. Associating tokens to IP address of user who've paid for some service
3. Manager interface of some network applications
4. (More general) Any network related application which interface is written in Django
5. Maybe some online game.

At the end of the day, IPAddressField is just another CharField with some restrictions, someone took the time to code it because he/she needed it and why not to include it in Django's Repertoire? :)

EDIT: I know all about circumventing this IP restrictions with proxies, etc, but, for less savvy users this might be effective, and for more savvy users this may be some pain in the... restrictions :)

Answer 3

I'm using this field in one of my models, so let me share the use case here. There is a web API which used to be freely available over the web. But now, we want to add authentication layer in it; without changing the way our end users have integrated it. Adding new authentication parameters will require changes at our client's end, so that was not an option.

Finally IP based authentication seemed the most feasible solution. For that I need to store the IP address of the client and authenticate whenever the request comes from a registered list of IPs.