LOCKDOWN_URL_EXCEPTIONS with subdomain?

[Steve P. Sharpe]

Hi there!

I'd like to lockdown on a staging site, however the API needs to be open at api.domain.com. I currently use django-hosts (https://github.com/jezdez/django-hosts). Is it possible to match the 'api' subdomain inside of LOCKDOWN_URL_EXCEPTIONS?

Thanks
Steve

[Daniel Roschka]

I'm not familiar with django-hosts and currently a bit short on time as well. I'll try to look into that next week.

[Steve P. Sharpe]

Great, thank you!

[Steve P. Sharpe]

I'm pretty new to Python, so I'm not 100% how to write the tests otherwise I'd submit a pull request, but this might work inside of process_request in middleware.py

if settings.SUBDOMAIN_EXCEPTIONS is not None:
    subdomain = request.get_host().split('.')[0]
    if subdomain in settings.SUBDOMAIN_EXCEPTIONS:
        return None

The add this to settings.py

SUBDOMAIN_EXCEPTIONS = getattr(settings, 'LOCKDOWN_SUBDOMAIN_EXCEPTIONS', ())

Then you could just use the following inside of the apps settings.

LOCKDOWN_SUBDOMAIN_EXCEPTIONS = ('api',)

[Daniel Roschka]

To rephrase the difficulty with my own words: django-lockdown currently only cares about the path component of an URL. All other components, like the host, are completely ignored, when considering if the URL should be locked or not. That matches Djangos behavior: Django also routes requests solely based on the path component of an URL. django-hosts extends that behavior by adding "hostconfs" in addition to Djangos "urlconfs" to enable serving multiple websites with different urlconfs from the same django installation.

From my point of view it's difficult to extend the current behavior of django-lockdown in a clean way. Your approach would solve your particular problem, but not the underlying limitation. E.g. one wants to check for the whole host (which still would be easily solvable by slightly modifying your implementation to check the whole host and not just the subdomain), for the scheme, the port or any other URL component. How to handle that properly? By introducing a new configuration option for each URL part? And what if one only wants an exception for a combination of multiple URL parts? I don't think that's an approach which would work out well.

I'm also not sure if it's beneficial to support more capabilities in terms of routing requests in django-lockdown as Django itself does. We simply can't support all functionality added by other third party applications to Django and it would increase the complexity of the code as well.

So for now I would like to not include the functionality you proposed, but you should consider one of the following options, which might or might not be an option for you depending on your use case:

• Split your websites into two django installations and abandon the use of django-hosts at all. You can still use the same code base, but have to choose different urlconfs depending on which installation it is. That might also make scaling easier later on.
• Use a patched version of django-lockdown. Cumbersome if you want to stay up to date with future improvements.
• Handle the locking of websites on the webserver side. As I don't know your exact use case, that might be cumbersome as well or not even possible at all.

I hope that information helps you to decide how to proceed.