On Wed, Dec 30, 2015 at 5:14 AM, Billu <billu.man...@gmail.com> wrote:
> Wouldn't it be much easier to just check the IP (or mac) addresses of the > request and if it matches the allowable ip(s), then allow otherwise deny? > > That's the super short and incomplete version of my response. My answer went more into depth about the various methods to do so. MAC addresses are only relevant if a) all of the machines exist within the same Ethernet segment/VLAN and b) only if you have a host or hardware firewall capable of making policy decisions based on MAC address. Django will never see the MAC address, as it is stripped away by the OS prior to the request being processed. TL;DR; You'll probably never refer to MAC addresses and Django security in the same sentence. "Just check the IP" is missing the vital answer of "how", which is a key portion in the first line of the OP's question. I suppose my answer did leave out the ability to check the IP at the Django level and make decisions based on that information. Given the multiple ways that an IP address may be made available to a Django application, I would recommend a package such as django-ipware ( https://github.com/un33k/django-ipware) which handles a majority of these situations in a DRY manner, although I've never used it myself. The IP checking would be made part of your authorization checks that should be run for each request cycle. That implementation is specific to your environment, so I can't really comment further, although Django 1.9 made some great strides in making such permission checks easy to integrate. For <1.9, these checks would probably muddy up your code, but are still possible, especially if django-braces is used (which is the package that the authorization changes to 1.9 are modeled after). I doubt I would ever do source IP checks in the application. That's what firewalls are for. Honestly, I'd much rather go with a true API key system, as it is much more flexible (especially if your API consumers live in multiple IP address segments that may/probably will change over time) and provides similar protection. If you find a trusted host is compromised, you simply invalidate the API key. Other processes using a different API key can continue to function from the same host. With strictly IP checking and no other authorization, you have to block the host entirely, which may or may not be acceptable. Full disclosure, I'm a network administrator by trade, so I'm generally biased towards network-level protections, and under the (usually correct) assumption that most application developers do a poor job of securing their applications, even when those applications cost more than a year's salary in licensing and are backed by Fortune 500 companies. Not that all applications are that way, but personal experience has left me a bit cynical and distrusting. Heck, we have big-money applications that still send service credentials across the network using straight HTTP and no encryption. App admins get mad when they create a new service account, and five minutes later you pull it off the network and read the password back to them while troubleshooting. Fun for me, though. :-D -James -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciUo2abWpuQp_q_eFJXn1bFtS2QSFr0-OnLZOTfm%2BOa_%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
