Frontpage-Extensions - .htaccess ausmisten

[Viennamade]

Hallo liebe Forumer!

Mangels Wissen über LDAP verstehe ich http://manual.int23.info/apache.de/mod/mod_auth_ldap.html#frontpage nicht zufriedenstellend.

Aber ich glaube aus der vom Provider vorgegebenen .htaccess

AuthLDAPURL     ldap://udsrr.entenhausen.at/o=yyy?uid
   AuthLDAPAuthoritative   off
   AuthLDAPFrontPageHack   on

rauslöschen zu können, wenn "dort" kein mit FP erstelltes Web liegt?

Beste Grüße
Viennamade

[Der Martin]

Hallo Viennamade,

ich kann mit LDAP auch nichts anfangen.

Aber ich glaube aus der vom Provider vorgegebenen .htaccess

AuthLDAPURL     ldap://udsrr.entenhausen.at/o=yyy?uid
   AuthLDAPAuthoritative   off
   AuthLDAPFrontPageHack   on

rauslöschen zu können, wenn "dort" kein mit FP erstelltes Web liegt?

Auch mein Provider bietet "Frontpage Extensions" mit an, obwohl mir das schnurz ist; deshalb habe ich auch diverse FP-bezogene Anweisungen aus der vorgegebenen .htaccess gelöscht. Ebenso wie die standardmäßig eingerichteten _vti* Verzeichnisse.
Und es hat scheinbar niemandem geschadet. :)

So long,

Martin

[Viennamade]

Hallo!

Danke für die Antwort!
Diese 3 Zeilen

AuthLDAPURL     ldap://udsrr.entenhausen.at/o=yyy?uid
   AuthLDAPAuthoritative   off
   AuthLDAPFrontPageHack   on

habe ich jetzt draußen und es funktioniert noch alles.

Bleiben noch diese 3 vom Provider eingerichteten; mindesten die beiden letzten riechen nach Frontpage:
  AuthName svuauseg.entenhausen.at
  AuthUserFile /var/users/kundenname/www/_vti_pvt/service.pwd
  AuthGroupFile /var/users/kundenname/www/_vti_pvt/service.grp

Andererseits scheinen die 3 wiederum zusammen zu gehören und für die Authentifizierung gut zu sein ?!

Beste Grüße
Viennamade

[Der Martin]

Hi nochmal,

Bleiben noch diese 3 vom Provider eingerichteten; mindesten die beiden letzten riechen nach Frontpage:

Klarer Fall. Die _vti-Namen sprechen eine deutliche Sprache.

Andererseits scheinen die 3 wiederum zusammen zu gehören und für die Authentifizierung gut zu sein ?!

Ja und? Ausprobieren! Die .htaccess wird doch nur vom Webserver ausgewertet. Wenn's schiefgeht, kommst du ja immer noch per FTP rein und kannst den Originalzustand wiederherstellen, oder?

Nur wer wagt, gewinnt!

Martin

[Viennamade]

Hallo!

Nur wer wagt, gewinnt!

Jo, jetzt habe ich die restlichen 3 Provider-Zeilen rausgenommen, nämlich
  AuthName ...
  AuthUserFile .../_vti_pvt/service.pwd
  AuthGroupFile .../_vti_pvt/service.grp

und es funktioniert noch immer alles. :-)

Danke!
Viennamade

[Ingo Turski]

Hi,

aus der vorgegebenen .htaccess gelöscht. Ebenso wie die standardmäßig eingerichteten _vti* Verzeichnisse.
Und es hat scheinbar niemandem geschadet. :)

nunja, lediglich die Logfles erhalten ein paar 404er von IE-Usern - bei mir im August
   51* /_vti_inf.html
zusätzlich zu den /MSOffice/cltreq.asp?... und den fehlerhaften CSS-Anforderungen ala pfad/Inhalt des title -Dateien/datei.css ;-)

freundliche Grüße
Ingo

[Viennamade]

Hallo!

