pfad für .htusers bei 1und1

[willie.de]

hallö ins forum,

ich hab mal ne ganz profane frage (wie immer :-)

ich suche den korrekten pfad für die ablage der .htusers (http://selfhtml.teamone.de/diverses/htaccess.htm#verzeichnisschutz) auf einem server bei 1und1. sicher kann ich mich an meinen hoster wenden, aber ich hätte die info gerne innerhalb der nächsten tage ;o)

danke für hilfe & grüße aus Leipzig
willie.de

[Stefan Einspender]

Hallo,

ich suche den korrekten pfad für die ablage der .htusers auf einem server bei 1und1.

einfachste Lösung wird es sein, wenn Du Dir mal die .htaccess aus
dem logs-Verzeichnis per FTP auf die Platte ziehst und da schaust,
steht der Pfad drin.

Beispiel
/kunden/homepages/XX/dYYYYYY/htpasswd

Wenn Du nur Nutzer hast, die auch in das logs-Verzeichnis dürfen,
dann lege einfach über https://login.1und1.de/ neue Benutzer für
/logs/ an, die kannst Du dann in Deinen .htaccess-Dateien nehmen
und dabei den obigen Pfad angeben.

Wenn nicht, dann lege eine eigene .htpasswd in das Verzeichnis,
welches Du nach dem FTP-Login aufrufst, der Pfad lautet dann wie
folgt: /kunden/homepages/XX/dYYYYYY/htdocs/.htpasswd

Wichtig, die Datei sollte über HTTP nicht aufrufbar sind (auch
nicht theoretisch, weil standardmäßig bekommt man beim Aufruf
einer Datei, die mit einem Punkt anfängt, nur einen 403), d.h.
Deine Website(s) sollte(n) dann in Unterverzeichnissen liegen,
über das Konfigurationsmenü kannst Du die ja für jede Domain
ganz einfach festlegen.

sicher kann ich mich an meinen hoster wenden, aber ich hätte die info gerne innerhalb der nächsten tage ;o)

Nach mehreren Supportanfragen über die Kontaktformulare im Kunden-
bereich bei 1&1 in den letzten Wochen kann ich sagen, dass dieser
Webhoster da sehr zuverlässig, kompetent und schnell antwortet :-)

Auch wenn Werbung hier nicht so gern gesehen ist, aber ich kann
1&1 wirklich empfehlen, Probleme werden, sofern sie auftreten,
schnell und gut gelöst. Was mich stört ist allenfalls die einge-
schränkte Flexibilität bei speziellen Angelegenheiten (ich wollte
z.Bsp. die webmaster-Acccounts gelöscht haben), aber damit kann
ich leben, schließlich sind die Angebote auch sehr preiswert :-)

Viele Grüße,
Stefan

[willie.de]

hallo

und danke für die schnelle

einfachste Lösung wird es sein...

und ausführliche antwort!

Nach mehreren Supportanfragen über die Kontaktformulare im Kunden-
bereich bei 1&1 in den letzten Wochen kann ich sagen, dass dieser
Webhoster da sehr zuverlässig, kompetent und schnell antwortet :-)

naja, ich hab email-antworten spät und teilweise gar nicht erhalten. aber immerhin haben sich die 1&1-er entschuldigt und meine probleme waren sehr speziell (zb. umbenennung des firmeneintrages). und: wenn die antwort kam, dann immer kompetent. (anders als ich es in einzelfällen zb. von freenet kenne.)

grüße aus Leipzig
willie.de

[Sven Rautenberg]

Moin!

und danke für die schnelle

einfachste Lösung wird es sein...
und ausführliche antwort!

Die einfachste Lösung wäre gewesen, einfach mal in die FAQ von Puretec zu gucken. Da steht das nämlich drin, wie's geht. Außerdem gibts im Web-Config-Bereich eine Möglichkeit, einen .htaccess-Schutz generieren zu lassen. Da steht der Pfad zum DOCUMENT_ROOT dann hinterher automatisch drin.

- Sven Rautenberg

[Michael Schröpl]

Hallo Stefan,

Wenn nicht, dann lege eine eigene .htpasswd in das Verzeichnis,
welches Du nach dem FTP-Login aufrufst, der Pfad lautet dann wie
folgt: /kunden/homepages/XX/dYYYYYY/htdocs/.htpasswd

