htAccess im Subordner nicht verwendet?

[k.arts]

Hallo!

Ich habe folgendes Problem:
Ich hab auf einem server (der von alice kommt, also kein Zugriff auf conf datei) in einem Verzeichnis /a eine htAccess Datei.
Der Inhalt:
AuthType Basic
AuthName "geschützter Bereich"
AuthUserFile a/secure/.htpasswd
Require valid-user

Soweit so gut. Funktioniert alles, ich kann mich nur mit Username und Password anmelden.

Nun habe ich ein weiteres Verzeichnis: a/privat
In diesem Verzeichnis befinden sich wichtige Daten, die nicht gelesen werden dürfen, (php Files, ...) am besten auch dann nicht, wenn ein Passwort eingegeben wurde.
Also hat das Verzeichnis ebenfalls ein htAccess file:
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
Options None

Bisher hab ich vermutet, dass alles klappt, bis ich im browser http://server/a/private/irgendeineDatei.php aufgerufen habe. Schwupps wurde diese Datei gestartet.
Wenn ich im Browser http://server/a/private/ angebe wird zumindest "Nicht erlaubt" ausgegeben. Das passiert aber auch, wenn ich die htAccess Datei in a/privat lösche.
Wird diese Datei nicht verwendet? Muss ich etwas tun, damit die a/htAccess Datei diese nicht überschreibt? Oder muss ich den url Zugriff anders schützen?

Vielen Dank für Eure Antworten!

[k.arts]

Hallo nochmal!

Dummerweise hab ich die htaccess datei im Subordner privat ".htAccess" genannt statt ".htaccess" ...

Jetzt scheint es zu klappen, allerdings etwas zu gut... Eine html datei aus /a kann nicht mehr auf php Dateien aus a/private zugreifen. Obwohl ich in der htaccess datei in a/privat A
Order deny,allow
Deny from all
Allow from 127.0.0.1
stehen habe. Müsste damit nicht der interne Zugriff klappen?

Danke!

[Nobbie]

Eine html datei aus /a kann nicht mehr auf php Dateien aus a/private zugreifen.

Ich wüßte auf Anhieb gar nicht, wie man überhaupt aus einer HTML Datei auf eine PHP Datei "zugreift". Was verstehst Du unter "intern zugreifen"?

[k.arts]

Hi

Ich greife auf die php Datei per Ajax zu (also javascript in der html)

Gruß

[Nobbie]

Ich greife auf die php Datei per Ajax zu (also javascript in der html)

Na also.

Und wer oder was führt den JavaScript Code aus? Apache (der Server) direkt (wie bei PHP), oder der Browser?

Natürlich der Browser, Apache kennt kein JavaScript.

Und wenn Dein Browser den Zugriff ausführt, welcher Rechner ist das (aus Sicht des Webservers)? Irgendein (weit entfernter) Client, aber ganz sicher nicht der Webserver selbst.

Dein Rechner zu Hause greift mit seiner Public WAN IP (meistens die IP des Routers) auf Deinen Webserver zu - und das ist nie "127.0.0.1".

[k.arts]

Ja stimmt schon Ich mach das einfach zu selten^^

Okay, nehmen wir nun an, ich habe unter a/privat eine php Datei die alle Anfragen an andere php Dateien weiterleitet... Kann ich dann den Rest privat machen und nur den Zugriff vom Localhost erlauben? Wohl nicht oder?

Falls nicht, gibt es dann trotzdem eine Möglichkeit wie ich vor Zugriff schützen kann?

Grüße

[Nobbie]

Okay, nehmen wir nun an, ich habe unter a/privat eine php Datei die alle Anfragen an andere php Dateien weiterleitet...

Auf welche Weise "weiterleitet"?

Kann ich dann den Rest privat machen und nur den Zugriff vom Localhost erlauben? Wohl nicht oder?

Keine Ahnung, ich verstehe kaum, was Du eigentlich machen willst. "Den Rest privat machen" - hä?? Das sind keine Vokabeln, die ich im Zusammenhang mit Webservern und Rechten kenne.