aus der vorgegebenen .htaccess gelöscht. Ebenso wie die standardmäßig eingerichteten _vti* Verzeichnisse.
Und es hat scheinbar niemandem geschadet. :)
nunja, lediglich die Logfles erhalten ein paar 404er von IE-Usern - bei mir im August
   51* /_vti_inf.html
zusätzlich zu den /MSOffice/cltreq.asp?... und den fehlerhaften CSS-Anforderungen ala pfad/Inhalt des title -Dateien/datei.css ;-)

Brrr, 404 bedeutet, daß vorhandene URIs angesteuert wurden und IE-Browser die nicht bekommen haben? Oder nur, daß jemand mit 'ftp://....' in der Adreßzeile eines IE surfen hat wollen?

Beste Grüße
Viennamade

[Ingo Turski]

Hi,

Brrr, 404 bedeutet, daß vorhandene URIs angesteuert wurden und IE-Browser die nicht bekommen haben?

Ja. der IE fordert bei bestimmten Funktionen erst "GET /_vti_inf.html HTTP/1.1" gefolgt von "POST /_vti_bin/shtml.exe/_vti_rpc" an.

Und bei der "Speichern unter..." Funktion lädt er unnötiger Weise die HTML-Seite nochmals neu, dann bei mir noch eine Grafik aus dem noscript-Bereich, die zuvor übergangen wurde (da JS aktiviert war), und dann eben diese - bei mir korrekt über @import eingebundenen - CSS-Dateien leider unter der URL Pfad/Titel%20der%20Seite%20-Dateien/Dateiname.css ;-)
Dieser Murks fällt dem Anwender erst auf, wenn er sich die gespeicherte Seite anschaut; dort fehlt dann nämlich ein Großteil des CSS. Und wenn er in den Quelltext sieht, ist der XHTML-Strict Doctype durch HTML Transitional ersetzt worden und natürlich jede Menge invalider Angaben hinzugefügt worden.

Aber das bringt mich gerade auf eine neue Idee für mein Auswertungsprogramm :-)
Ich werde diese 404er dazu nutzen, um die vom IE gespeicherten Seiten zu identifizieren. Eine schöne Ergänzung zur Angabe der gesetzten IE-Favoriten...

freundliche Grüße
Ingo

[Viennamade]

Hallo Ingo!

Danke für die Informationen!

Brrr, 404 bedeutet, daß vorhandene URIs angesteuert wurden und IE-Browser die nicht bekommen haben?
Ja. der IE fordert bei bestimmten Funktionen erst "GET /_vti_inf.html HTTP/1.1" gefolgt von "POST /_vti_bin/shtml.exe/_vti_rpc" an.

Diese _vti_inf.html und shtml.exe sind auf meinem WebSpace gar nicht drauf. Jedenfalls belasse ich die _vti-Verzeichnisse, schließlich will ich ja auch den IE-Nutzern problemlosen Besuch ermöglichen.

Jetzt frag ich mich, ob die _vti-Verzeichnisse überhaupt einen Sinn machen, wenn ich diese Zeilen (scheinbar Teil der Front-Page-Extensions) rausgenommen habe?
  AuthUserFile .../_vti_pvt/service.pwd
  AuthGroupFile .../_vti_pvt/service.grp

Mal sehen ...

Beste Grüße & Danke
Viennamade

[Ingo Turski]

Hi,

Diese _vti_inf.html und shtml.exe sind auf meinem WebSpace gar nicht drauf. Jedenfalls belasse ich die _vti-Verzeichnisse, schließlich will ich ja auch den IE-Nutzern problemlosen Besuch ermöglichen.

