Provide built-in authentication method for public webinterface

[pyrocumulus]

The docs state that a public facing web interface poses a danger and it highly recommend to password protect the interface. However if you want to do that, it would mean creating a ssh session to the dsmr and configuring quite some stuff with htpasswd and nginx. This will work but I feel it would be beneficial to make this process easier.

In my opinion the application could also provide this functionality directly, as it already does so for the Configuration-pages. It would make it easier to protect the interface and will make sure that the device environments don't get to differ too much because it's all configuration of the application itself.

I can imagine that this will not have the highest of priorities but I do feel it would benefit DSMR.

[dennissiemensma]

Bedankt voor je suggestie! Ik heb het ooit wel overwogen in het begin, maar het punt is dat ik dan simpelweg élke URL achter een wachtwoord-wall moet zetten, en dan ook nog eens optioneel/configureerbaar. Plus alle tests bijwerken. Voor de admin/configuratie-pagina's is dat vrij simpel omdat het ingebouwde admin-functionaliteit van Django zelf is.Vandaar dat de functionaliteit daar wel (standaard) aanwezig is.

Dit project gaat er vanuit dat gebruikers de applicatie intern draaien. Mocht er wel behoefte zijn om het publiekelijk te draaien, dan blijft de aanbevolen methode van afscherming via de webserver (of welke proxy er dan ook voor staat). Het is relatief weinig werk en garandeert dat elke URL afgeschermd is. :]

[pyrocumulus]

Ik begrijp je kant van het verhaal, het zij zo :) Nu heb ik dan toch die instructies maar even geprobeerd maar zodra ik dat gedaan heb, krijg ik alleen nog server error 500 te zien. De authenticatie van Nginx via de htpasswd gaat wel af maar zodra ik dat inlogdialoog voorbij ben alleen nog een error. Zo te zien ongeacht de opgevraagde pagina.

De tail van het dsmr_webinterface proces laat helemaal niets zien geen enkele error. De error pagina die ik zie is ook nogal ruw en lijkt gewoon uit Nginx te komen. Ik weet niet precies waar ik dit moet zoeken, maar zou het kunnen dat de instructies voor dit stuk niet meer helemaal up to date zijn?

Ik heb het ook geprobeerd met een ongewijzigde SECRET_KEY maar dat hielp niet. Enige wat hielp was de auth_basic en auth_basic_user_file van de site configuratie van Nginx weer in commentaar zetten. Uiteraard heb ik wel die htpasswd aangemaakt en het pad lijkt ook te kloppen.

Weet even niet hoe nu verder, is er een log van Nginx of zo die ik kan checken?

[pyrocumulus]

Ai, te vroeg ingeschoten. Ben er denk ik al achter:
Nginx gives an Internal Server Error 500 after I have configured basic auth

Er staan inderdaad crypt_r() failed errors in de log van Nginx in /var/log/nginx/error.log

Misschien is die transip htpasswd generator geüpdatet en levert ie nu wachtwoorden op middels bcrypt ipv md5 hashes? Klinkt een stuk veiliger maar het lijkt erop dat de Nginx installatie die op mijn Rpi2 draait dat niet aan kan. Ik ga het later nog eens proberen met een md5 generator maar dit zou het goed zijn.

[dennissiemensma]

Bedankt voor het melden, het zou in één keer moeten werken. Het lijkt er inderdaad op dat de generator van TransIP inmiddels is veranderd.

Deze andere tool werkt wel en ik zal de docs daarop bijwerken: http://www.htaccesstools.com/htpasswd-generator/

[dennissiemensma]

Uitgebracht in de nieuwe release.

[FutureCow]

Wellicht dit stukje ook nog toevoegen aan de nginx conf:

satisfy    any;
allow      192.168.1.0/24;
deny       all;
auth_basic "Restricted application";
auth_basic_user_file /etc/nginx/htpasswd;

op die manier kun je lokaal verkeer altijd toe laten en alleen van buitenaf met user+pass?

[dennissiemensma]

Dankje, ik heb #455 voor je gemaakt.

[pyrocumulus]

@FutureCow fijne tip! 👍 Heb ik meteen even toegepast. M'n reverse proxy in de deny en rest van m'n lokale netwerk op basis van subnet in allow gezet. Werd stiekem ook wel beetje gek van die HTTP auth als ik gewoon thuis was.