Falls nicht, gibt es dann trotzdem eine Möglichkeit wie ich vor Zugriff schützen kann?

Was willst Du schützen, in welchem Kontext willst vor "Zugriff" schützen? Was für ein Zugriff?

[k.arts]

Hi!

Sorry wenn ich mich etwas unklar ausdrücke... Ich komme nicht aus der Server / Apache / etc Welt

Also ich habe eine PHP Schnittstelle (die über javascript angesteuert wird). Diese Php Seite wiederum greift auf andere php seiten zu (Module wenn man so will). Die Frage ist, kann ich diese anderen php Module schützen, vor runterladen, Zugriff etc. Es geht darum, dass in diesen Modulen wichtige Berechnungen durchgeführt werden, die den Mitbewerbern meines Kunden nicht in die Hände fallen sollen. Mir ist klar, dass ein Zugriff auf diese Daten nur möglich ist, wenn man direkt über die URL anfragt (und einen Passwortschutz umgeht), aber ich möchte möglichst alles ausschließen.

Ich habe nun aber schon probiert mit Hilfe der Files Direktive einige PHP Dateien (nicht das Interface, dass von Javascript gestartet wird) zu schützen. Und es scheint zu funktionieren. (hierzu hab ich allerdings schon einen neuen Thread erzeugt, da ich da auch ein kleines Problem habe). Also von daher könnte dieser Thread dicht gemacht werden. Ich hoffe trotzdem, dass verstanden wird, was ich eigentlich will. Wie gesagt, ich beschäftige mich normalerweise nicht mit sowas.

Vielen Dank für die Hilfe bisher!

[Nobbie]

Also ich habe eine PHP Schnittstelle (die über javascript angesteuert wird).

Ne, so wird das nix. "Angesteuert" ist wieder genau so ein nichtssagender Müll (sorry). Du mußt endgültig lernen, die Vokablen zu benutzen, die es für diese Dinge gibt. Ich rate mal, dass Du in JavaScript mittels AJAX einen HTTP Request auf eine Seite machst, und dort wird dann ein PHP Script gestartet. Stimmt das so?

Diese Php Seite wiederum greift auf andere php seiten zu (Module wenn man so will).

Nein, will man so nicht, ist wieder Scheiße, langsam nervts echt. "Zugreifen" kann man auf eine fettige Pommes, vielleicht auch auf eine Datei (da aber bereist muss man einen Kontext angeben). Was macht die PHP Datei mit den anderen "Seiten" (auch "Seiten" gibt es nicht, das ist auch Müll)? Meinst Du vielleicht, dass ein PHP Script ein weiteres Script "includiert" (mittels include() einfügt)?

Die Frage ist, kann ich diese anderen php Module schützen, vor runterladen, Zugriff etc. Es geht darum, dass in diesen Modulen wichtige Berechnungen durchgeführt werden, die den Mitbewerbern meines Kunden nicht in die Hände fallen sollen. Mir ist klar, dass ein Zugriff auf diese Daten nur möglich ist, wenn man direkt über die URL anfragt (und einen Passwortschutz umgeht), aber ich möchte möglichst alles ausschließen.

Ist es Dir jemals gelungen, so ein PHP Script im Sourcecode(!) herunterzuladen? Was passiert, wenn ein Anwender die Adresse eines PHP Scripts in seine Browserzeile eingibt? Wird dann der Sourcecode angezeigt? Beispielsweise hier im Forum: Siehst Du da den Source? Oder siehst Du das Ergebnis dessen, was das PHP Script ausgibt, nachdem es von Apache durch den PHP Interpreter geschickt wurde?

Wenn Du diese Frage erst einmal beantwortet hast, wirst Du vielleicht merken, dass Du völlig auf einem Holzweg läufst. Dennoch könnte man (wenn Du endlich genauer beschreibst, was eigentlich "zugreifen" bedeutet) möglicherweise einige der PHP Scripte (und zwar alle diejenigen, die nicht direkt via HTTP Request aufgerufen werden, sondern die nur "included" werden) zusätzlich so auf dem Server speichern, dass man ÜBERHAUPT NICHT via Apache (von außen) dran kommt. Das ist denkbar einfach, man muss sie nur außerhalb des DocumentRoots speichern.

Wie gesagt, ich beschäftige mich normalerweise nicht mit sowas.

Sondern? Und wieso tust Du es jetzt?

[k.arts]

Hallo Nobbie!

Wenn Du Dich so sehr an meinen Begriffen störst, kannst Du es entweder nett sagen, oder aber Dich gar nicht äußern.

Ich hatte gehofft, hier Hilfe zu bekommen, stattdessen werde ich hier nur angemacht. Naja kennt man ja von Foren. Wenn Du nichts besseres zu tun hast, als Leute zu beleidigen, tust Du mir leid.

Wenn ich von "zugreifen" rede, dann ist ja wohl vollkommen klar, was ich meine oder? Siehst Du, Du hast auch verstanden, dass ich PHP Scripts include. Und ja, es sind scripts und keine Seiten So was nenne ich Korinthenkackerei.

Ich bin davon ausgegangen, dass man die PHP Seiten, wenn nicht weiter geschützt herunterladen bzw. irgendwie einsehen kann.
Wenn dem nicht so ist, auch gut. Es gibt noch andere Daten die ich schützen muss und die plain Text sind.

Aber egal, ich werde meine "Apache Friends" Zeit hiermit beenden. Beleidigen lassen kann ich mich auch woanders...
Wofür stand das "Friends" nochmal?

Whatever

[Altrea]

Wenn Du Dich so sehr an meinen Begriffen störst, kannst Du es entweder nett sagen, oder aber Dich gar nicht äußern.

Ich hatte gehofft, hier Hilfe zu bekommen, stattdessen werde ich hier nur angemacht. Naja kennt man ja von Foren. Wenn Du nichts besseres zu tun hast, als Leute zu beleidigen, tust Du mir leid.

Nobbie ist vielleicht manchmal etwas direkt in dem was er sagt, aber beleidigend wird er eigentlich nicht.
Er versucht dir nur deutlich zu machen, dass deine Begriffe die du verwendest im besten Fall zwei-, meistens sogar vieldeutig zu interpretieren sind.

Wenn ich von "zugreifen" rede, dann ist ja wohl vollkommen klar, was ich meine oder? Siehst Du, Du hast auch verstanden, dass ich PHP Scripts include. Und ja, es sind scripts und keine Seiten So was nenne ich Korinthenkackerei.

Zugreifen ist ganz und garnicht klar formuliert. Man kann ein PHP Script beim Server anfragen/anfordern, oder als Datei (sofern man Verzeichniszugriffsrechte besitzt) auf diverse Arten kopieren/einsehen, was auch immer. Dass du Dateien per include einbindest, hast du vorher in keinem Wort erwähnt und wurde von Nobbie lediglich vermutet. Auf Vermutungen kann man aber keine wirkliche Hilfeleistung (schon garnicht in einem Forum, wo es eh schon schwer genug fällt jemandem zu helfen) leisten. Du musst immer im Hinterkopf behalten, dass wir keine Einsicht in deinen Code und deine Struktur haben und deshalb angewiesen sind auf die Informationen, die du uns lieferst.

Ich bin davon ausgegangen, dass man die PHP Seiten, wenn nicht weiter geschützt herunterladen bzw. irgendwie einsehen kann.

Und woher sollten wir wissen, dass dieses Missverständnis besteht? Hellsehen können wir (zum Glück/leider) nochnicht.

Wenn dem nicht so ist, auch gut. Es gibt noch andere Daten die ich schützen muss und die plain Text sind.

Mit adequaten Informationen, kann man da vielleicht sogar eine Lösung heraus erarbeiten.

Aber egal, ich werde meine "Apache Friends" Zeit hiermit beenden. Beleidigen lassen kann ich mich auch woanders...

Reisende soll man nicht aufhalten. Du warst derjenige, der um Hilfe ersucht hat. Ohne die nötigen Informationen war dies ein hoffnungsloses Unterfangen.

Ich hoffe, ich wurde nicht zu beleidigend.

Mit besten Grüßen