was soll die Passwort-Liste innerhalb des URL-Raums?
(Ich würde sie oberhalb von 'htdocs' anlegen wollen.)

Viele Grüße
      Michael

[Stefan Einspender]

Hallo Michael,

folgt: /kunden/homepages/XX/dYYYYYY/htdocs/.htpasswd

was soll die Passwort-Liste innerhalb des URL-Raums?
(Ich würde sie oberhalb von 'htdocs' anlegen wollen.)

da kommt man nicht ran. Lediglich die Passwort-Liste, die für das
logs-Verzeichnis zuständig ist, welches man automatisch bei 1&1
bekommt, liegt oberhalb von htdocs. Allerdings muß ich auch sagen,
dass es im Konfigurationsmenü die Möglichkeit gibt, Verzeichnisse
zu schützen und diese Passwörter werden dann sicher auch in die
/kunden/homepages/XX/dYYYYYY/htpasswd reingeschrieben.

Wie sieht es eigentlich aus, wenn ich für alle (Sub)Domains ein
Unterverzeichnis als Startverzeichnis festlege, ist es dann auch
kritisch, wenn die .htpasswd im htdocs-Verzeichnis liegt?

/domain1/
/domain2/
/domain3/
/logs/
/subdomain1/
/subdomain2/
/subdomain3/
.htpasswd

Viele Grüße,
Stefan

[Michael Schröpl]

Hi Stefan,

folgt: /kunden/homepages/XX/dYYYYYY/htdocs/.htpasswd
was soll die Passwort-Liste innerhalb des URL-Raums?
(Ich würde sie oberhalb von 'htdocs' anlegen wollen.)
da kommt man nicht ran. Lediglich die Passwort-Liste, die für das
logs-Verzeichnis zuständig ist, welches man automatisch bei 1&1
bekommt, liegt oberhalb von htdocs.

komischer Provider. Wenn ich oberhalb von htdocs nichts tun kann, wieso brauche ich dann überhaupt ein separates Verzeichnis für die HTTP-Dokumente? Bei meinem 5-EUR-Webspace darf ich viel mehr.

Wie sieht es eigentlich aus, wenn ich für alle (Sub)Domains ein
Unterverzeichnis als Startverzeichnis festlege, ist es dann auch
kritisch, wenn die .htpasswd im htdocs-Verzeichnis liegt?

Dann liegt sie an einer Stelle, die nicht durch einen URL (welcher Subdomain auch immer) zu beschreiben ist, oder? Nur darauf kommt es an.

"Kritisch" ist immer relativ zu sehen.
Du erinnerst Dich sicher noch an den Provider, bei dem das Self-Portal früher einmal war und der bei Übernahme durch eine andere Firma erst mal den Webserver derartig ruinierte, daß sämtliche Zugriffsschutzsysteme abgeschaltet waren und man die Klartexte jeder innerhalb des URL-Raums liegenden Datei lesen konnte?
Kannst Du einen solchen Fingerfehler für 1&1 _verbindlich_ ausschließen?

Etwas, das im HTTP-Universum nicht sichtbar ist, kann nicht durch einen Konfigurationsfehler des Providers der Öffentlichkeit preisgegeben werden.
Also: Keine Userid/Passwort-Daten innerhalb des URL-Raums - auch nicht fest eingebrannt in Perl- oder PHP-Skripten (die statt dessen diese Informationen ebenfalls aus einer separaten Datei, einer Datenbank oder was auch immer einlesen sollten).

Viele Grüße
      Michael

[Stefan Einspender]

Hallo Michael,

komischer Provider. Wenn ich oberhalb von htdocs nichts tun kann, wieso brauche ich dann überhaupt ein separates Verzeichnis für die HTTP-Dokumente? Bei meinem 5-EUR-Webspace darf ich viel mehr.

stimmt schon, besonders flexibel ist es nicht. Allerdings denke ich,
dass sich 1&1 da auch ein Stück weit absichern will. Sonst legen
die DAUs ihre Websites in / (und nicht /htdocs/) und die Anfragen
beim Support häufen sich, warum da nix im Browser angezeigt wird ;-)

Kannst Du einen solchen Fingerfehler für 1&1 _verbindlich_ ausschließen?