Jetzt frag ich mich, ob die _vti-Verzeichnisse überhaupt einen Sinn machen, wenn ich diese Zeilen (scheinbar Teil

nein. Du kannst die Verzeichnisse AFAIK problemlos löschen. Ob vorhanden oder nicht - IE-User erhalten ohnehin einen 404.

freundliche Grüße
Ingo

[Viennamade]

Hallo!

Jetzt frag ich mich, ob die _vti-Verzeichnisse überhaupt einen Sinn machen, wenn ich diese Zeilen (scheinbar Teil
nein. Du kannst die Verzeichnisse AFAIK problemlos löschen. Ob vorhanden oder nicht - IE-User erhalten ohnehin einen 404.

Also eigentlich habe ich Deinen Thread-Einstieg so verstanden, daß IE-Nutzer den Fehler nur dann erhalten, wenn die _vti-Verzeichnisse nicht da sind. Jetzt verstehe ich ihn so, daß es schlicht ein IE-Fehler ist.
OK, ich lösche sie.

Beste Dank
Viennamade

[Ingo Turski]

Hi,

Also eigentlich habe ich Deinen Thread-Einstieg so verstanden, daß IE-Nutzer den Fehler nur dann erhalten, wenn die _vti-Verzeichnisse nicht da sind.

genauer gesagt: auf meinem Webspace gibt es weder FP-Erweiterungen noch ein _vti-Verzeichnis noch solche obskuren Dateien und auch keinerlei Serverausgaben, die einen Zugriff provozieren würden. Die nicht existierenden Dateien in dem nicht vorhandenem Verzeichnis werden also ganz ohne ersichtlichen Grund vom IE angefordert. Natürlich nicht von allen, sondern nur ein paar wenigen. Keine Ahnung, was die Leute da eingestellt haben.

freundliche Grüße
Ingo

[Der Martin]

Hi,

• Fi!

Jetzt hast du es geschafft, mich tief zu verblüffen (aber nicht zu verunsichern).

nunja, lediglich die Logfles erhalten ein paar 404er von IE-Usern - bei mir im August 51* /_vti_inf.html

Du willst uns doch nicht erzählen, dass der IE ohne erkennbaren Grund nach solchem _vti* sucht? Also mein Hobby-Server läuft jetzt schon etwa ein halbes Jahr, aber solche Einträge hatte ich bisher _noch nie_ im Log. Und dabei hatte ich - weiß Gott! eine Menge Zugriffe von IEs, und etliche eindeutige Hack-Versuche (natürlich alle erfolglos). Auch irgendwelchen MSOffice-Kram hab ich in _meinem_ Log noch nicht gesehen.
Fast alle 404er, die ich anbieten kann, resultieren aus versuchten Zugriffen auf die (früher nicht vorhandene) robots.txt, favicon.ico oder irgendwelche abstrusen "../../../scripts/xyz.dll?..." Konstruktionen. Oder gelegentlich aus klaren Fehlern meinerseits, z.B. fehlerhafte Links.
Wenn du also derartige Zugriffe im Log hast, muss das IMHO noch ganz andere Ursachen haben.
Was für einen UA melden die eigentlich?

zusätzlich zu den /MSOffice/cltreq.asp?... und den fehlerhaften CSS-Anforderungen ala pfad/Inhalt des title -Dateien/datei.css ;-)

Auch das kann ich nicht nachvollziehen.

Ach ja: Dass der IE die Seite neulädt, wenn ich sie lokal speichern will, ist allerdings wahr, auch wenn's eigentlich nicht nötig wäre (und bei dynamisch generierten Seiten auch problematisch).
Allerdings verursacht das meistens nicht viel Traffic, weil der IE anscheinend sowieso immer ein "If-Modified-Since" oder etwas ähnliches im Request mitschickt und sich dann mit einem "304 Not Modified" als Antwort zufriedengibt. Meinen Logs zufolge werden jedenfalls viele IE-Requests nur mit einem 304er beantwortet.

Mein eigener IE scheint solche Zugriffe auf "*_vti*" oder "MSOffice" übrigens auch nicht zu machen, aber um diese Aussage zu untermauern, habe ich meiner Desktop-Firewall eben mal einen Filter aus solche URLs gesetzt. Wollen wir doch mal sehen...!

Herzliche Grüße,

Martin

[Ingo Turski]

Hi,

Jetzt hast du es geschafft, mich tief zu verblüffen (aber nicht zu verunsichern).

gern gescheh' ;-)

Du willst uns doch nicht erzählen, dass der IE ohne erkennbaren Grund nach solchem _vti* sucht?

Wie ich unten schon schrieb: Ja.

Ich nehme mal aus der letzten Woche einen hierfür typischen Besuchsverlauf:

[02/Sep/2004]

932: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ?1024 *t
      Ref: http://www.google.de/search?hl=de&ie=UTF-8&q=berechnung+wohngeld&meta=
[20:53:13]     /prg/sozialberatung.html
[20:53:20]     /prg/Sozialberatung.xls
[20:53:32] 404 /_vti_inf.html
[20:53:33] 500 /_vti_bin/shtml.exe/_vti_rpc
[20:53:33]     /prg/Sozialberatung.xls
[20:54:43]     /
[20:54:44] 404 /_vti_inf.html
[20:54:44] 500 /_vti_bin/shtml.exe/_vti_rpc

Interessant ist, wie ich gerade festgestellt habe, daß die meisten dieser Anforderungen im Zusammenhang mit dem Download einer Excel-Datei stehen - allerdings nicht alle.

Auch irgendwelchen MSOffice-Kram hab ich in _meinem_ Log noch nicht gesehen.

Auch hierzu ein Beispiel:

[03/Sep/2004]

1004: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) ?1024 *t
      Ref: http://www.google.de/search?q=crea+dance&hl=de&lr=lang_de&ie=UTF-8&start=10&sa=N
