Apache, .htaccess & differenzierte Authentifizierung

[Joerg]

Hallo,

ich habe lokal einen Apache laufen, auf dem einige Applikationen laufen. Auf den Apache kann ich auch über einen Dienst wie dynDNS von außen zugreifen.

Ich möchte nun erreichen, dass sich jeder von außen kommende User, im Gegensatz zu den lokalen Usern, am Server anmelden muss, um auf die Apps zugreifen zu können.

Gibt es irgendeine Möglichkeit, z. B. via .htaccess, diese Art der Differenzierung vorzunehmen?

Es geht hier um eine einfache Sicherheitsmaßname, damit nicht jeder, dem die externe Adresse bekannt ist, sich auf dem Server tummeln kann.

Habe zu diesem Thema noch keine wirklich aussagekräftigen Hinweise gefunden.

Vielen Dank im Voraus,
Joerg

[frankx]

Ahoi,

Habe zu diesem Thema noch keine wirklich aussagekräftigen Hinweise gefunden.

Ja, wo hast Du denn gesucht? http://aktuell.de.selfhtml.org/artikel/server/aliasing/

Dank und Gruß,

frankx

[frankx]

Ahoi,

Ja, wo hast Du denn gesucht? http://aktuell.de.selfhtml.org/artikel/server/aliasing/

bzw. http://aktuell.de.selfhtml.org/artikel/server/htaccess/index.htm

Dank und Gruß,

frankx

[Joerg]

Hallo,

danke für die schnelle Antwort.

»» Ja, wo hast Du denn gesucht? http://aktuell.de.selfhtml.org/artikel/server/aliasing/

hm, gesehen habe ich das wohl. Mir ist aber nicht klar, wie ich beide Zugriffsarten unter einen Hut bekomme. Entweder müssen sich alle User anmelden, oder keiner.

Lokale User haben den IP-Bereich 192.168. Ich weiß, dass ich mit satisfy ? und allow ? arbeiten muss. Aber konkret? Da hakt es dann. Könntest du mir vielleicht eine kleine Demo-.htaccess zeigen?

Vielen Dank im Voraus,
Joerg

[ChrisB]

Hi,

Lokale User haben den IP-Bereich 192.168. Ich weiß, dass ich mit satisfy ? und allow ? arbeiten muss. Aber konkret? Da hakt es dann.

RTFM - die Apache-Doku zu Satisfy hat ein Beispiel für *genau* *diesen* Anwendungsfall.

MfG ChrisB

[Joerg]

Hi,

RTFM - die Apache-Doku zu Satisfy hat ein Beispiel für *genau* *diesen* Anwendungsfall.

Danke für den Hinweis und die warmen Worten. Kannst du dir vorstellen, dass jemand, der nicht täglich den Apache konfiguriert, mit den diversen Hinweisen in der Doku leicht überfordert sein könnte? Zumal dort immer nur kleine Schnippsel behandelt werden und der große Zusammenhang schnell verloren geht.

Meine Konfiguration sieht nun so aus:
[...]
AllowOverride all
Order Deny,Allow
Deny from all

<LIMIT GET>
Require valid-user
Allow from 192.168
Satisfy Any
</LIMIT>
[...]

Ich muss das jetzt noch einmal "Live" testen, das dauert etwas. Vielen Dank für die schnelle Hilfe.

Joerg

[Vinzenz Mai]

Hallo,

Danke für den Hinweis und die warmen Worten. Kannst du dir vorstellen, dass jemand, der nicht täglich den Apache konfiguriert, mit den diversen Hinweisen in der Doku leicht überfordert sein könnte?

Meine Konfiguration sieht nun so aus:
[...]
AllowOverride all
Order Deny,Allow
Deny from all

Warum LIMIT? Warum?

<LIMIT GET>
Require valid-user
Allow from 192.168
Satisfy Any
</LIMIT>

Ist das fettgedruckte in der Doku nicht fettgedruckt genug?

Freundliche Grüße

Vinzenz

[frankx]

Ahoi,

Warum LIMIT? Warum?

Was macht das denn, limitiert es den Zugang nur auf GET-Anfragen, sprich, putten und posten kann ich nicht, oder heißt das, dass put und post garnicht limitiert sind, also ein post-request(?) ohne passwortkontrolle an den server gesandt werden könnte?

Dank und Gruß,

frankx

[Vinzenz Mai]

Hallo,

» Warum LIMIT? Warum?

Was macht das denn, limitiert es den Zugang nur auf GET-Anfragen,

Nein.

sprich, putten und posten kann ich nicht,

oder heißt das, dass put und post garnicht limitiert sind, also ein post-request(?) ohne passwortkontrolle an den server gesandt werden könnte?

Ja. Steht da. Schwarz auf weiß.

Ich zitiere zunächst das Fettgedruckte:

"Im Allgemeinen sollten Zugriffskontrollen nicht in einen <Limit>-Container
     gepackt werden."

Das ist ziemlich unmißverständlich. Man sollte schon verdammt gute Gründe haben, überhaupt einen LIMIT-Container einzusetzen.

"Der Sinn der Direktive <Limit>  ist es, den Effekt der
     Zugriffskontrollen auf die angegebenen HTTP-Methoden zu beschränken.
     Bei allen anderen Methoden haben die in der <Limit>-Gruppe enthaltenen
     Zugriffsbeschränkungen keine Wirkung. Im folgenden Beispiel gilt die
     Zugriffskontrolle nur für die Methoden POST, PUT und DELETE. Alle
     anderen Methoden bleiben ungeschützt:

  
        <Limit POST PUT DELETE>  
            Require valid-user  
        </Limit> 

[...]"

Sprich: LIMIT limitiert die Zugriffsbeschränkungen, nicht den Zugriff.
Der letzte Satz ist doch überhaupt nicht falsch zu verstehen.

Freundliche Grüße

Vinzenz

[frankx]

Ahoi Vinzenz,

wer liest ist klar im Vorteil! Merci.

Dank und Gruß,

frankx