Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
User Agent Detection #31
I've used this package on several sites now and have run into two different, related problems:
First, I built an internal business application that ran into problems because the company's internal firewall was making a GET request to the login code URLs before passing it along to the user's browser, resulting in a 404 because the firewall's request invalidated the login code. This is, of course, exceptionally annoying IT behavior, but my workaround was to customize the login view to detect their firewall's IP and simply return a 200 to it.
Second, I recently found (and blogged about) an issue where applications that use Facebook App Links can cause Facebook to make a GET request to any URL clicked in the application, also invalidating the login code. This is, of course, also exceptionally annoying behavior, and my workaround was to use the user-agents package to return a HttpResponseForbidden to invalid user agents. Here's my modified
I don't know if there's anything that could be done within django-nopassword to handle these situations better. It seems heavy-handed to require user-agents as a dependency (along with it's dependencies, as it uses ua-parser), but the alternative would be to bundle some basic user agent detection into django-nopassword, which seems outside of the scope. On the other: this could effect a lot of people using this package so maybe it's worth it?
Likewise, the first situation above, that of the evil corporate firewall, could be solved by possibly adding a ip address blacklist setting. On the other hand, that also could be seen as outside the scope of this package.
Maybe the solution is just documentation explaining how to work around each of these scenarios?
What do you think? This has affected me on multiple occasions so I'm happy to help out with some solution, but I'm not sure what the best solution would be.
Thank you for reporting this! I think that some blame should go to django-nopassword for not following the http standard. It currently changes state on a GET request, which is not allowed and at least not optimal. I just haven't thought about it before now.
The first solution fixing that problem that I can come up with is to do an ajax POST request on the page and use