Automatisches redirect auf WEB bzw WEBphone u. Anmeldedaten speichern iOS/iPhone

Begonnen von rapster, 02 Dezember 2014, 23:19:32

Vorheriges Thema - Nächstes Thema

rapster

Hi Zusammen,

da mich einerseits das dauernde neu eingeben der Anmeldedaten auf meinen iOS Geräten recht genervt hat (aufgrund des verwendeten Basic-Auth's),
und da ich nicht zusätzlich immer den jeweiligen Port für WEB bzw. WEBphone eingeben wollte, habe ich mir auf meiner FHEM-Kiste noch einen kleinen apache installiert der diese Probleme löst.

Der Apache hat lediglich den default-vhost konfiguriert, welcher je nach verwendetem UserAgent die Website mit Port auswählt.
So muss man sich nurnoch seine adresse merken (z.B. https://meinfhem.de) und der apache zeigt einem dann vom normalen Firefox z.B. http://meinfhem.de:8083 bzw. http://meinfhem.de:8084 auf dem iPhone an.

Desweiteren habe ich das BasicAuth in Fhem deaktiviert und über das Attribut 'allowfrom 127\.0\.0\.1' den Zugriff auf die lokale Loopback-Adresse begrenzt.
Jetzt geht die komplette Anmeldung über das apache mod_auth_form Modul, wodurch die Speicherung der Zugangsdaten / Passwort auch auf iOS Geräten möglich ist. (Siehe angehängtes Bild.)

Als Beispiel habe ich meinen default-vhost für den apache sowie die Login-Form angehangen. Manche Einstellungen (wie z.B. die Einbindung der SSL-Zertifikate habe ich bei mir in der globalen apache2.conf, da gibts aber auch nichts spezielles für dieses Thema zu beachten.)

Die Datei FhemLogin.html muss einfach nur im DocumentRoot des vhosts abgelegt werden. Den rest macht der Apache ;)
Das benötigte .htpasswd File lässt sich über den Befehl "htpasswd -c /opt/fhem/apache.htpasswd myusername" erzeugen
Im Moment sind nur 2 RewriteRules eingetragen für WEB und WEBphone, lässt sich allerdings auf die selbe Weiße mit einer RewriteRule für z.B. WEBtablet erweitern.

Benötigt für die Apache-Form-Authentifizierung werden die Apache-Module: mod_session, mod_auth_form, mod_request, mod_session_cookie, mod_session_crypto, mod_authn_file, mod_authn_core
Für die Proxy Funktionalität: mod_proxy, mod_proxy_connect, mod_proxy_http, mod_rewrite
Und für SSL natürlich: mod_ssl, und evtl. mod_socache_shmcb (oder was verwendet wird)
...die restlichen benötigten Module sollten denke ich Standard sein, falls eines fehlt bemängelt dies der Apache allerdings beim Start.


Evtl. kann es ja jemand gebrauchen, da ich hier im Forum schon öfter die Frage bzgl. der Anmeldedatenspeicherung gesehen habe, und teilweise wilde Lösungen wie http://user:pw@fhem.de dazu auftauchten...


Gruß Claudiu

P.S. Die LoginForm ist ein freies Template von codepen.io, welches ich nur etwas für meine Bedürfnisse angepasst habe.

rudolfkoenig

Weisst du, warum iOS das Passwort-Abspeichern fuer basicAuth nicht anbietet?

rapster

Das ist eine generelle Limitierung von iOS, glaub bis iOS 3 konnte man basicAuth noch speichern.
Gibt aber leider nichts was fhem tun könnte um dieses Verhalten zu ändern  :(

P.S.
Hier noch eine weitere Version des Apache-Vhosts, falls man Dienste verwendet die BasicAuth zwingend benötigen (z.B. geofancy).

In diesem vhost werden request an http(s)://fhem.domain.tld/fhem/geo mit basicAuth abgewickelt, alle anderen Seiten/URL's werden über die Form-Authentication abgewickelt.


Luco

Hallo Rapster,

der Thread ist zwar schon was älter, ist aber genau das was ich suchte.
Leider habe ich Probleme die ganzen benötigten Apache Module zu installieren auf dem Raspberry. Hast du eine Idee wie ich die ganzen Module installiere?
Sowas wie: apt-get install libapache2-mod-proxy-html nur halt für die ganzen anderen Module

Danke im Voraus

rapster

Hallo Luco,

welche Linux-Distribution verwendest du?
Normalerweise sind die ganzen Module schon bei der Apache Installation mit dabei.

Bei Debian z.B. sollte es einen Ordner ../apache2/mods-available geben, einfach ein "ln -s" in ../apache2/mods-enabled machen um die entsprechenden Module beim Start von Apache zu laden.

andies

Das ist nun schon zwei Jahre her, keine Ahnung, ob hier noch jemand mitliest. Ich möchte genau das tun, was OPs Problem war: Speicherung von Passwörtern. Und ja, ich habe in der Tat http://login:passwd@usw verwendet...

Nun kenne ich mich mit Virtual Hosts nicht aus und bin daher zögerlich sofort umzusetzen, was da steht. Auf meinem RPi ist nginx installiert. Ich habe das mW nicht gemacht (eventuell geschah das durch FHEM)? In jedem Fall stellt sich mir die Frage, ob ich nun einfach apache2 "darüber" installieren kann oder nicht dann beide Webserver einander in die Quere kommen? Oder kann ich diesen ReverseProxy in nginx konfigurieren?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

rapster

Entweder nginx oder Apache,

Die Beispielkonfig ist für Apache.
Das ganze lässt sich natürlich auch über den nginx bereitstellen.

andies

Sorry, ich muss nochmal nerven. Leider habe ich Schwierigkeiten, die Dokumentationen zu verstehen; manchmal sind die etwas rudimentär. Also ich habe mir bei Letsencrypt ein Zertifikat besorgt:
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/XXXXXXXXXXX.selfhost.bz/fullchain.pem.
   Your cert will expire on 2017-07-YY. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"

Meine reverse-proxy sieht dann so aus:
server {
    listen 80;
    return 301 https://$host$request_uri;
}

server {

    listen 443;
    server_name fhempi;

    ssl_certificate           /etc/letsencrypt/live/XXXXXXX.selfhost.bz/fullchain.pem;
    ssl_certificate_key       /etc/letsencrypt/live/XXXXXXX.selfhost.bz/privkey.pem;
##da liegen die Dateien auch wirklich, geprueft

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    access_log            /var/log/nginx/jenkins.access.log;

    location / {

      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;

      proxy_pass          http://localhost:8083;
      proxy_read_timeout  90;

        auth_basic "Restricted Content";
        auth_basic_user_file /etc/nginx/.htpasswd;

      # proxy_redirect      http://localhost:8083 https://localhost;
    }
  }

zuletzt habe ich nginx neu gestartet
sudo service nginx reload
Ich war jetzt davon ausgegangen, dass https://xxxxxxxx.selfhost.bz bereits funktioniert (Port 80 ist freigegeben und wird von außen direkt auch Port 80 am Pi weitergeleitet). Das geht aber nicht. Ich mache sicher etwas falsch oder vergesse etwas, weiß aber nicht was?

<EDIT> Die Fehlermeldung war jetzt nicht so präzise. Also ich rufe meine Adresse XXXXX.selfhost.bz:8084 auf und werde nicht auf eine https-Seite umgeleitet:


Im Verzeichnis /etc/nginx/sites-available liegt doch eine Datei default, könnte es an der liegen?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

rudolfkoenig

ZitatPort 80 ist freigegeben und wird von außen direkt auch Port 80 am Pi weitergeleitet
...
ZitatAlso ich rufe meine Adresse XXXXX.selfhost.bz:8084 auf und werde nicht auf eine https-Seite umgeleitet
80 oder 8084?

andies

Ich hatte sowohl 80 als auch 8084 getestet. Inzwischen glaube ich, dass eine falsche Konfiguration meinerseits die Ursache ist; ich komme nur momentan nicht dazu, mir das in Ruhe anzuschauen. Aber wenn wir schon mal so weit sind, eine Frage des Laien:

Wenn ich http://sowieso:80 aufrufe und intern ein Proxy eingerichtet ist, der die Anfrage auf 443 umleitet, wird dann daraus die Adresse https://sowieso:443? Also ist der Port entscheidend dafür, dass verschlüsselt wird? Oder muss das intern dem Webserver noch mitgeteilt werden?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

rudolfkoenig

Das Protokoll muss man mW angeben, Port duerfte alleine nicht reichen. Was hinter 8083 konfiguriert ist, das kann apache/nginx schlecht raten. In Apache schaut die Umleitung so aus:
ProxyPass        /fhem  http://localhost:8083/fhem
ProxyPassReverse /fhem  http://localhost:8083/fhem

und in deiner Config wird die Adresse auch komplett mit Protokoll spezifiziert

andies

So, ich habe das endlich geschafft - sichere Verbindung steht. Ich versuche mal aufzuschreiben (und so nachzuvollziehen), wie das ging.

0) Mit https://letsencrypt.org/ entsprechende Zertifikate (zwei .pem-Dateien) für <meine-domain> erstellt und in die gleich aufgeführten Verzeichnisse kopiert.

Anmerkung: Die müssen spätestens alle drei Monate erneuert werden, geht mit cronjob
02 03 15 */2 * /home/pi/certbot-auto renew  --non-interactive --no-bootstrap && sudo /etc/init.d/nginx reload

1) Im Modem/Router (hier: Speedport) eine Umleitung von <meine-domain>:8084 auf <interne-IP>:443 eingerichtet.

