geschützte WP Webseite: restricted-site-access vs. .htaccess

[unleash_it]

hallo und guten Tag,

es geht um eine passworgtgeschützte Webseite: WP-Plugin: restricted-site-access vs .htaccess/.htpasswd-Lösungen im Vergleich: die Besonderheit: möglichst sollte die Sitzung dann 2 bis 3 std. offen sein

Hintergrund: ich will eine (Wordpress-) Webseite durch ein passwort im Zugang sichern - m.a.W. man soll nur zugang bekommen - wenn man durch die Passwortkontrolle geht: es soll lediglich ein einziger Benutzer angelegt werden: Die Seite ist noch neu - und in Entwicklung. Ich will sie auf dem Server hosten u. nicht (nur) auf einem XAMPP-System.

es gibt hier mehrere Optionen - auf die ich unten eingehe:

a. die .htacces/htpasswd-Kombination oder
b. ein Wordpress-Plugin: How to Restrict WordPress Site Access by IP or Logged In https://de.wordpress.org/plugins/restri ... te-access/

Metadaten: Version:7.2.0
Aktive Installationen:20.000+
WordPress-Version:4.6 oder höher
Getestet bis:5.3.3
Schlagwörter:privacy restrict


Beschreibung:
mehr dazu unten...

daneben gibt es dann immer noch die Lösung mit .htaccess und .htpasswd:

Als erstes denke ich, ist die Anlage einer .htpasswd Datei in einem Verzeichnis notwendig: dabei glaube ich ist es wichtig dass diese Datei im Grunde auch abseits der darauf verweisenden .htaccess Datei liegt Also es ist im Grunde so gedacht dass die .htpasswd nicht das Verzeichnis und deren Unterverzeichnisse in der die Datei liegt absichert, Nein - es ist vielmehr so, dass die Datei eine Liste bzw. ein 'Inhatsverzeichnis darstellt - aller möglichen Zugangsdaten. Absichern tut die .htaccess Datei. Sie - also die .htacess-Datei übernimmt die eigentliche Sicherungsaufgabe das Verzeichnis und aller darunter liegenden Unterverzeichnisse mit einem Passwortschutz versehen. Aus diesem Grunde ist es glaube ich auch wichtig - wo die .htacces datei abgelegt wird.

.....generell ist es so, dass das mit htpasswd generell geht: um das Verzeichnis, das man schützen will, muss man eine .htaccess-Datei. einrichten:
Um einen solchen Passwortschutz einzurichten, braucht man generell folgende Anweisungen wie z.B. AuthType, AuthName, AuthUserFile, und wenn auch mit einem Benutzergruppen arbeiten will dann noch mit AuthGroupFile. Ferner benötigt man wenn der Zugriff auf bestimmte Benutzer oder Gruppen aus diesen Dateien festlegt (also einschränken) sein soll, eine oder mehrere Angaben der Anweisung Require.
AuthType bezeichnet die Art der Authentifizierung. Webserver/htaccess/Passwortschutz –
Also - bei meiner Aufgabe handelt es sich um eine Wordpress-Seite- Da gbibt es schon ein HTACCESS. Deshalb denke ich dass ich die .htaccess Datei anpassen muss. So oder so muss folgender Code in die Datei rein:

.htaccess-Datei für Passwortschutz

Code: Select all

# .htaccess-Datei für Passwortschutz
AuthType Basic
AuthName "Geschützter Bereich - jetzt ein Passwort eingeben!"
AuthUserFile /Individueller/Pfad/.htpasswd
Require valid-user0


Erläuterungen: vgl. auch



vgl hier. https://wiki.selfhtml.org/wiki/Webserve ... wortschutz

Aber nun die Sonderlösung und die Spezialaufgabe bzw. Frage: Was ist - wenn ich diese Passwortsicherung etwas aufwändiger haben will -also etwa so dass immer wenn ich die Seite betrete nach dem Passwort-Eingeben.

- ich dann die Seite offenstehen hab auf meinem Rechner?!
- also dass die Seite für 2 oder drei Stunden offen steht
- auf meinem aufrufenden Rechner


