Kirsten Flemming: htaccess und htpasswd - jetzt kommt keiner auf die Seiten

Hallo,

ich bin dabei, einen Bereich von Vereinsseiten nur für die Mitglieder zugänglich zu machen. Bei meiner Suche bin ich auf htaccess gestossen und finde das sehr gut. Habe viel gesurft, noch mehr gelesen und ausprobiert. Nun habe ich das ganze aktiviert. Jetzt funktioniert der Passwortschutz zu gut. Jeder Zugriff wird verweigert, weil nicht das richtige Passwort.

Was mache ich so grundlegend falsch?

Danke
Kirsten

  1. Guten Morgen,
    waere hilfreich, wenn Du uns den Inhalt der .htaccess und der dazugehoerenden pwd verraten wuerdest. Und waere auch gut zu wissen, auf welcher Servertype das alles liegt.
    dm.

    Hallo,

    ich bin dabei, einen Bereich von Vereinsseiten nur für die Mitglieder zugänglich zu machen. Bei meiner Suche bin ich auf htaccess gestossen und finde das sehr gut. Habe viel gesurft, noch mehr gelesen und ausprobiert. Nun habe ich das ganze aktiviert. Jetzt funktioniert der Passwortschutz zu gut. Jeder Zugriff wird verweigert, weil nicht das richtige Passwort.

    Was mache ich so grundlegend falsch?

    Danke
    Kirsten

    1. Guten Morgen,

      erstmal danke für die schnelle Antwort.

      Der Server ist ein LINUX-Server.

      Die htaccess sieht wie folgt aus:
      AuthName text
      AuthType Basic
      AuthUserFile /www.vonformat/aamo/.htpasswd
      require valid-user

      Und in der htpasswd steht:
      flemming:FRgR7jgsudOYs

      Mir fehlt mittlerweile jede Idee. Habe schon verschiedene Versionen und Verschlüsselungen ausprobiert. Im Moment bin ich in einer Sackgasse und finde nicht heraus.

      Danke
      Kirsten

      1. Hallo Kirsten!

        AuthName text
        AuthType Basic
        AuthUserFile /www.vonformat/aamo/.htpasswd
        require valid-user

        Probiere mal statt Authname text: AuthName "Secure Entry"

        Beim Pfad entweder http:// vor dem www. setzen oder den absoluten Pfad vom Root aus (wie hier - so sieht in etwa die .htaccess eines meiner geschützten Verzeichnisse aus):

        -------------
        AuthUserFile /home/atomic/public_html/DeinePasswortFile.pw
        AuthGroupFile /dev/null
        AuthName "Secure Entry"
        AuthType Basic

        <Limit GET POST>
        require valid-user
        </Limit>
        -------------

        Grüße,
        Patrick

        1. Re!

          AuthUserFile /www.vonformat/aamo/.htpasswd

          Hier fehlt auch  noch das .com hinter dem Domainnamen...

          Grüße,
          Patrick

        2. Hallo Patrick,

          danke für Deine Info. Das .com stand in der htaccess nur nicht hier im Text. Tippfehler.

          Habe deinen Vorschlag - http.. und Authname - ausprobiert. Leider keine Änderung. Die Seiten sind immer noch hoch gesichert.

          Trotzdem vielen Dank
          Kirsten

        3. Hallo Kirsten!

          AuthName text

          Hier kann stehen, was will. Es wird (je nach Browser) im Passowrt-Fenster ausgegeben.

          AuthUserFile /www.vonformat/aamo/.htpasswd

          Hier liegt wahrscheinlich das Problem. Das Verzeichnis /www.vonformat.com/aamo/ wird sicher nicht in der root des Webservers liegen, es ist Deine WWW-root. Deine Pfadangabe sieht aber für den Server so aus.

          Du brauchst also die absolute Pfadangabe. Wenn Du die nicht selbst rauskriegen kannst (steht manchmal in einer Enviroment-Variable, mal alle per CGI ausgeben lassen oder per SSI), frage Deinen Provider.

          Gruß Frank

      2. Hallo Kirsten!

        Wette 90:10 das folgender Pfad falsch ist:

        AuthUserFile /www.vonformat/aamo/.htpasswd

        Da muss der absolute Pfad zu deinen Verzeichnissen auf dem System deines Provders liegen. Er kann keinesfalls mit http:// beginnen.
        Rausbekommen tust du den Pfad auf den Hilfeseiten deines Providers oder durch Anfrage bei selbigem.
        Ohne diesen korrekten Pfad hat das keinen Zweck. Ebenso ist raten[1]  zum scheitern verurteilt, dazu gibt es einfach zuviele verschiedene Möglichkeiten.

        Solltest du PHP auf deinem Account dürfen speichere folgendes:

        <?
        phpinfo();
        ?>

        als Datei phphinf.php3 auf deinem Webspace. Das zeigt dir dann beim Aufruf per Browser (unter vielem anderen) den Pfad an. Anschliessend löschen dieser Datei nicht vergesen!

        Gruss,
         Carsten

        [1] Der Punkt ist etwas suspekt  (aber nicht unmöglich)(eher /www/vonformat/...)
        ausserdem sieht es so aus wie der Pfad ab der Stelle wo du per FTP einsteigst, da fehlt dann einiges davor (z.b. /home/username/www/vonformat/aamo/.htpasswd oder /usr/local/httpd/htdocs/username/vonformat/aamo/.htpasswd oder /www/tarifart/vonformat/aamo/.htpasswd, wie gesagt raten hat absolut keinen Zweck, hier hilft NUR fragen oder rausbekommen!)

        1. Hallo Carsten!

          <?
          phpinfo();
          ?>

          Sehr interessant. Liefert viel mehr Infos als bei Perl:

          for (keys %ENV)
          {
            print "$_ : $ENV{$_}<br>\n";
          }

          So habe ich erfahren (sollte es von Bedeutung für die Vielposter- und die geplanten SELFSPEZIAL-Stats), dass ich über PHP version 4.1.0 verfüge...

          Aber zwei Fragen fallen mir in diesem Zusammenhang ein.

          1. Was bedeutet HTTP_ACCEPT_ENCODING: gzip, deflate ? Hat das mit diesem hier installierten mod_gzip zu tun?

          2. Die 2. Frage richtet sich eher an Perl-Spezis. Kann man herausfinden, welche Perl-Module installiert sind (könnte ja den Provi fragen, aber dazu müsste ich mein Englisch anstregen, nee, nur im Notfall *g*)?

          Grüße,
          Patrick

          1. Hallo,

            1. Die 2. Frage richtet sich eher an Perl-Spezis. Kann man herausfinden, welche Perl-Module installiert sind (könnte ja den Provi fragen, aber dazu müsste ich mein Englisch anstregen, nee, nur im Notfall *g*)?

            Kann man. Ich habe (glaube ich) bei http://www.i-netlab.de mal so ein Script(chen) zum Download gesehen.

            Gruß Frank

            1. Hallo Frank!

              Kann man. Ich habe (glaube ich) bei http://www.i-netlab.de mal so ein Script(chen) zum Download gesehen.

              Thanks, das war genau richtig. Jetzt weiß ich, dass ich das eine Modul nachinstallieren muss!

              Grüße,
              Patrick

          2. Hi Patrick,

            1. Was bedeutet HTTP_ACCEPT_ENCODING: gzip, deflate ? Hat das mit diesem hier installierten mod_gzip zu tun?

            Ja.

            Der UserAgent sendet dem Server Angaben darüber, welche Content-Encodings er zu verstehen behauptet ("Accept-Encoding").
            Und wenn der Server das glaubt, dann darf er Seiten in der entsprechenden Codierung zurück senden ("Content-Encoding").

            Was der Client sendet, ist übrigens eine Menge; was der Server antwortet, eine Liste. Ein Paket darf nämlich auch mehrfach codiert sein; die Liste beschreibt dann die Reihenfolge, in welcher die Verpackungen angewandt wurden, und der Client muß die Encodings in umgekehrter Reihenfolge wieder rückgängig machen.

            Mozilla 0.9.7 ist der erste mir bekannte Browser, bei dem man diesen Accept-Encoding-String in der Konfiguration gezielt verändern kann. Mit diesem Client könnte ein Benutzer sich also auch gegen eine Verwendung bestimmter Codierungen entscheiden, falls er damit Probleme hat.
            Und für Probleme gibt es eine Reihe möglicher Gründe ... ich sage nur "caching proxies" ... weia, das war eine lange Nacht gestern abend.

            Viele Grüße
                  Michael

            1. Hallo Michael!

              1. Was bedeutet HTTP_ACCEPT_ENCODING: gzip, deflate ? Hat das mit diesem hier installierten mod_gzip zu tun?

              Ja.

              Hmmh... da muß ich mal nachhaken... heißt es dann, ich könnte auch mod_gzip einsetzen? Wenn ja, wie?

              Grüße,
              Patrick

              1. Hi Patrick,

                Hmmh... da muß ich mal nachhaken... heißt es dann, ich könnte auch
                mod_gzip einsetzen?

                <standardfrage>Was willst Du denn erreichen?</standardfrage>

                mod_gzip ist ein 3rd-Party-Apache-Modul, welches die Inhalte ausgelieferter Seiten komprimieren kann - insbesondere dynamisch generierte Seiten. Denn bei statischen Seiten gäbe es auch schon Lösungen mit 'Bordmitteln' (statisch komprimieren und Content Negotiation - das kann mod_gzip so nebenbei auch, und ohne dafür den ganzen MultiViews-Voodoo veranstalten zu müssen, siehe entsprechender Feature-Artikel).
                Das spart zweifellos Bandbreite bei der Seitenauslieferung; je nach Meßverfahren (ich zähle die HTTP-Header etc. mit) ist eine Halbierung bis Drittelung des Traffic durchaus machbar. (Je mehr "Luft" bisher ausgeliefert wurde, desto mehr kannst Du gewinnen; generierte HTML-Seiten eines Forums sind toll komprimierbar, GIFs gar nicht, miniwinzigkleine CSS- und JavaScript-Dateien auch kaum.)
                Die on-the-fly-Komprimierung belastet den Server natürlich ein wenig zusätzlich, aber bei der Konfiguration kann man an vielen Schrauben drehen, um dies entsprechend feinzutunen.
                Es gibt zahlreiche Antworten, die Du _nicht_ komprimiert ausliefern wollen wirst - sei es, daß es nicht viel bringt, sei es, daß der Browser Dich belogen hat und besser doch keine komprimierten Seiten bekommen sollte. (Meine Produktionsmaschine komprimiert 39% aller Requests, reduziert damit aber das Volumen des ausgelieferten Content um 67% und den Gesamt-Traffic um 57%, Zahlen von heute.) Auch das ist eine Frage der Konfiguration - im Wesentlichen baust Du dabei einen Regelsatz auf, welcher auf Eigenschaften des Request beruht. (URL, Dateiname, MIME-Typ, ein- und ausgehende HTTP-Header-Felder, Apache-Handler - Gestaltungsfreiheit ist reichlich vorhanden - man braucht aber auch fast alles, wenn man weiß, was man will.)

                Wenn ja, wie?

                "Einsetzen" bedeutet:

                1. Einbauen in den Apache-Server, den Du _betreibst_. Du mußt selbst Apache-Administrator Deiner Maschine sein, weil Du ja nicht nur das Verhalten (die Konfiguration), sondern den Binärcode des Apache selbst um ein 'Fremdprodukt' erweiterst - normales Webhosting reicht _nicht_. (Server-Hosting schon ...) Mag sein, daß so etwas irgendwann mal den Unterschied zwischen einem normalen und einem 'guten' Provider ausmachen wird.
                Je nachdem, was Du da selbst darfst bzw. kannst, hast Du die Wahl zwischen "Apache plus mod_gzip-Quelltext neu übersetzen" (so mache ich es unter UNIX) oder "ein Deiner Plattform entsprechendes übersetztes Modul downloaden" (für Windows und Linux gibt es in diesem Format schon etwas - da ich keinen Windows-C-Compiler habe, muß ich auf dieser Plattform diesen Weg gehen) "und via httpd.conf dazu laden" - wofür Dein Apache bereits den Shared-Object-Loader mod_so beinhalten muß (das tun aber viele vorgefertigten Apaches schon, insbesondere die Windows-Binaries, aber auch die typischen Linux-Apaches - grusel).

                2. Konfigurieren. Dabei legst Du ein paar Betriebsparameter fest; vor allem aber beschreibst Du, Ergebnisse welcher Anforderungen vor der Auslieferung von mod_gzip komprimiert werden sollen und welche nicht. Das ist ein durchaus nichttrivialer Teil der Arbeit, weil erstens die momentan verfügbare Dokumentation eher spärlich bemessen ist ("wir arbeiten daran" ...) und zweitens für ein wirkliches Verständnis dessen, was man alles tun muß, um mit wirklich exotischen Sonderfällen klar zu kommen, ein detailliertes Wissen über interne Apache-Abläufe erforderlich ist, welches ich auch nach einem halben Jahr Beschäftigung mit mod_gzip noch nicht bis ins Detail erworben habe ... nein, nicht weinen - es ging wirklich nur um die _exotischen_ Sonderfälle, also diejenigen anderen Apache-Fremdmodule, welche sich an bestimmte interne Apache-Spielregeln nicht halten, eigenmächtig Requests intern umschreiben usw.
                Eine mod_gzip-Konfiguration für den "Normalbetrieb" kriegst Du genauso hin wie jede andere Apache-Konfiguration: Überlegen, was Du willst, und die entsprechenden Direktiven verwenden. Mit
                   http://www.schroepl.net/projekte/mod_gzip/config.shtml
                kommst Du schon mal ziemlich weit - wenn Du dann anfangen willst, auch noch die dynamischen Ausgaben von Java-Servlet-Engines oder SSL-Virtual Hosts zu komprimieren, oder Deinen Apache als 'compressing proxy' vor eine Menge anderer (fremder! Es ist sogar ein M$-IIS dabei) Webserver zu stellen, dann treffen wir uns auf der mod_gzip-Mailingliste wieder ...

                Viele Grüße
                      Michael

                P.S.: In der iX 3/2002 ist ein schöner Artikel über mod_gzip.

                1. Danke Michael für die ausführliche Antwort!

                  Du mußt selbst Apache-Administrator Deiner Maschine sein, weil Du ja nicht nur das Verhalten (die Konfiguration), sondern den Binärcode des Apache selbst um ein 'Fremdprodukt' erweiterst - normales Webhosting reicht _nicht_.

                  Daran wird's wohl scheitern :-)

                  Grüße,
                  Patrick

                  1. Hi Patrick,

                    Du mußt selbst Apache-Administrator Deiner Maschine sein - normales Webhosting reicht _nicht_.
                    Daran wird's wohl scheitern :-)

                    Hast Du den Provider schon gefragt?

                    Schließlich würde ja nicht nur Dein Webspace davon profitieren, sondern _jeder_ seiner Kunden ...

                    Viele Grüße
                          Michael

        2. Hallo Kirsten!
          Wette 90:10 das folgender Pfad falsch ist:

          AuthUserFile /www.vonformat/aamo/.htpasswd

          Hi,
          Sieht mir auch nicht nach dem absolutem Pfad aus, aber eigenartig dann, dass - so hab ich Kerstin's mail verstanden - nicht nur das Subdir aamo NICHT, sondern ganz im Gegenteil gleich ALLES gesichert ist.
          Ist das PWD ein Offenes oder ein Verschluesseltes und hast Du auf case sensitive geachtet?
          Cheers, dm.

          PS: Das hat man davon wenn man aus'm Haus muss... man stellt schnell mal eine Frage und ist dann dennoch der Letzte, der zum antworten kommt...

  2. Hi Kirsten,

    Jeder Zugriff wird verweigert, weil nicht das richtige Passwort.

    wer behauptet das?

    Wenn ein beliebiger interner Verarbeitungsfehler vorliegt, dann wird
    der Zugriff immer scheitern.

    Was mache ich so grundlegend falsch?

    Ein Blick in das error_log des Servers würde Dir Aufschluß darüber geben. Genau dafür ist das error_log da.
    Und sag ja nicht, Du hättest keinen Zugriff darauf ...

    Viel Grüße
         Michael