nicht angemeldet
Matthias Apsel
Gunnar Bittersmann
TS
Hallo, alle miteinander!
Ich arbeite gerade an einer Seite, ich nenne sie mal www.beispiel.de. Wenn ich mir die Unterseite www.beispiel.de/crm/inc/ausf_kggegenbest.php anzeigen lassen möchte, wird mir folgendes angezeigt:
Not Found The requested URL /inc/ausf_kggegenbest.php was not found on this server.
D.h., das "crm" wird einfach ausgeschnitten. Das ist ein generelles Problem, tritt also auch bei anderen Unterseiten und auch ohne "inc" auf oder bei absoluten Links.
Woran könnte das liegen und was kann ich machen?
Herzliche Grüße, Kerstin
Hallo Kerstin,
nutzt du ein CMS oder sowas? Und was meinst du mit "anzeigen lassen"?
Tippst du die URL in die Browserzeile ein oder meinst du damit, dass du einen Link anklickst?
liebe Grüße Klaus
Hallo Klaus,
Es wird mir in beiden Fällen falsch angezeigt, also sowohl, wenn ich es in die Browserzeile eingebe: Ich gebe ein: www.example.de/crm/inc/example.php, klicke auf Enter und plötzlich wird in der Browserzeile angezeigt: www.example.de/inc/example.php, also ohne das "crm" und ich bekomme die Fehlermeldung: Not Found The requested URL /inc/example.php was not found on this server.
Auch wenn ich den Link als absoluten Link in meinen Code schreibe, passiert bei Aufruf das Gleiche.
Herzliche Grüße, Kerstin
@@script42
Ich gebe ein: www.example.de/crm/inc/example.php
Nein, example.de ist keine der genannten Beispieldomains.
LLAP 🖖
Ach, so! Jetzt hab ich's verstanden! Danke für den Link!
Hallo script42,
Ich arbeite gerade an einer Seite, ich nenne sie mal www.beispiel.de.
Nenn sie besser example.com.
Bis demnächst
Matthias
Okay. Danke für den Hinweis!
@@Matthias Apsel
Ich arbeite gerade an einer Seite, ich nenne sie mal www.beispiel.de.
Nenn sie besser example.com.
Unter beispiel.de erschient jetzt eine Seite, die genauso aussieht wie die von der IANA registrierten Beispieldomains wie example.com – nur halt auf deutsch und halt nicht von der IANA registriert, sondern von der deutschen Firma Fireball Labs GmbH, die auch hinter der Suchmaschine Fireball stehen.
Sie geben an: „Beispiel.de wird für immer eine neutrale Beispieldomain bleiben, ähnlich wie example.com für den englischsprachigen Raum.“ Ob deren einziges Ziel mit dieser Seite ist, mehr Traffic auf ihre Suchmaschine zu bekommen – keine Ahnung.
Ob man denen mehr trauen kann als Google – keine Ahnung. Aber weniger geht ja eigentlich nicht.
LLAP 🖖
Ob man denen mehr trauen kann
Die Betreiber der Seiten nehmen den Service von adgoal in Anspruch. Adgoal ist ein Dienstleister der Vermarktungslösungen entwickelt und Webseitenbetreiber darin unterstützt, Werbeeinnahmen zu erzielen
Ich will es nicht nutzen.
als Google
whois example.com sagt:
organisation: Internet Assigned Numbers Authority
Die IANA. Also nicht google.
Hello,
Sie geben an: „Beispiel.de wird für immer eine neutrale Beispieldomain bleiben, ähnlich wie example.com für den englischsprachigen Raum.“ Ob deren einziges Ziel mit dieser Seite ist, mehr Traffic auf ihre Suchmaschine zu bekommen – keine Ahnung.
Ob man denen mehr trauen kann als Google – keine Ahnung. Aber weniger geht ja eigentlich nicht.
Jetzt fehlt mir persönlich der Button für "vielleicht", also weder "-", noch "+".
Ich mag hier keine Punkte vergeben, finde deinen Denkansatz aber trotzdem diskussionswürdig — dann ab er bitte mit Belegen!
Liebe Grüße
Tom S.
Ich gehe davon aus, dass der Webserver ein Apache ist. Falls nicht müssen wir das wissen!
Hinweis: Es ist eine "versteckte" Datei (beginnt mit einem Punkt). Je nachdem womit Du auf den Server zugreifst musst Du die Anzeige dieser "versteckten" Dateien erlauben.
Hinweis: Du kannst diese Datei '.htaccess' NICHT mittels http://example.org/.htaccess abholen. Gänge das so bestände ein Sicherheitsproblem.
Vermutlich ist mod_rewrite konfiguriert und Dir wird angezeigt, dass die Ressource mit der umgeschriebenen URL nicht gefunden wurde.
Und vermutlich hat das mal jemand mit voller Absicht konfiguriert.
Deshalb folgende Fragen an Dich, die unbedingt wahrheitsgemäß beantwortet werden müssen:
Noch etwas: Laut der URL handelt es sich womöglich um ein "CRM" also "Customer-Relationship-Management". Das ist im Regelfall keine triviale Software an der man mal eben ein wenig rumschreibt. Denn bei sowas sollten die Sicherheitsvorkehrungen "paranaoid" sein. Dazu zählt:
Liebe Regina,
danke für Deine Antwort.
Ja, es handelt sich um ein Customer-Relationship-Management-System, aber das habe ich selbst angefangen zu basteln und es deshalb in den Ordner crm verfrachtet. Es befindet sich auf einem Webhosting-Apache-Server von Hetzner. Die .htaccess, die ich auch selbst erstellt habe, sagt folgendes:
MudGuard
Tabellenkalk# Set the default handler
DirectoryIndex seite_im_aufbau.html index.php index.html index.htm
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
# 301-Weiterleitung von http auf https
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]
php_flag log_errors on
Liebe Grüße, Kerstin
Ok. Jetzt ist unklar welche .htaccess das ist. Wir brauchen:
Wir brauchen alle 3 (soweit vorhanden) und zwar mit der Angabe, welche welche ist.
Daraus ergeben sich womöglich weitere Fragen.
ein Customer-Relationship-Management-System, aber das habe ich selbst angefangen zu basteln
Sowas ist keine "Bastelarbeit".
... und damit wurde das Problem gelöst! Beim Nachsehen habe ich festgestellt, dass sowohl in $_SERVER['DOCUMENT_ROOT']/ als auch in $_SERVER['DOCUMENT_ROOT']/crm/ die gleiche .htaccess lagen. Nachdem ich sie aus dem /crm/ gelöscht hatte, tritt das Problem nun nicht mehr auf.
Vielen Dank! 😀
P.S. Warum keine Bastelarbeit? Ich bastel schon seit geraumer Zeit dran rum... 😉 Ist mein Projekt, um php zu lernen.
P.S. Warum keine Bastelarbeit? Ich bastel schon seit geraumer Zeit dran rum... 😉 Ist mein Projekt, um php zu lernen.
Ein CRM enthält regelmäßig zu viele unternehmenskritische Daten.
Wenn es nur für Dich ist und Du a) eine 1-"Mann"-Firma bist und b) so 3 bis 10 Kunden verwalten willst mag das durchgehen. Es sind aber schon Firmen den Bach runter gegangen, weil unternehmenskritische Anwendungen "gebastelt" wurden.
Der gröbste mir bekannt gewordene Fall war eine deutsche Firma mit rund hundert Beschäftigten, deren Produktionssteuerungssystem von einem Pole in Excel (mit VBA) gebastelt wurde. Und zwar unter Nichtbeachtung von einfachsten Regeln des Programmierens:
Es war "historisch gewachsen", inzwischen komplett unpflegbar - und der Pole war weg. Als ich das - mit weit aufgerissenen Augen - gesehen habe, hab ich klipp und klar gesagt, dass das früher oder später zum Untergang des Unternehmens führen wird.
:-) Ja, das klingt gruslig! Aber in meinem Fall ist es tatsächlich ein Lernprojekt für ein Kleinstunternehmen, das bisher auch noch nicht von der Leine gelassen wurde. (Das Projekt meine ich... - also noch keine Produktivumgebung) Daten sind in eine Datenbank ausgelagert, Variablen und Funktionen haben deutsche Namen und Dokumentation findet meist auch statt... ;-)
Danke für Eure Hilfe hier im Forum,
herzliche Grüße Kerstin
Hallo Regina,
leider habe ich zu frühzeitig Entwarnung gegeben. Nun tritt das Fehlverhalten wieder auf. Einzige vorliegende .htaccess - jedenfalls was mich betrifft, ev. gibt es von Hetzner ja auch noch Grundeinstellungen, über die ich nichts weiß - ist die oben eingestellte, die jetzt im root-Verzeichnis public_html liegt.
Herzliche Grüße Kerstin
hallo
leider habe ich zu frühzeitig Entwarnung gegeben. Nun tritt das Fehlverhalten wieder auf. Einzige vorliegende .htaccess - jedenfalls was mich betrifft, ev. gibt es von Hetzner ja auch noch Grundeinstellungen, über die ich nichts weiß - ist die oben eingestellte, die jetzt im root-Verzeichnis public_html liegt.
Ich sehe, deine .htaccess verwendet 301 permanent Redirect. Das ist schlecht zum testen. Verwende 302
Danke, beatovic!
Ist das auch relevant, wenn ich auf den betroffenen Unterseiten <meta name="robots" content="noindex, nofollow"> stehen habe?
Herzliche Grüße Kerstin
<meta name="robots" content="noindex, nofollow">
bedeutet nur, dass Suchmaschinen, die Seite nicht in den Index aufnehmen und Limks generell nicht folgen sollen.
Auf normale Webbrowser hat das keinen Einfluss: Lösche mal den Browser-Cache.
Noch ein Tipp:
Ich untersuche sowas auf die schnelle mit wget -d --delete-after URL. Ergeben sich aus dem HTTP-Header Unterschiede zum Verhalten des Browser muss ich tiefer forschen.
Liebe Regina,
ich habe nun beides gemacht und jetzt funktioniert es wieder! Vielen Dank! Kannst Du mir noch erklären, was das 302 damit zu tun hat oder war das nur nebenbei bemerkt wegen des Testens allgemein?
Herzliche Grüße Kerstin
Wenn das Cachen erlaubt ist kann sich der Browser womöglich auch die Weiterleitung mit dem Statuscode 302 ("permanent", im Gegensatz zu 301: "nur jetzt") merken. Das heisst: Er bekommt den Auftrag, eine URL abzuholen, schaut im Cache nach, ob er das da schon mal hat (und findet die Weiterleitung).
Also geht er - ohne den Server nochmal zu fragen - gleich zur neuen URL. Genauer: Er fragt erst wieder seinen Cache ob der das Zeug kennt...
Das Vorstehende ist übrigen seine stark vereinfachte Variante, weil es noch COOKIES, POST-Daten und etliche Regeln für das Cachen gibt, die zum Teil für den Browser, zum Teil für cachende Proxys oder für beide gelten.
beatovich hat es angedeutet: HTTP 302
Lösche mal den Browser-Cache.
Ok. Jetzt ist unklar welche .htaccess das ist. Wir brauchen:
- $_SERVER['DOCUMENT_ROOT']/.htaccess
- $_SERVER['DOCUMENT_ROOT']/crm/.htaccess
- $_SERVER['DOCUMENT_ROOT']/crm/inc/.htaccess
Wir brauchen alle 3 (soweit vorhanden) und zwar mit der Angabe, welche welche ist.
Daraus ergeben sich womöglich weitere Fragen.
ein Customer-Relationship-Management-System, aber das habe ich selbst angefangen zu basteln
Sowas ist keine "Bastelarbeit".
Also das da oben sieht aber so ziemlich wie eine Bastelarbeit aus. Nichts ist schlimmer als eine verteilte (dezentrale) Konfiguration. Und SoftwareKomponenten wie /crm und /inc im URL abzubilden ist auch so eine Unsitte.
MfG
Tach!
Und SoftwareKomponenten wie /crm und /inc im URL abzubilden ist auch so eine Unsitte.
Woraus entnimmst du, dass das keine Begriffe des Anwendungsfalles sind? CRM ist die übliche Abkürzung für Customer Relationship Management (Kundenbeziehungsmanagement) und steht hier auch dafür. Das ist also nicht nur eine "Software-Komponente". Auch inc steht nicht notwendigerweise für include, es kann zum Beispiel auch incorporation bedeuten. Selbst wenn es für include steht, ist damit nicht gesagt, dass das serverseitig zu inkludierende Code-Dateien sind. Es kann sich auch um CSS, JS oder Bilder handeln.
dedlfix.
Tach!
Und SoftwareKomponenten wie /crm und /inc im URL abzubilden ist auch so eine Unsitte.
Woraus entnimmst du, dass das keine Begriffe des Anwendungsfalles sind? CRM ist die übliche Abkürzung für Customer Relationship Management (Kundenbeziehungsmanagement) und steht hier auch dafür. Das ist also nicht nur eine "Software-Komponente".
Das Verzeichnis wird in dem Moment zur SW Komponente wenn eine andere Konfiguration für dieses Verzeichnis greift.
Auch inc steht nicht notwendigerweise für include, es kann zum Beispiel auch incorporation bedeuten. Selbst wenn es für include steht, ist damit nicht gesagt, dass das serverseitig zu inkludierende Code-Dateien sind. Es kann sich auch um CSS, JS oder Bilder handeln.
Includieren ist auf jeden Fall eine der SW vorbehaltene Handlung.
Und was das für Probleme mit sich bringt sehen wir doch hier!
MfG
Tach!
Woraus entnimmst du, dass das keine Begriffe des Anwendungsfalles sind? CRM ist die übliche Abkürzung für Customer Relationship Management (Kundenbeziehungsmanagement) und steht hier auch dafür. Das ist also nicht nur eine "Software-Komponente".
Das Verzeichnis wird in dem Moment zur SW Komponente wenn eine andere Konfiguration für dieses Verzeichnis greift.
Ich verstehe nicht, was du damit aussagen möchtest.
Auch inc steht nicht notwendigerweise für include, es kann zum Beispiel auch incorporation bedeuten. Selbst wenn es für include steht, ist damit nicht gesagt, dass das serverseitig zu inkludierende Code-Dateien sind. Es kann sich auch um CSS, JS oder Bilder handeln.
Includieren ist auf jeden Fall eine der SW vorbehaltene Handlung.
Ja klar, aber nicht so, wie du das vermutlich gerade meinst, wenn du SW mit serverseitige Software meinst. Inkludieren ist ein ziemlich allgemeiner Begriff, der nicht nur beispielsweise PHPs include/require umfasst, sondern auch alle anderen Arten der Dateineinbindung. Auch sowas wie <link href="style.css" rel="stylesheet"> oder <img src="bild.png"> gehört zu den Dingen, die man inkludieren/einbinden kann. Was es hier im konkreten Fall ist, kannst du nicht aus lediglich den Wörtern "crm", "inc" und der Kenntnis, dass es eine .htaccess gibt, ableiten.
Und was das für Probleme mit sich bringt sehen wir doch hier!
Ich sehe da noch gar nichts konkretes, außer dass es irgendein Problem mit der verzeichnisindividuellen Konfiguration gibt. Ob das ein strukturelles Problem ist, könnte ich zumindest bei den derzeit bekannten Informationen nur hellsehen.
dedlfix.
Danke Dedlfix! Nun, zumindest hat sich in diesem Fall das Problem gelöst, ohne die Verzeichnisstruktur zu ändern… Darüberhinaus werde ich aber auch Reginas Ratschläge zur Umsetzung bringen, denn in meinem Fall handelt es sich tatsächlich um Ausführungsdateien, auch wenn Du richtig schreibst, dass man das dem "inc" allein nicht entnehmen kann.
Herzliche Grüße Kerstin
Hallo pl, Ich habe doch gar keine dezentrale Konfiguration! 😀 Das wurde nur nachgefragt! Im Moment gibt es eine einzige .htaccess im root-Verzeichnis.
Ansonsten mag es ja sein, dass ich ein paar "Unsitten" drin habe. Schließlich fange ich gerade erst an zu programmieren. Dann wäre ich froh über Aufklärung und Verbesserungsvorschläge. Momentan ist das crm als "Backoffice" hinter der eigentlichen Homepage geplant, daher in einem eigenen Unterordner. Die includes sind tatsächlich leider keine Bilder oder css, wie netterweise von dedlfix nicht ausgeschlossen, sondern Ausführungsdateien, aber gerade deshalb wird man sie im Ernstfall ja auch selten in der URL zu Gesicht bekommen, da sie über header direkt wieder an Dateien außerhalb weiterleiten, oder habe ich da ein falsches Verständnis?
Herzliche Grüße Kerstin
Die includes sind tatsächlich leider keine Bilder oder css, wie netterweise von dedlfix nicht ausgeschlossen, sondern Ausführungsdateien, aber gerade deshalb wird man sie im Ernstfall ja auch selten in der URL zu Gesicht bekommen,
Ändere "selten" zu "gar nicht, nie und nimmer" und sperre das Verzeichnis /inc/ gegen jeden Zugriff via http. Dafür ist .htaccess wirklich gedacht. Bei sicherheitskritischen Anwendungen täuscht man zusätzlich einen 404er (Not Found) statt dem 403er (Forbidden) vor.
Ah, siehst Du - wieder was gelernt! Ich konnte mit dem Namen "htaccess" nie wirklich etwas anfangen, aber in diesem Zusammenhang macht er Sinn! Die Datei regelt eben den "htaccess"... ;-) Danke!
Den Rest werde ich auch machen. Vielen Dank für all die hilfreichen Tipps, Regina!
Tach!
Ah, siehst Du - wieder was gelernt! Ich konnte mit dem Namen "htaccess" nie wirklich etwas anfangen, aber in diesem Zusammenhang macht er Sinn! Die Datei regelt eben den "htaccess"... ;-)
Noch besser ist, solche Dateien, die keine auszuliefernden Inhalte haben, außerhalb des DocumentRoot abzulegen. Dann kann man die auch ohne eine Ausschluss-Konfiguration im Webserver nicht direkt übers Web abfragen. Übers Dateisystem kann PHP aber sehr wohl zugreifen. Wenn man dann keine ../../Relativ-Angaben-Orgien feiern möchte, kann man auch den include_path für PHP konfigurieren.
dedlfix.
Tach!
Noch besser ist, solche Dateien, die keine auszuliefernden Inhalte haben, außerhalb des DocumentRoot abzulegen.
Nur, da habe ich glaube ich keinen Zugriff. Ist ja nur ein Webhosting-Paket. Oder meinst Du, einfach die ganze Verzeichnisstruktur eine Ebene tiefer zu setzen, sozusagen auch den "Root-Knoten" verschieben - wenn man das so sagen darf - und dann die incs auf gleiche Ebene zu legen?
Dann kann man die auch ohne eine Ausschluss-Konfiguration im Webserver nicht direkt übers Web abfragen. Übers Dateisystem kann PHP aber sehr wohl zugreifen. Wenn man dann keine ../../Relativ-Angaben-Orgien feiern möchte,
😀
kann man auch den include_path für PHP >konfigurieren.
Interessant!
Kerstin
Wenn man dann keine ../../Relativ-Angaben-Orgien
define ('MY_INCLUDE_DIR', '/foo/bar/tok/lib/');
require_once MY_INCLUDE_DIR . 'libary.php';
tut es ohne diese Orgie. Außerdem gäbe es noch spl_autoload - aber das mag ich persönlich nicht.
Tach!
Wenn man dann keine ../../Relativ-Angaben-Orgien
define ('MY_INCLUDE_DIR', '/foo/bar/tok/lib/'); require_once MY_INCLUDE_DIR . 'libary.php';tut es ohne diese Orgie.
Ja, aber den include_path kann man auch mit einer einzelnen Zeile definieren/erweitern und braucht dann nicht zu jeder Datei einen Vorsatz anführen.
dedlfix.
... und braucht dann nicht zu jeder Datei einen Vorsatz anführen.
Ich weiß. Ist mir persönlich aber unangenehm. Ich tippe lieber mehr weil ich GENAU sehen will, was ich dem werten Herrn Interpreter für Aufgaben stelle. Kannst Du als Macke abtun.
Hi,
Ja, aber den include_path kann man auch mit einer einzelnen Zeile definieren/erweitern und braucht dann nicht zu jeder Datei einen Vorsatz anführen.
und irgendwann hat man dann in unterschiedlichen Verzeichnissen im includepath Dateien mit demselben Namen, und wundert sich, warum immer die falsche Datei includiert wird …
cu,
Andreas a/k/a MudGuard
Tach!
Ja, aber den include_path kann man auch mit einer einzelnen Zeile definieren/erweitern und braucht dann nicht zu jeder Datei einen Vorsatz anführen.
und irgendwann hat man dann in unterschiedlichen Verzeichnissen im includepath Dateien mit demselben Namen, und wundert sich, warum immer die falsche Datei includiert wird …
Hat man das? Hatte ich noch nicht. Aber vielleicht strukturiere ich das einfach so, dass das nicht vorkommen kann. Es geht nicht darum, jedes einzelne Verzeichnis in den include_path zu legen, sondern den include_path auf das Abseits-des-DocumentRoot-Verzeichnis zeigen zu lassen, in dem man das nicht direkt zu erreichende Zeug lagert. So bleibt der Inhalt darin eindeutig ansprechbar. Wenn es dann noch Probleme mit Dopplungen gibt, sollte man sich eher fragen, warum man nun immer noch Zeug inkludiert, das nicht im Abseits-Verzeichnis liegt.
dedlfix.
Hello,
Ja, aber den include_path kann man auch mit einer einzelnen Zeile definieren/erweitern und braucht dann nicht zu jeder Datei einen Vorsatz anführen.
Ja, das ist das Problem!
Wer "brauchen" ohne "zu" gebraucht, verwendet "include_path" auch ohne Struktur :-P
Siehe hierzu MudGuard
First hit applies
Liebe Grüße
Tom S.
Hallo,
braucht dann nicht zu
Wer "brauchen" ohne "zu" gebraucht,
hat er doch…
scnr
Gruß
Kalk