Zwischenbemerkung zum .htacces angesichts dieser Sonderaufgabe - dass hier eine Sitzung mehrere h offen sein soll, denke ich nicht das hierfür eine schlichte und konventionelle basic HTTP-Authentication dafür ausreicht; Das wird wohl nicht gehen. Denke das man hier irgendwie anders ansetzen muss und ggf. irgendeine Form eines Tokens mit begrenzter Lebensdauer (z.B. ein JWT oder ein Sitztungs-Cookie, das für Requests mitgesendet wird mit einer im Backend registrierten Session korrespondiert) einsetzen sollte. Das macht das also schon etwas aufwändiger.
Man könnte ggf. mittels JS dafür sorgen, dass der Client auf einen bestimmten Timeout reagiert (und dann z.B. auf eine Login-Seite geht), aber wenn nun hier etwa ein dritter Zugriff auf das System hat, kann er grundsätzlich die vom Browser zwischengespeicherten Variablen und den DOM manipulieren oder die Ausführung von JS unterbrechen…Das wäre doof.
Mit einer schlichten Basic-Authentifizierung: Im Falle der HTTP (Basic) Authentifizierung sendet der Browser die Logindaten immer mit, also ist dessen Verhalten fuer die gestellten Fragen relevant. In der Regel merkt sich der Browser die Logindaten einige Zeit (zB fuer die aktuelle Session), bevor er wieder danach fragt. Das müsste man dann halt ausprobieren, ob ich hier an meine Sonderlösung komme u. sie so umsetzen kann.


und weiters: htpasswd Datei erstellen:
Damit der Verzeichnisschutz mit Passwort funktioniert, genügt die .htaccess-Datei alleine allerdings nicht. Man braucht hier immer zusätzlich auch noch eine Text-Datei, in der (der Benutzername und) das zugehörige Passwort drinne steht.

Code: Select all

.htpasswd-Datei
# die Passwort-Datei
myname:$2y$0d4433545$MQ7RdCCRrKmBEDD/usaks.9qAeCKy4YCP2pzgmc4lppfli41zC
Achtung!


Theoretisch könnte man die ganzen Passwörter auch im Klartext ablegen. Da sie so aber auch von Fremden ausgelesen werden können, ist es besser man verschlüsselt sie immer. Dabei ist folgendes wichtig:

- auf die veraltete MD5-Verschlüsselung sollte man hier nicht unbed. zurückgreifen.
- Benutzernamen sollten nicht länger als 255 Bytes sein.

Zusammengefasst sind die wichtigsten Regeln für .htpasswd:

- die Datei muss auf dem Web-Server, jedoch außerhalb des Web-Space liegen. Sie darf per HTTP weder gelesen und schon gar nicht geschrieben werden.
- die .httpwasswd-Datei muss root gehören.
- Sie - die .httpwasswd - darf nur durch root geschrieben werden.
- der Benutzer, unter dem das Web-Server-Programm lauft, darf in dem Verzeichnis, in dem die Datei .htaccess liegt, keine Dateien anlegen und keine Datei löschen können.
- man sollte darauf achten, dass der Pfad zu der Datei auch richtig gesetzt wird m.a.W. dass der richtige Pfad zur .htpasswd Datei angegeben ist. Aus Sicherheitsgründen sollte die .htpasswd Datei immer (!!) in einem anderen Verzeichnis gespeichert sein als die jeweilige .htaccess Datei, die auf die .htpasswd verweist. Das ist ziemlich wichtig.

Alternativ kann man auch einen WP-Plugin zu verwenden - How to Restrict WordPress Site Access by IP or Logged In ...https://de.wordpress.org/plugins/restri ... te-access/

vgl. Restricted Site Access bzw: Restricted Site Access

Beschränke den Zugriff auf deine Website auf angemeldete Besucher oder auf einen spezifischen IP-Bereich. Sende Besucher ohne Zugriff zur Anmeldeseite, leite sie weiter oder zeige eine Nachricht oder Seite an. Eine optimale Lösung für Extranets, öffentliche Intranets oder parallele Entwicklungsumgebungen.

- Adds a number of new configuration options to the Reading settings panel as well as the Network Settings panel in multisite. From these panels you can:
- Enable or disable site restriction
- Change the restriction behavior: send to login, redirect, display a message, display a page
- Add IP addresses to an unrestricted list, including ranges
- Quickly add your current IP to the unrestricted list
- Customize the redirect location, including an option to send them to the same requested path and set the HTTP status code for SEO friendliness
- Define a simple message to show restricted visitors, or select a page to show them – great for „coming soon“ teasers!