[08:38:37]     /tanz/creacasino.html
[08:38:37] 500 /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=5606&STRMVER=4&CAPREQ=0
[08:38:37] 404 /MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=5606&STRMVER=4&CAPREQ=0

Du siehst: beide Male ein IE6, der Javascript akiviert hat, ein 1024er Fenster nutzt und sich (zufällig) über die Telekom eingewählt hat.

Ach ja: Dass der IE die Seite neulädt, wenn ich sie lokal speichern will, ist allerdings wahr, auch wenn's eigentlich nicht nötig wäre (und bei dynamisch generierten Seiten auch problematisch).
Allerdings verursacht das meistens nicht viel Traffic, weil der IE anscheinend sowieso immer ein "If-Modified-Since" oder etwas ähnliches im Request mitschickt und sich dann mit einem "304 Not Modified" als Antwort zufriedengibt. Meinen Logs zufolge werden jedenfalls viele IE-Requests nur mit einem 304er beantwortet.

Ich habe es selbst mit meinem IE getestet. Beim Speichern als Webseite wird die gerade übertragene Datei neu angefordert und auch komplett neu übertragen. 304er gibt's in diesem Fall nicht. Und wie schon gesagt: über die unsinnige Anforderung per import eingebundener CSS-Dateien geben IE-User eindeutig zu erkennen, daß und welche Seite sie gerade gespeichert haben - genauso wie bei favicon-Anforderungen beim Setzen eines Bookmarks.
Nur scheine ich (bis jetzt) der einzige zu sein, der das auch zur Auswertung nutzt;-)

freundliche Grüße
Ingo

[Viennamade]

Hallo!

Du willst uns doch nicht erzählen, dass der IE ohne erkennbaren Grund nach solchem _vti* sucht?
Wie ich unten schon schrieb: Ja.

Frontpage ist auf vielen Arbeitsplatz-PCs (wegen irgendwelcher OEM-Bundles).

Ich nehme mal aus der letzten Woche einen hierfür typischen Besuchsverlauf:
...

Dei Fehlermeldungen decken sich frappant mit diesen hier:
http://support.microsoft.com/default.aspx?scid=kb;en-us;185553

Ob vielleicht ein PC mit installiertem FP irgendetwas automatisch versucht g ?

Beste Grüße
Viennamade

[Der Martin]

Hi Ingo,

zu den komischen Excel/Office-Phänomenen habe ich jetzt auch noch einen Verdacht, der möglicherweise in eine ähnliche Richtung geht wie die Frontpage-Idee von Viennamade.