Nein, allerdings vertraue [1] ich der Firma soweit, dass ich den
Fehler für unwahrscheinlich genug halte.

Also: Keine Userid/Passwort-Daten innerhalb des URL-Raums - auch nicht fest eingebrannt in Perl- oder PHP-Skripten (die statt dessen diese Informationen ebenfalls aus einer separaten Datei, einer Datenbank oder was auch immer einlesen sollten).

Klingt vernünftig und werde ich in Zukunft, soweit irgendwie mög-
lich auch berücksichtigen.

Viele Grüße,
Stefan

[1] Wobei mein Vertrauen hier nicht blind ist, d.h. mit den Pass-
    wörtern werden Daten geschützt, die nicht hochsensibel sind,
    d.h. würde da jemand Zugriff bekommen, wäre es für mich
    keine Katastrophe, sondern nur ein Ärgernis. Und wer wirk-
    lich relevante Dinge (Shops ...) für 3,50 EUR hostet, der
    ist selbst schuld ;-)

[Sven Rautenberg]

Moin!

komischer Provider. Wenn ich oberhalb von htdocs nichts tun kann, wieso brauche ich dann überhaupt ein separates Verzeichnis für die HTTP-Dokumente? Bei meinem 5-EUR-Webspace darf ich viel mehr.

stimmt schon, besonders flexibel ist es nicht. Allerdings denke ich,
dass sich 1&1 da auch ein Stück weit absichern will. Sonst legen
die DAUs ihre Websites in / (und nicht /htdocs/) und die Anfragen
beim Support häufen sich, warum da nix im Browser angezeigt wird ;-)

Allerdings kann man das auch beliebig konfigurieren. Per FTP ist das eigene "Root"-Verzeichnis zugänglich - höher gehts nicht. Man kann dieses Verzeichnis jetzt direkt als Document-Root verwenden (ist AFAIK default), oder (da man noch Subdomains und weitere Hauptdomains dazukriegen kann) Unterverzeichnisse anlegen, in denen dann je Domain/Subdomain der jeweilige Document-Root liegt.

Die Webconfigurationsoberfläche machts möglich. :)

- Sven Rautenberg

[Christian Seiler]

Hallo Michael,

Du erinnerst Dich sicher noch an den Provider, bei dem das Self-Portal früher einmal war und der bei Übernahme durch eine andere Firma erst mal den Webserver derartig ruinierte, daß sämtliche Zugriffsschutzsysteme abgeschaltet waren und man die Klartexte jeder innerhalb des URL-Raums liegenden Datei lesen konnte?
Kannst Du einen solchen Fingerfehler für 1&1 _verbindlich_ ausschließen?

Nunja, auch wenn dies schon vorgekommen ist, halte ich das ganze dann doch für _sehr_ unwarscheinlich. In der httpd.conf, die von der Apache Group mitgeliefert wird, stehen diese Zeilen zusammen mit einem ziemlich ausführlichen Kommentar drin:

<Files ~ "^.ht">
    Order allow,deny
    Deny from all
</Files>

Ich halte es eher für warscheinlicher, dass jemand aus Versehen AllowOverride None setzt und somit ".htaccess" wirkungslos macht. Oder dass eine Sicherheitslücke im Webserver auftaucht, die das Auslesen von Dateien außerhalb des Stammbaums gestattet. (das gabe es öfters beim IIS, beim Apache AFAIK auch schon)

Wenn man sich wirklich solche Sorgen mache, dass jemand so an bestimmte Daten kommt, sollte man sich lieber wirklich einen dedizierten Server mieten oder einen eigenen Server in einem Rechenzentrum housen lassen.

Viele Grüße,
Christian

[Michael Schröpl]

Hi Christian,

Kannst Du einen solchen Fingerfehler für 1&1 _verbindlich_ ausschließen?
Nunja, auch wenn dies schon vorgekommen ist, halte ich das ganze dann doch für _sehr_ unwarscheinlich.
Ich halte es eher für warscheinlicher, dass jemand aus Versehen AllowOverride None setzt und somit ".htaccess" wirkungslos macht.

dies wollte ich unter "solche" Fingerfehler mit abgedeckt haben - aber die explizite Erwähnung ist sinnvoll, danke.

Viele Grüße
      Michael