Bewertungen:
a. Protecting my development and test sites with this Plugin has been part of my workflow for a long time. It’s simple, effective and elegant–works so seamlessly that I forget it’s not just part of core WordPress.


ich werde dieses Plugin näher ansehen und testen.

Was meint ihr denn - was meint ihr zu diesem Zusatz!?

[Nobbie]

- ich dann die Seite offenstehen hab auf meinem Rechner?!
- also dass die Seite für 2 oder drei Stunden offen steht
- auf meinem aufrufenden Rechner

Genau so etwas GIBT ES NICHT. Das Protokoll HTTP ist sog. "zustandslos" und es gibt nicht den Zustand "offenstehen". Das Protokoll HTTP ist ein sog. "transaktionierendes" Protokoll. Im Prinzip bedeutet das:

1) EIn Client (Browser) bekommt vom Anwender die Aufgabe, eine bestimmte Ressource zu laden (durch Eingabe einer URL).
2) Der Browser wird in den allermeisten Fällen erst einmal den angefragten Servernamen "auflösen", d.h. er wird durch entsprechende Requests herausfinden, welche IP mit der angefragten URL konnektiert ist.
3) An diese IP schickt der Browser einen HTTP Request. Der gesuchte Server "horcht" dauerhaft auf einem Port (meistens Port 80) und der Clientbrowser macht (ähnlich wie ein Open einer Datei) einen "Open" Request auf diese IP und auf diesem Port.
4) Wird der gewünschte Server dort erreicht (wenn nicht, gibt es die entsprechende Meldung im Browser "Server not found"), schickt der Browser seinen HTTP Request an diesen Server. Das ist ein einfacher Satz a la "GET /index.html ...." usw. und erklärt dem Server, welche Ressource (welche Datei) der Browser gerne hätte.
5) Mit diesem Request kann der Browser die Daten von Cookies usw. mit dem Apache Server austauschen, es ist ein Dialog möglich, der den Request genauer spezifizieren kann.
6) Am Ende der Anfrage (der sog. "HTTP Header") schickt der Apache Server die gewünschte Ressource an den Client (Browser). Wenn das nicht ein fetter Download ist, sondern beispielsweise eine WordPress Seite, dann ist das Senden diese Inhalts eine Sache von Sekundenbruchteilen. Das ist der allerhäufigste Fall. Der Browser bekommt die komplette Ressource, er stuft sie als HTML ein (das steht u.a. auch im HTTP Header) und stellt die entsprechende Seite auf dem Monitor dar.
7) Nachdem alle Daten vom Server beim Browser angekommen sind, macht der Browser einen "Close" auf die TCPIP Verbindung. Der Server macht nun in seinem Tagesgeschäft weiter und "lauscht" auf Port 80, der Browser hat nichts zu tun und zeigt die gewünschte Seite.

Die beiden Rechner (Client PC und Apache Server) sind nun wieder vollkommen getrennt. Haben nichts miteinander zu tun. Das, was man gemeinhin als "eingelogged" bezeichnet, gibt es als Zustand nicht. Das ist eine Simulation, die mit dem Inhalt von Cookies realisiert wird. Es gibt kein "eingelogged" bei HTTP, Server und Client kennen sich nicht. Mit geschickten Inhalten von Cookies wird dem Anwender vorgegaukelt, es gäbt etwas vergleichbares wie unter Windows, wo man sich "einlogged". Das gibt es bei HTTP nicht. Mit der Trennung nach dem Request kennen sich die Rechner nicht mehr, es steht keine Leitung dazwischen, nichts gibt es da.

Was Du als "stundenlang offen stehen" bezeichnest, ist in der Realität gar nichts. Der Browser zeigt die ganze Zeit einen bestimmten Inhalt - sonst nichts. So wie Word, wenn Du stundenlang einen Text stehen läßt. Wenn Du Deinen Rechner einfach ausschaltest (brutal einfach Knopf drücken!), bekommt der Apache Server nichts davon mit. Der kennt Dich schon lange nicht mehr. Es gibt keine Verbindung, es gibt kein "offen stehen lassen".

[unleash_it]

hallo und guten Tag Nobbie

Danke für deine rasche Antwort - und ja; das leuchtet ein - die Zustands-Losigkeit (stateless) des HTTP legt dies klar. Hab ich kpl. vergessen. Da kann ich die Idee - so wie sie angedacht war vergessen.