Ich vermute, dass _diese_ Folge von Requests entsteht, wenn der User ein Office-Dokument per OLE direkt im IE öffnet! Frontpage gehört ja bekanntlich auch zur Office-Familie, da liegen die ominösen _vti-Verzeichnisse nicht fern!
Da ich keine Office-Dokumente auf meinem Server habe, konnte ich diesen Effekt also noch nie beobachten.

Was hältst du von dem Erklärungsansatz?

Ich habe es selbst mit meinem IE getestet. Beim Speichern als Webseite wird die gerade übertragene Datei neu angefordert und auch komplett neu übertragen. 304er gibt's in diesem Fall nicht.

Ich hab's auch mit meinem lokalen Webserver gerade probiert: Die HTML-Datei wird tatsächlich komplett neu übertragen, bei den eingebauten Bildern, Stylesheets, Scripts etc. begnügt sich der Bursche mit der 304er-Antwort (MSIE 5.5).

Und wie schon gesagt: über die unsinnige Anforderung per import eingebundener CSS-Dateien geben IE-User eindeutig zu erkennen, daß und welche Seite sie gerade gespeichert haben

Ach so, nur bei der Einbindung mit @import? Okay, das mag sein.

genauso wie bei favicon-Anforderungen beim Setzen eines Bookmarks.

Ja, stimmt, das fordert der MSIE erst beim Bookmarken an. ;)

Ebenso freundliche Grüße

Martin

[Ingo Turski]

Hi,

zu den komischen Excel/Office-Phänomenen habe ich jetzt auch noch einen Verdacht, der möglicherweise in eine ähnliche Richtung geht wie die Frontpage-Idee von Viennamade.

die ich übrigens auch nicht von der Hand weisen würde.

Ich vermute, dass _diese_ Folge von Requests entsteht, wenn der User ein Office-Dokument per OLE direkt im IE öffnet! Frontpage gehört ja bekanntlich auch zur Office-Familie, da liegen die ominösen _vti-Verzeichnisse nicht fern!

Das dürfte eine Erklärung der weitaus meisten Fälle sein. Interessant vielleicht auch:

1522: Microsoft Data Access Internet Publishing Provider Cache Manager *t
      Ref: -
[13:30:01]     /
[13:30:01] 404 /_vti_inf.html
[13:30:01] 500 /_vti_bin/shtml.exe/_vti_rpc

und

2048: Mozilla/2.0 (compatible; MS FrontPage 4.0)
      Ref: -
[08:54:52] 404 /_vti_inf.html
[08:54:54] 500 /_vti_bin/shtml.exe/_vti_rpc

Übrigens scheint der IE hier überaus hartnäckig zu sein und auch überflüssigen Traffic zu erzeugen, wie dieses Beispiel zeigt:

[12/Aug/2004]

2064: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90) *t
      Ref: http://www.google.de/search?sourceid=navclient&hl=de&ie=UTF-8&q=wohngeld+berechnung
[10:42:33] 304 /prg/sozialberatung.html
[10:42:43] 304 /prg/Sozialberatung.xls
[10:42:47] 404 /_vti_inf.html
[10:42:47] 500 /_vti_bin/shtml.exe/_vti_rpc
[10:42:48]     /prg/Sozialberatung.xls
[11:04:11]     /
[11:04:11] 404 /_vti_inf.html
[11:04:11] 500 /_vti_bin/shtml.exe/_vti_rpc
[11:05:51] 404 /_vti_inf.html
[11:05:52] 500 /_vti_bin/shtml.exe/_vti_rpc
[11:05:52]     /prg/Sozialberatung.xls
[11:06:11] 404 /_vti_inf.html
[11:06:11] 500 /_vti_bin/shtml.exe/_vti_rpc
[11:06:12]     /prg/Sozialberatung.xls
[11:31:13]     /
[11:31:13] 404 /_vti_inf.html
[11:31:13] 500 /_vti_bin/shtml.exe/_vti_rpc

freundliche Grüße
Ingo