I am working on a website that should not be open for public viewing. I'm currently developing on my local computer using manage.py and runserver.

However, I want to make the site publicly accessible to only a few certain people. These people are not developers, so they don't need access to the code. Also, since they aren't devlopers, it should be a somewhat user friendly solution. They just need access to view my current changes 24 hours a day.

I considered trying to do something with ALLOWED_HOSTS, but these people are on the go and login from many different IPs, some of which I'm sure are dynamic.

I considered setting the landing page as a login, but the website already has a complicated login system with multiple user types that these people will need to create multiple accounts to view and test different website features. Creating a separate login just for overall website access and then having the ability to still login to test other accounts seemed like way too much overhead and not user friendly. I figured there must be a better solution.

So, what is the best way to share a Django website to a limited non developer audience during development while ensuring that the random public doesn't have access? Is there a package or service that does this?


  • Just deploy it as you eventually will to production, e.g. nginx, gunicorn, etc., but to the private server. – Michael Hampton Feb 19 at 19:55

One possible idea is to give testers client-side X509 certificates.

  • A person enters their certificate and private key into their browser. In my Firefox it's in Preferences -> Privacy -> scroll to the very bottom -> View Certificates -> tab Your Certificates -> Import
  • Your end of SSL/TLS connection (nginx reverse proxy, haproxy, apache, etc) although listens on a public 443 port, is configured not only to serve the usual server-side certificate, but also to require a successful verification of a client-side certificate (you configure to only accept tester's certificates obviously).
  • These are advanced SSL/TLS options on your end, so for example AWS ALB implementation of https is insufficient.
  • Only https usage can be authorized this way, not plaintext http.
  • This doesn't impact contents of http GET/POST/cookie at all, therefore it doesn't impact authentication schemes at these levels.
  • Unauthorized browsers display an SSL/TLS error - they cannot pass any GET/POST whatsoever.
  • This seems to be exactly what I was looking for. Thanks for the response. – Lucas Feb 19 at 23:35
  • This answer could be improved by explaining why it is worth the effort over simply sending them an HBA link like https://user:pass@domain.example/app. – anx Feb 20 at 0:28
  • @anx That's another good option, worth a separate answer. – kubanczyk Feb 20 at 0:29

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.