Genau so etwas GIBT ES NICHT. Das Protokoll HTTP ist sog. "zustandslos" und es gibt nicht den Zustand "offenstehen". Das Protokoll HTTP ist ein sog. "transaktionierendes" Protokoll. Im Prinzip bedeutet das:

1) EIn Client (Browser) bekommt vom Anwender die Aufgabe, eine bestimmte Ressource zu laden (durch Eingabe einer URL).
2) Der Browser wird in den allermeisten Fällen erst einmal den angefragten Servernamen "auflösen", d.h. er wird durch entsprechende Requests herausfinden, welche IP mit der angefragten URL konnektiert ist.
3) An diese IP schickt der Browser einen HTTP Request. Der gesuchte Server "horcht" dauerhaft auf einem Port (meistens Port 80) und der Clientbrowser macht (ähnlich wie ein Open einer Datei) einen "Open" Request auf diese IP und auf diesem Port.
4) Wird der gewünschte Server dort erreicht (wenn nicht, gibt es die entsprechende Meldung im Browser "Server not found"), schickt der Browser seinen HTTP Request an diesen Server. Das ist ein einfacher Satz a la "GET /index.html ...." usw. und erklärt dem Server, welche Ressource (welche Datei) der Browser gerne hätte.
5) Mit diesem Request kann der Browser die Daten von Cookies usw. mit dem Apache Server austauschen, es ist ein Dialog möglich, der den Request genauer spezifizieren kann.
6) Am Ende der Anfrage (der sog. "HTTP Header") schickt der Apache Server die gewünschte Ressource an den Client (Browser). Wenn das nicht ein fetter Download ist, sondern beispielsweise eine WordPress Seite, dann ist das Senden diese Inhalts eine Sache von Sekundenbruchteilen. Das ist der allerhäufigste Fall. Der Browser bekommt die komplette Ressource, er stuft sie als HTML ein (das steht u.a. auch im HTTP Header) und stellt die entsprechende Seite auf dem Monitor dar.
7) Nachdem alle Daten vom Server beim Browser angekommen sind, macht der Browser einen "Close" auf die TCPIP Verbindung. Der Server macht nun in seinem Tagesgeschäft weiter und "lauscht" auf Port 80, der Browser hat nichts zu tun und zeigt die gewünschte Seite.

Die beiden Rechner (Client PC und Apache Server) sind nun wieder vollkommen getrennt. Haben nichts miteinander zu tun. Das, was man gemeinhin als "eingelogged" bezeichnet, gibt es als Zustand nicht. Das ist eine Simulation, die mit dem Inhalt von Cookies realisiert wird. Es gibt kein "eingelogged" bei HTTP, Server und Client kennen sich nicht. Mit geschickten Inhalten von Cookies wird dem Anwender vorgegaukelt, es gäbt etwas vergleichbares wie unter Windows, wo man sich "einlogged". Das gibt es bei HTTP nicht. Mit der Trennung nach dem Request kennen sich die Rechner nicht mehr, es steht keine Leitung dazwischen, nichts gibt es da.

Was Du als "stundenlang offen stehen" bezeichnest, ist in der Realität gar nichts. Der Browser zeigt die ganze Zeit einen bestimmten Inhalt - sonst nichts. So wie Word, wenn Du stundenlang einen Text stehen läßt. Wenn Du Deinen Rechner einfach ausschaltest (brutal einfach Knopf drücken!), bekommt der Apache Server nichts davon mit. Der kennt Dich schon lange nicht mehr. Es gibt keine Verbindung, es gibt kein "offen stehen lassen".

also ich denke dass du mit dem Hinweis auf die Zustandslosigkeit und mit deinen Erläuterungen dazu vieles geklärt hast.

Generell - das wäre ohnhin nicht mit einer basic HTTP-Authentication machbar gewesen;

- auch wohl nicht mit irgendeiner Form eines Tokens - z.B. mit begrenzter Lebensdauer (z.B. ein JWT oder ein Sitztungs-Cookie, das für Requests mitgesendet wird mit einer im Backend registrierten Session korrespondiert).
- oder wenn man z.B. mittels JS dafür sorgen, dass der Client auf einen Timeout reagiert (und dann z.B. auf eine Login-Seite geht), …


Dir nochmals vielen dank - ich teste im Moment den WP-Plugin "restricted-acess" - und guck wie weit ich damit komme. Im Moment sieht es damit ganz gut aus.


Viele Grüße und noch einen schoenen Tag

Unleash