2) Im RPi nginx so konfiguriert, dass a) http-Anfragen auf https umgeleitet werden und b) diese wiederum durch die erwähnten Zertifikate gesichert sind. Dazu musste im Verzeichnis /etc/nginx/sites-available eine Datei reverse-proxy angelegt werden (in der darüber liegenden nginx.conf wurde diese bereits eingebunden - bitte nachprüfen!). Diese Datei enthält bei mir folgenden Inhalt:
server {
    listen 80; # block http://
    return 301 https://$host$request_uri;
}

server {
    listen 443;

    server_name <meine-domain>;

    ssl_certificate           /etc/letsencrypt/live/<meine-domain>/fullchain.pem;
    ssl_certificate_key       /etc/letsencrypt/live/<meine-domain>/privkey.pem;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    access_log            /var/log/nginx/jenkins.access.log;

    location /fhem {
      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-Proto $scheme;

      proxy_pass          http://localhost:8083;
      proxy_read_timeout  90;

      auth_basic "Restricted Content";
      auth_basic_user_file /etc/nginx/.htpasswd;

     # proxy_redirect      http://localhost:8083/fhem https://<meine-domain>:8084/fhem;
    }
  }


Die erste Serverdirektive sorgt dafür, dass http in https geleitet wird. Die zweite Serverdirektive bindet dann die Zertifikate ein. Anfragen an <meine-domain>:8084 gehen dann auf den RPi und die dort liegende FHEM-Installation auf Port 8083. 

Zuletzt noch die global-Attribute löschen.

Und dann endlich das hier im Browser:
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

PS Damit events auf dem Bildschirm sofort angezeigt werden und man nicht ein refresh machen muss, war es nötig, dass ich noch folgendes  einfgen (habe ich aus dem Wiki)
location /fhem {
proxy_pass http://meinfhemserver:8083/fhem;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_buffering off;
proxy_ignore_client_abort off;
break;
}
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann