Hallo Freunde.

Mein Hauptmenü wird per '(PHP) include' eingebunden.

Jetzt möchte ich für Admin-Aufgaben ein Admin-Menü aus einem geschützten Verzeichnis laden und statt dessen an der gleichen Stelle einbinden.

Funktioniert prächtig, ... zu prächtig!
Ich werde nämlich nicht nach dem Passwort gefragt.

Eine einfache kleine test-dummi.html aus dem selben geschützten Verzeichnis verlangt hingegen User & Passwort, also so wie es sein soll.

Wie heißt der Hund, und wo liegt er begraben.

Wär' ganz nett wenn mir jemand auf die Sprünge helfen könnte...

Viel Gruß
HH.

Mit Passwort geschützt meinst du vermutlich einen .htaccess Schutz? Dieser funktioniert auf HTTP Ebene, d. h. ein HTTP Request landet in der Passwortabfrage. PHP arbeitet mit Include auf Dateiebene, weshalb der Schutz nicht greift. Eine eventuelle Passwortabfrage wirst du also mit PHP realisieren müssen.

Aha! OK!


Danke für die schnelle Antwort.

...und wenn ich erwäge ich die komplette admin.php in das geschützte Verzeichnis zu stellen?
Allerdings würde ich nicht alle dazugehörigen CSS, Bilder, Includes, jsScripts hier redundant deponieren wollen.
Ich nehme an, dass man Einstellungen in der .htacess vornehmen kann, die die relativen Pfade in die richtige Richtung lenken.

Ich kenne mich mit Apache, htacess, und der gleichen allerding nicht aus und wüßte nicht einmal welchen Namen das Problem überhaupt hat.

Ich hatte eigentlich an eine schnelle, 'kleine' Lösung gedacht.
Die Programmierung einer Passwortabfrage wäre denkbar, aber ich bin in meinem PHP-Handbuch erst halb durch...
...in ein paar Wochen vielleicht.


Kannst Du auch .htaccess?
HH.

Hallo,

gibt es einen Grund, warum Du das so lösen willst?

Ich programmiere mir meist einen eigenständigen Admin-Bereich (sofern notwendig) in einem geschützten Ordner, der auf den grafischen Schnickedöns der Mainpage verzichtet: Geht a) schneller und lässt sich b) viel einfacher pflegen. Und wenn man ein eigenes Konzept erarbeitet hat, lässt er sich auf nahezu allen von einem programmierten Webseiten problemlos verwenden, ohne dass man jedesmal irgendwo groß was anpassen muss. Motto: Der muss nicht "schön" sein, sondern funktional.

Greetz
cw

Hallo Hühnerflügel

Solche anspruchslosen schnörkellosen 0815-Anwendungen mach' ich mir immer wieder mal zwischendurch, und pfeif dabei auf Passwortschutz (Hoppla, hat das jemand gehört...?)

Aber irgendwann am Ende soll auch mal ein anderer oder andere (Plural) Benutzer damit umgehen können. Außerdem möchte ich zum Teil sofortige Kontrolle darüber wie sich ein neuer Inhalt oder geänderte Parameter auf das Gesamtsystem auswirken. Am Ende wird es wohl ein ausgewachsenes CMS werden...

Ich bin auf dem Wege zu einer 'Bastellösung' ohne htaccess und ohne Verzeichnisschutz, weil ich annehme, dass PHP selber genügend Schutz aus sich selber heraus bietet.

Außerdem lohnt sich meine WebSite für Internet-Terroristen sowieso nicht...

Die Lösungen interessieren mich zwar immer noch, rein akademisch, für ein anderes Mal, und überhaupt, besonders die mit .htaccess, ... aber es brennt nicht mehr.

Viel Gruß
HH.

Moin,

na, da hast Du Dir ja was vorgenommen. Aber wenn Du CMS wie z.B. joomla anschaust oder Foren wie z.B. phpBB, die haben alle ein eigenständiges Adminsystem, dass nicht in die eigentliche Webseite eingebettet ist. Da verlass ich mich mal drauf, dass 100 Leute, die da dran rumpfriemeln, schon einen Grund dafür haben. Usergestütztes einloggen bleibt da mal außen vor. Aber dafür kann man ohnehin die .htaccess nicht sinnvoll gebrauchen, zumindest nicht, wenn man viele Anwender auf der Seite hat oder sich gar seine Werte aus 'ner Datenbank holt.

Greetz
cw

Hallo 'Flügel des Huhns'

Wenn ich CMS sage dann meine ich natürlich nicht Joomla und nicht irgend ein anderes kommerzielles CMS. Es gibt genügend hervorragende Sachen die hundert mal besser sind als das was mein's jemals wird(?)...

Es fing an, dass ich Contents in einzelne include-Dateien ausgelagert habe und per KeyWords und und SuchAlgorithmus wieder zusammengesetzt habe. Ich bin froh, dass mittlerweile alle Includes relativ komfortabel ausgelesen und in eine MySQL-Datenbank übertragen werden, und dass ich sie von dort so wie sie sein sollen auch wieder runter und in meinen 'Rahmen' eingefügt bekomme. Alles geschieht immer am 'lebenden' Objekt. Der nächste Schritt wird sein, einen vernünftigen Editor zu integrieren, damit ich das Gesammtsystem nicht mehr zu verlassen brauche. Kenntnisse eigne ich mir genau so an wie ich sie brauche....

...nenn' es meinetwegen 'Kraut und Rüben'... kommt der Sache schon recht nahe...

CMS heißt für mich auch nicht, dass man die 'Kiste' am Ende auf beliebige Bereiche übertragen können wird, oder gar vermarkten. Ziel ist vielmehr, dass man auch mal einen anderen damit arbeiten lassen kann, oder zwei, oder drei...

Genug geschwafelt!


Danke für Deine Einschätzung
HH.

Ich kenne mich mit Apache, htacess, und der gleichen allerding nicht aus und wüßte nicht einmal welchen Namen das Problem überhaupt hat.

ohne htaccess und ohne Verzeichnisschutz, weil ich annehme, dass PHP selber genügend Schutz aus sich selber heraus bietet.

Ohne diese Probleme zu lösen wird es wohl nichts.
Einfaches Beispiel: Du hast eine Datei in einem Ordner liegen, dann ist sie immer abrufbar, da kann php gar nichts machen (probier es mit einem Bild).

Du kannst natürlich nur php-Dateien ablegen, die dann für sich erstmal überprüfen, ob sie ihren Inhalt ausgeben, z.B. über Session.

Hallo supersalzi

Ja, OK. ...
... was heißt abrufbar?

Wenn ich eine x.php aufrufe, dann wird sie auf dem WebServer gestartet und kommt bei mir nur noch als normaler html-Code an. Und wenn ein übergebener Parameter mit einer Variaben oder einem Array verglichen wird, dann passiert das auf dem Webserver, und nicht beim User. ... und der Vergleich mit einer Bilddatei hinkt. Seh' ich das evtl. falsch?

'Sessions' sind bisher noch kein Begriff für mich...?! Was ist das?

Viel Gruß
HH.

nein, der Vergleich hinkt nicht. Du schreibst genau was ich sagte. Eine PHP-Datei kann aufgerufen werden und dann entscheiden was sie ausgibt (ob nun html oder nicht lass ich mal im Raum stehen). Aber solange du Dateien im Verzeichnis liegen hast, sind diese abrufbar. Beim Bild wird ganz klar, dass ich als user das Bild sehen kann, bei einer xml Datei ebenso. Lediglich in PHP Datein kannst du nach dem Aufruf noch was beeinflussen.
Wie machst du denn Log-In ohne Sessions und ohne .htaccess?

Habe mich ebenfalls oft in solchen Problemen verrannt (inzwischen läuft mein kleines cms ganz gut).

Denkanstoß:
Nimm eine index.php-Datei. Diese kann einen front-Bereich (öffentliche Website) und einen backend-Bereich (Admin) includieren. Passwort machst du mit PHP-Sessions. Die reinen backend-Daten kannst du ein einem mittels .htaccess geschützten Ordner legen, includieren lassen sie sich mit php trotzdem.
Welche Seiten nach welchem login angezeigt werden kannst du mit PHP machen, z.B. wenn du das inlcude an eine log-in Bedingung knüpfst.

Moin, Moin,

Da HTML ein verbindungsloses Protokoll ist, musst Du ja trotzdem Deine Daten irgendwie auf die nächste "Seite" hieven. Dabei unterstützt Dich die sog. Session. Zu Sessions lässt sich 'ne Menge sagen, aber ich will's mal kurz machen: Du solltest nach Möglichkeit Sessions nur per Cookie zulassen, anderenfalls besteht die Gefahr, dass Dir u.U. einer Deine Session "klaut". Um das etwas sicherer zu machen, kann man z.B. die Session auch gegen die IP prüfen. Aber der Aufwand wird dann halt immer größer.
Du könntest eigentlich nur dann ohne Sessions arbeiten, wenn Du die relevanten Daten wie Variablen usw. als Parameter in die URI packst und dann mit $_GET auf einer (Folge-)Seite wieder ausliest => viel zu aufwändig, zumal die Anzahl der Zeichen auch begrenzt ist (schlag mich tot, aber ich komm jetzt nicht auf die Größe - 256, 512, 1024?)
Die Session selber startest Du mit

PHP-Code:

session_start(); 


Danach könnte es wie folgt weitergehen:

PHP-Code:

$_SESSION['LoggedIn']=isset($_SESSION['LoggedIn']) ? $_SESSION['LoggedIn'] : false;
if(isset($_POST['senden'])) { // "Formular-Button name="senden" gedrückt?
   // Der Name für die Formfelder sei u_user und u_passwd
   if($_POST['u_user']=="xxx" && $_POST['u_passwd']=="xyz") {
     $_SESSION['LoggedIn']=true;
   }
}
if($_SESSION['LoggedIn']===false) {
   include("admin/login.php");
} 


Auf den folgenden Seiten arbeitest Du dann nur noch mit dem bool'schen Wert von $_SESSION['LoggedIn']

PHP-Code:

if($_SESSION['LoggedIn']===true) {
   include("admin/index.php");
} else {
   // Tu irgendwas anderes
} 


Bei einem Logout haust Du entweder die ganze Variable raus (dann solltest Du aber auch auf isset() prüfen, da Dein errorlog sonst rapide anwächst wg. "undefined index"):

PHP-Code:

unset($_SESSION['LoggedIn']); 


oder

PHP-Code:

$_SESSION['LoggedIn']=false; 


Wenn Du verhindern möchtest, dass irgendjemand Deine Dateien aus dem admin-Ordner direkt über die URL aufruft (.htaccess):

Code :

1 2 3 4

# Options +FollowSymLinks RewriteEngine On RewriteBase / RewriteRule admin /index.php [R=301,L]

Hier wird einfach auf die Startseite zurückgelenkt (so sie denn index.php heißt und natürlich das Wichtigste: Dein Server rewrite unterstützt)

Falls ich mich oder etwas an irgend 'ner Stelle wiederholt habe: sorry!

Greetz
cw

Zitat von chickenwing

Da HTML ein verbindungsloses Protokoll ist, [...]

HTML ist kein Protokoll, es ist eine (Auszeichnungs-)Sprache für Webinhalte! Ausserdem wäre es nicht verbindungslos, da es über TCP läuft.

Der Punkt ist eher, dass HTTP (das Protokoll hinter HTML) selbst keine Sitzungen anbietet und du hier auf ein Sitzungsmanagement (z.B. von PHP) zurückgreifen musst.
Weitere Informationen hier oder hier.

Zitat von chickenwing

[...]Du solltest nach Möglichkeit Sessions nur per Cookie zulassen, anderenfalls besteht die Gefahr, dass Dir u.U. einer Deine Session "klaut". [...]

Falsch, Cookies schützen keineswegs gegen Diebstahl. Vor kurzem hat das zum Beispiel das Tool Firesheep anschaulich und einfach demonstriert. Ob du die Session-ID nun per Cookie oder per URL übergibst ist vom Sicherheits-Standpunkt aus unerheblich, erstes sieht aber besser aus und ist leichter zu handhaben.

Zitat von chickenwing

[...]als Parameter in die URI packst und dann mit $_GET auf einer (Folge-)Seite wieder ausliest => viel zu aufwändig, zumal die Anzahl der Zeichen auch begrenzt ist (schlag mich tot, aber ich komm jetzt nicht auf die Größe - 256, 512, 1024?)[...]

Die Länge der URL ist vom Standard her nicht begrenzt, hier kommt es auf den verwendeten Webserver und den Browser an. Hierbei sind URLs bis 1000 Zeichen meist problemlos möglich. Ob diese dann "schön" oder angemessen sind muss jeder selbst beurteilen.

@chickenwing: Ansonsten ein guter Crash-Kurs zu Sessions.

Gruß
BK

Moin BK,

zu 1) sorry, das war mein Fauxpas, ich meinte auch http. "Verbindungslos" sollte auch nicht physikalisch im Sinne einer "Verbindung" wie z.B. beim Telefon oder im Netzwerk zu verstehen sein. Ich meinte eher im bildlichen Sinn die eine Seite zur nächsten (dennoch im Sinne der Beschreibung bei Wikipedia):

[...] ]HTTP ist ein zustandsloses Protokoll. Ein zuverlässiges Mitführen von Sitzungsdaten kann erst auf der Anwendungsschicht durch eine Sitzung über eine Session-ID implementiert werden. [...]

http://de.wikipedia.org/wiki/Hyperte...nsfer_Protocol
Aber so differenziert wollte ich das Thema gar nicht anschneiden, sondern nur sehr grob erläutern, wieso und wofür es überhaupt Sessions gibt. "Zustandslos" wäre aber zweifellos die korrektere Wahl.

zu 2) Da möchte ich Dir ein wenig (aber nicht gänzlich) widersprechen (den Text hatte ich nachträglich aus meinem Post entfernt, weil's dann einfach zuviel Text wurde): Ich habe genug Besucher auf meinen Seiten gehabt, die mir Links inklusive der SID geschickt haben. Wenn die Session noch nicht verfallen ist, dann hätte ich ohne Mühe mit ihren Daten weiterarbeiten können. Ich habe mir den Mund fusselig geredet, dass sie die SID aus der URL entfernen, wenn sie Links weiterschicken.

Zitat PHP Benutzerhandbuch, Anhang CXLIX:
Sessions und Sicherheit
[...]
Wenn Sie z.B. Benutzer vor einfachen Social Engineering Tactics (Anm. des Übersetzers: Techniken der Ausnutzung menschlicher Schwächen) schützen wollen, müssen Sie session.use_only_cookies aktivieren.
[...]
Es gibt mehrere Wege, über die eine Session-ID an Dritte gelangen kann. Eine entführte Session-ID ermöglicht diesen, auf alle Daten zuzugreifen, die mit dieser Session-ID verbunden sind. Erstens sind das URLs, die Session-IDs enthalten. Wenn Sie auf eine externe Site verweisen, könnte die URL inklusive Session-ID in den Referrer-Logs der externen Site gespeichert werden. Zweitens kann ein aktiverer Angreifer Ihren Netzwerkverkehr abhören. Falls Ihr Netzwerkverkehr nicht verschlüsselt ist, werden Session-IDs im Klartext über das Netzwerk übertragen.

Womit Cookies nicht nur wegen der Optik zu bevorzugen wären... Wenn ich dahingehend verstanden worden bin, dass man mit Cookies auf "der sicheren Seite" sei, dann hab ich das zu kurz formuliert. Gemäß meinem Motto: "Im Web bist Du nie wirklich auf der sicheren Seite" würde ich solche Aussagen auch gar nicht treffen wollen. Die beste Wegfahrsperre schützt auch nicht vor dem Autoklau. Man kann es den Leuten nur möglichst schwerer machen, damit sie vor allem "die Zeit (und Lust)" verlieren, um sich lieber (so bitter das ist) "einfachere Opfer" zu suchen.

Zu 3) Hast Du natürlich Recht. Im Netz kursieren viele Faustregeln, einige sagen 250 Zeichen (und /oder ab dann sollte man POST einsetzen), andere mit 1000, wieder andere, wenn die URL nicht mehr "menschenlesbar" ist. Aber per Definition ist es nicht begrenzt, eher von den Browsern oder Proxies. Bleibt übrig: Nichts Genaues weiß man nicht

Zu 4) Danke für das Lob. Ich werde mal (hoffentlich) versuchen, in Zukunft meine manchmal "schludrige" Ausdrucksweise etwas zu bändigen.

Greetz
cw