Status 404 senden, außer Anmeldung ist korrekt
2 0 
Der Martin
0 
molily
0 1 molily
0
0 0
0 molily
0
Status 404 senden, außer Anmeldung ist korrekt
Ich möchte ein script (php) verwenden aber der Aufruf soll 404 zurückliefern (genau als wäre nichts da), außer es erfolgte eine korrekte Anmeldung.
Nun könnte ich mit meinen Fähigkeiten lokal ein html-Dokument mit entsprechendem Formular benutzen und mit php auf dem Server prüfen, ob die Anmeldung korrekt war und dann das eigentliche Formular ausliefern oder wenn nicht (ohne Anmeldung oder bei falscher Anmeldung) den 404 senden.
Aber gibt es auch eine einfachrere Methode? Kann man HTTP-Authentifizierung in der Art benutzen, wenn ja wie? Oder fragt der Server zwangsweise nach dem Passwort, wenn er eins erwartet? Oder gibt er zwangsweise den Status 401(?) aus, wenn das Passwort falsch ist? (Bedingungsgefüge: gemietet, shared hosting)
Eine etwas andere Baustelle: Kann es eigentlich irgendwelche Probleme geben, wenn man Inhalte mit einer 404-Fehlerseite ausliefert? Irgendwas in der Art, daß der Browser dann gewisse Dinge anders macht wodurch die Funktionalität eingeschränkt ist, z.B. bei einem Formular? (Mir ist schon klar, daß das browserspezifisch sein kann.)
Wenn es einem recht ist, wenn zumindest ein menschlicher Besucher einen relevanten Inhalt erkennt aber maschinell (durch einen Bot) der Status 404 verarbeitet werden soll, muß man dann mit Einschränkungen bei der menschlichen Nutzung rechnen?
-
Hi,
Ich möchte ein script (php) verwenden aber der Aufruf soll 404 zurückliefern (genau als wäre nichts da), außer es erfolgte eine korrekte Anmeldung.
Security by Obscurity also – wozu? Dass das Unfug ist, sollte doch klar sein.
Wenn der Nutzer nicht berechtigt ist, auf eine Ressource zuzugreifen – dann antworte mit einem *passenden* Statuscode – entweder 403 Forbidden, oder 401 Unauthorized (letzteres nur wenn auch tatsächlich sowas wie HTTP Auth verwendet wird).
Eine etwas andere Baustelle: Kann es eigentlich irgendwelche Probleme geben, wenn man Inhalte mit einer 404-Fehlerseite ausliefert? Irgendwas in der Art, daß der Browser dann gewisse Dinge anders macht wodurch die Funktionalität eingeschränkt ist, z.B. bei einem Formular? (Mir ist schon klar, daß das browserspezifisch sein kann.)
Alte IE hatten die Default-Einstellung, 404-Fehlerdokumente des Servers zu unterschlagen, und stattdessen ihre eigene Meldung anzuzeigen.
Und irgendeinen generellen Zusammenhang zwischen der Größe des Fehlerdokumentes gab’s in älteren IE auch noch – IIRC haben sie es sogar ignoriert, wenn der Nutzer das explizit abgestellt hatte, und das Fehlerdokument kleiner als 512 Byte war.Wenn es einem recht ist, wenn zumindest ein menschlicher Besucher einen relevanten Inhalt erkennt aber maschinell (durch einen Bot) der Status 404 verarbeitet werden soll, muß man dann mit Einschränkungen bei der menschlichen Nutzung rechnen?
Wenn du irgendeinen *relevanten* Inhalt verbreiten willst – dann *lüge* nicht bezüglich seines Status, das ist einfach Unsinn.
MfG ChrisB
--
Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/-
Hallo,
Alte IE hatten die Default-Einstellung, 404-Fehlerdokumente des Servers zu unterschlagen, und stattdessen ihre eigene Meldung anzuzeigen.
Und irgendeinen generellen Zusammenhang zwischen der Größe des Fehlerdokumentes gab’s in älteren IE auch noch – IIRC haben sie es sogar ignoriert, wenn der Nutzer das explizit abgestellt hatte, und das Fehlerdokument kleiner als 512 Byte war.IIRC war es genau umgekehrt: Ab einer Länge des Error-Dokuments von 512 Byte hat der IE dem Server "geglaubt" und dessen Dokument angezeigt, darunter nur, wenn der Nutzer es mit der Einstellung "Kurze HTTP-Fehlermeldungen anzeigen" explizit gefordert hat. Das betraf auch nicht nur den Status 404, sondern auch andere Fehlerbedingungen, etwa 403 oder 500.
Ist das denn bei aktuellen IE-Versionen inzwischen anders?
Wenn du irgendeinen *relevanten* Inhalt verbreiten willst – dann *lüge* nicht bezüglich seines Status, das ist einfach Unsinn.
Genau. Es spricht aber nichts dagegen, den Status 404 zu senden, dem menschlichen Nutzer aber trotzdem irgendeine Hilfe anzubieten, etwa eine Liste von Links zu möglichen Alternativen, ein Suchformular, oder auch die Startseite der Website (das hatten wir hier neulich als Diskussionsthema).
Ciao,
Martin--
Männer sind ungerecht: Sie sehen immer nur den Baum, den eine Frau mit dem Auto gerammt hat. Aber die vielen Bäume, die sie nicht einmal gestreift hat, sehen sie nicht.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
IIRC war es genau umgekehrt:
Habe ich auch so in Erinnerung, ich habe das Fehlerdokument extra etwas aufgeblasen als es noch zu klein war. Sollte ich tatsächlich mal jemand anderem die Nutzung meines Vorhabens antragen, werde ich ggf. darauf hinweisen, sich bei Problemen mit älteren Browsern an mich zu wenden.
-
-
Security by Obscurity also – wozu? Dass das Unfug ist, sollte doch klar sein.
Wenn der Nutzer nicht berechtigt ist, auf eine Ressource zuzugreifen – dann antworte mit einem *passenden* Statuscode – entweder 403 Forbidden, oder 401 UnauthorizedSo klar ist das gar nicht. Du gehst davon aus, dass alle URLs auf allen Hosts für alle bekannt und sichtbar sein sollen. Das ist nicht der Fall. Viele Inhalte sind privat, haben aber URLs, weil wir uns im Web befinden. Wenn der Server nicht 404 zurückgibt, ist es sehr einfach, durch Crawler alle privaten URLs herauszubekommen. Die URLs können bereits Aufschluss über Inhalte geben. Wenn sie das nicht täten, wären es schlechte URLs.
Mathias
-
Hi,
So klar ist das gar nicht. Du gehst davon aus, dass alle URLs auf allen Hosts für alle bekannt und sichtbar sein sollen.
Du gehst doch nicht davon aus, dass sie „unsichtbar“ blieben, nur weil du sie nicht aktiv publik machst?
Denn:
Das ist nicht der Fall.
Viele Inhalte sind privat, haben aber URLs, weil wir uns im Web befinden.
Und sie haben entsprechenden Zugriffsschutz implementiert, wenn die Informationen, die unter ihnen ausgeliefert werden, nicht öffentlich sein sollen.
Wenn der Server nicht 404 zurückgibt, ist es sehr einfach, durch Crawler alle privaten URLs herauszubekommen.
Dagegen gibt’s ja bspw. HTTP Auth.
Die URLs können bereits Aufschluss über Inhalte geben. Wenn sie das nicht täten, wären es schlechte URLs.
Und eben damit wären wir doch wieder exakt bei Security through Obscurity – die Sicherheit deiner Information (diesmal nur der im URL enthaltenen) basiert darauf, dass sie niemand „kennt“.
Wie leicht der URL an sich “leaken” kann, brauche ich dir nicht erzäehlen.
Ergo gehört diese Information für mich *nicht* in den URL, wenn sie derart sensibel ist.
MfG ChrisB
--
Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/-
Wenn der Server nicht 404 zurückgibt, ist es sehr einfach, durch Crawler alle privaten URLs herauszubekommen.
Dagegen gibt’s ja bspw. HTTP Auth.
Das verstehe ich nicht. »Nicht 404« trifft auch auf 403 zu.
Und eben damit wären wir doch wieder exakt bei Security through Obscurity – die Sicherheit deiner Information (diesmal nur der im URL enthaltenen) basiert darauf, dass sie niemand „kennt“.
Hier würde ich eher von Privacy sprechen als Security. Wenn einzelne URLs leaken, dann ist das eben so. Das kann schnell passieren, alleine schon durch Referrer. Ein Browser ist keine sichere, abgeschlossene Umgebung. Das ist immer noch ein weiter Unterscheid dazu, dass alle URLs und darin enthaltenen Informationen systematisch lesbar sind und vom Angreifer für Social Engineering oder zur Planung gezielter Angriffe benutzt werden können.
Ergo gehört diese Information für mich *nicht* in den URL, wenn sie derart sensibel ist.
Es redet auch niemand davon, dass die Information in der URL unglaublich geheim ist. Aber hinreichend sensibel, dass sie nicht crawlbar und maschinell auswertbar sein sollte.
Ein geschlossenes Forum beispielsweise wird früher oder später leaken, wenn »SEO-freundliche« URLs den Threadtitel oder gar Postinginhalt preisgeben. Trotzdem ist es nicht möglich, die einzelnen Threads maschinell zu erraten, weil die meisten geschlossenen Foren bei jeder nicht autorisierten Anfrage dieselbe Login-Seite zeigen. Natürlich ist es sinnvoll, solche URL-Generierung kurzerhand abzuschalten, wenn nicht unbedingt benötigt.
Private Repositories auf GitHub funktionieren ähnlich. Durch URL-Leaks kann an die Öffentlichkeit kommen, dass ein Unternehmen an einem $geheimenProjekt arbeitet oder einen Fork von $bekannteSoftware einsetzt. Aber es lässt sich nicht automatisiert erraten, weil GitHub 404s anstatt einer Login-Seite liefert. Dass GitHub konsequent mit sprechenden URLs anstatt mit Zufallsstrings arbeitet, ist ein Usability-Feature und wurde wichtiger als die Privatsphäre erachtet.
Mathias
-
Es redet auch niemand davon, dass die Information in der URL unglaublich geheim ist. Aber hinreichend sensibel, dass sie nicht crawlbar und maschinell auswertbar sein sollte.
Jeder kann jede url in die Welt schreien. Ob nun jemand einen Link setzt oder Informationen aus dem Browser leaken ist relativ egal. Auswertbar ist die Fehlerseite zwar, wenn aber 404 zurückgegeben wird, nimmt keine mir bekannte Suchmaschine die url in den Index auf (schon weil die meisten 404er echte 404er sind).
ohne 404 sieht das z.B. bei google gern so aus:
falls vorhanden, manchmal der Titel (wo doch erst gar kein Zugriff erfolgen soll)
url
"Aufgrund der robots.txt dieser Website ist keine Beschreibung für dieses Ergebnis verfügbar. Weitere Informationen"
-
-
-
Die URLs können bereits Aufschluss über Inhalte geben. Wenn sie das nicht täten, wären es schlechte URLs.
In dem Fall ist es wohl umgekehrt, insbesondere, wenn es nur eine url ist.
-
-
Ich möchte ein script (php) verwenden aber der Aufruf soll 404 zurückliefern (genau als wäre nichts da), außer es erfolgte eine korrekte Anmeldung.
Security by Obscurity also – wozu? Dass das Unfug ist, sollte doch klar sein.
Die Security kommt von der Anmeldung. Obscurity betrifft nur daß nicht zu sehen sein soll, daß überhaupt was da ist.
Wenn du irgendeinen *relevanten* Inhalt verbreiten willst
Relevanter Inhalt kann ein Anmeldeformular sein, welches nur für mich oder noch ganz wenige andere Leute gedacht ist. Wenn also was nicht funktionieren würde, würde ich das schon merken, ich wollte mich nur im Vorfeld informieren.
dann *lüge* nicht bezüglich seines Status, das ist einfach Unsinn.
Mir geht es um einen die Regel bestätigenden Ausnahmefall. Und robots.txt und noindex wird auch benutzt, auch wenn es vor nichts sicher schützt. Vor manchem auch nicht bei guten Bots.
-
hi,
Wenn der Nutzer nicht berechtigt ist, auf eine Ressource zuzugreifen – dann antworte mit einem *passenden* Statuscode – entweder 403 Forbidden, oder 401 Unauthorized (letzteres nur wenn auch tatsächlich sowas wie HTTP Auth verwendet wird).
Bitte nicht verwechseln: Authentifizierung, Autorisierung
Einen Header für nicht autorisierte Benutzer gibt es nicht. Es gibt jedoch einen Header für nicht authentifizierte Benutzer.
Es ist möglich, den Request auf eine autorisierte Ressource an eine dem Request vorhergehende Autentifizierung zu koppeln und für Letzteres einen dementsprechenden Header zu senden (Auth Basic). Es ist jedoch nicht zwingend vorgeschrieben, Auth Basic zu benutzen.
D.h., wenn es eine Ressource gibt, die nur einem dafür autorisierten Benutzerkreis zugänglich sein soll, musst Du das nicht mit einem Auth Basic Header kundtun.
Horst
-
Hi,
D.h., wenn es eine Ressource gibt, die nur einem dafür autorisierten Benutzerkreis zugänglich sein soll, musst Du das nicht mit einem Auth Basic Header kundtun.
Hab ich auch nicht behauptet.
MfG ChrisB
--
Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/
-
-
-
Hi!
Nun könnte ich mit meinen Fähigkeiten lokal ein html-Dokument mit entsprechendem Formular benutzen und mit php auf dem Server prüfen, ob die Anmeldung korrekt war und dann das eigentliche Formular ausliefern oder wenn nicht (ohne Anmeldung oder bei falscher Anmeldung) den 404 senden.
Ja, das ist so üblich, wenn man Ressourcen, die nur für gewisse Nutzergruppen zugänglich und verlinkbar sein sollen, für den Rest der Welt verstecken will.
Aber gibt es auch eine einfachrere Methode?
Ich denke nicht. Die Schritte, die du oben beschreibst, müssen so oder ähnlich abgearbeitet werden. Ob das nun PHP ist oder eine andere Sprache, ob das auf dieser oder einer höheren Software-Ebene erfolgt.
Kann man HTTP-Authentifizierung in der Art benutzen, wenn ja wie?
Kann man schon. Dann ist aber bekannt, dass die Ressource existiert und geschützt ist. *Das* willst du ja anscheinend vermeiden.
Oder fragt der Server zwangsweise nach dem Passwort, wenn er eins erwartet?
Ja, sofort.
Bei HTTP Basic Auth wird der erste GET-Request mit einem 401 Authorization Required beantwortet, zusammen mit entsprechenden Headern. Das löst den Passwort-Dialog im Browser aus. Der Browser schickt dann einen weiteren GET-Request *mit* den Credentials. Den beantwortet der Server dann mit einem 200 OK.
Bei Folge-Requests auf dieselbe URL und Unterpfade schickt der Browser automatisch die Credentials mit, sodass keine weiteren 401 erzeugt werden. Das gilt aber nur für die Browsersession.
Außer mit dem initialen 401 bringt man den Browser auch nicht dazu, einfach mal Credentials mitzuschicken.
Kann es eigentlich irgendwelche Probleme geben, wenn man Inhalte mit einer 404-Fehlerseite ausliefert? Irgendwas in der Art, daß der Browser dann gewisse Dinge anders macht wodurch die Funktionalität eingeschränkt ist, z.B. bei einem Formular? (Mir ist schon klar, daß das browserspezifisch sein kann.)
Ja, das kann sein. Manche Browser zeigen gar nicht die Antwort des Servers an, sondern eine eigene Seite. Manche zeigen die HTML-Antwort des Servers nur an, wenn sie gewisse Kriterien erfüllt (z.B. Response-Größe). Ja, das ist browserspezifisch.
Falls sie die HTML-Antwort des Servers anzeigen, so wird das Dokument in aller Regel genauso verarbeitet wie HTML-Dokumente, die mit 200 ausgeliefert werden. Alles funktioniert darin wie gehabt.
Wenn es einem recht ist, wenn zumindest ein menschlicher Besucher einen relevanten Inhalt erkennt aber maschinell (durch einen Bot) der Status 404 verarbeitet werden soll, muß man dann mit Einschränkungen bei der menschlichen Nutzung rechnen?
Diese Frage verstehe ich leider nicht. Kannst du sie umformulieren?
Grüße
Mathias-
Ok, dann werde ich es so machen wie es mir vorschwebte, danke.
Diese Frage verstehe ich leider nicht. Kannst du sie umformulieren?
Das war ergänzend noch mal die gleiche Frage, nur mehr aus Sicht der Nutzung/Motivation und etwas ergebnisoffener.
-
-
Ich möchte ein script (php) verwenden aber der Aufruf soll 404 zurückliefern (genau als wäre nichts da), außer es erfolgte eine korrekte Anmeldung.
Mal zurückgefragt: Autorisierte Benutzer sollen andere Inhalte sehen, ggf. auch auf einunddemselben URL andere Inhalte (je nach Benutzergruppe), ist das Dein Anliegen bzw. Ziel?
-
Ich möchte ein script (php) verwenden aber der Aufruf soll 404 zurückliefern (genau als wäre nichts da), außer es erfolgte eine korrekte Anmeldung.
Mal zurückgefragt: Autorisierte Benutzer sollen andere Inhalte sehen, ggf. auch auf einunddemselben URL andere Inhalte
Ja, oder jein, abhängig von der Formulareingabe (nach der Anmeldung) wird das Verarbeitungsergebnis variieren.
(je nach Benutzergruppe), ist das Dein Anliegen bzw. Ziel?
Das könnte sich in Zukunft auch ergeben, ja. (zeitlich und "grupplich" sehr beschränkter Umfang)
-
(zeitlich und "grupplich" sehr beschränkter Umfang)
Ich will damit nur sagen, es muß nicht super benutzerfreundlich o.ä. sein. Nicht das jemand denkt, ich hätte so eine Einstellung dazu.
-
Das könnte sich in Zukunft auch ergeben, ja. (zeitlich und "grupplich" sehr beschränkter Umfang)
Na, dann mach das doch, d.h., ein 404 für /foo.html z.B. wäre völlig ok, wenn einer diesen URL aufruft und nicht in der entsprechenden Gruppe (foo) angemeldet ist.
Liegt hingegen eine Anmeldung in der Gruppe foo vor, erzeugt ein Request auf /foo.html den Status 200 und die Seite wird in voller Pracht gezeigt.
Auf meiner Seite kannst Du /showstats.html auch nur dann sehen, wenn Du angemeldet bist. Wenn nicht, kommt Status 404, was denn sonst.
Horst
--
Logisch: der Letzte, der das Opfer lebend sah, ist der Täter!-
Das könnte sich in Zukunft auch ergeben, ja. (zeitlich und "grupplich" sehr beschränkter Umfang)
Na, dann mach das doch, d.h., ein 404 für /foo.html z.B. wäre völlig ok, wenn einer diesen URL aufruft und nicht in der entsprechenden Gruppe (foo) angemeldet ist.
Schon klar, nur wird bei mir die Anmeldung ebenfalls auf /foo.html erfolgen oder die Anmeldeseite ebenfalls ein 404 zurückgeben.
(Ich sehe nicht, was ich deinem Beitrag entnehmen soll*. Es ist nicht so, daß ich Schwierigkeiten hätte, Inhalte in Abhängigkeit von der Anmeldung ggf. auf urls in Abhängigkeit von der Anmeldung auszuliefern.)
*Oder doch, Du meinst vielleicht, weil andere Leute kein lokales Formular zum anmelden haben würden bzw. ich es ihnen zukommen lassen müßte. Ja, das wäre uner den Umständen alles andere als elegant.
-
zu früh abgeschickt
*Oder doch, Du meinst vielleicht, weil andere Leute kein lokales Formular zum anmelden haben würden bzw. ich es ihnen zukommen lassen müßte. Ja, das wäre uner den Umständen alles andere als elegant.
Dafür wäre die Fehlerseite mit Formular der Kompromiß.
-
hi,
Schon klar, nur wird bei mir die Anmeldung ebenfalls auf /foo.html erfolgen oder die Anmeldeseite ebenfalls ein 404 zurückgeben.
Du vermischst Autentifizierung und Autorisierung. Trenne das besser und noch besser ists für den Programmierer, wenn solche Sachen aus dem Code ganz raus sind.
Horst
-
... noch besser ists für den Programmierer, wenn solche Sachen aus dem Code ganz raus sind.
Du meinst bei HTTP-Authentifizierung? Wie ich das dort mit Gruppen machen müßte, müßte ich ohnehin erst nachschauen. Wie ich mit php da rankommen würde, um verschiedene Inhalte auszuliefern auch. Das würde ich dann wahrscheinlich anders machen (also gleich ohne php und mit verschiedenen urls).
Ich mache es nun aber komplett mit php und da muß es irgendwie in den Code. Oder was meinst du?
-
Mahlzeit,
Ich mache es nun aber komplett mit php und da muß es irgendwie in den Code. Oder was meinst du?
http://www.php.net/manual/de/features.http-auth.php
So schwer ist das nun auch nicht zu finden ;)
--
42-
Ich mache es nun aber komplett mit php und da muß es irgendwie in den Code. Oder was meinst du?
http://www.php.net/manual/de/features.http-auth.php
So schwer ist das nun auch nicht zu finden
Gefunden hätte ich es, nur was soll ich damit? Eine Fehlerseite, die eine Authentifizierung fordert will ich nicht. Und keine Authentifizierung zu fordern, wenn keine Authentifizierung erfolgreich war und eine Authentifizierung zu fordern, wenn eine Authentifizierung erfolgreich war, ist sinnlos.
;)
Ist es nun nicht schwer zu finden und ist der Symbol MC9090 ein Handheld mit Barcodescanner oder nicht?
-
Mahlzeit,
Gefunden hätte ich es, nur was soll ich damit?
Du prüfst http_auth und lieferst im Fehlerfall nen 404. Ich hab dich so verstanden, dass es das ist, was du willst. Wenn ich da falsch lag, ignorier meinen Beitrag ;)
Ist es nun nicht schwer zu finden und ist der Symbol MC9090 ein Handheld mit Barcodescanner oder nicht?
Für mich ist es ein Handheld mit Barcodescanner. Was wäre er denn sonst? Auch nennt es der Hersteller (Motorola) so.
--
42-
Du prüfst http_auth und lieferst im Fehlerfall nen 404. Ich hab dich so verstanden, dass es das ist, was du willst. Wenn ich da falsch lag, ignorier meinen Beitrag ;)
Das würde ich wollen. Nur, wie soll ich den Passwort-Dialog im Browser auslösen um http_auth füttern zu können? Wenn ich molly richtig verstehe, muß dazu 401 gesendet werden.
Ich müßte mich mit anderen Mitteln (HTML-Formular) an den Server wenden um mich anzumelden um dann die HTTP-Anmeldung auszulösen. Da kann ich es gleich bei der ersten Anmelung belassen.
Ist es nun nicht schwer zu finden und ist der Symbol MC9090 ein Handheld mit Barcodescanner oder nicht?
Für mich ist es ein Handheld mit Barcodescanner.
Für mich auch. Du hast gesehen, was ich zitiert habe? Ein ";)" Symbolisiert doch eigentlich, daß das davorstehende nicht so gemeint ist.
-
-
-
-
... noch besser ists für den Programmierer, wenn solche Sachen aus dem Code ganz raus sind.
Du meinst bei HTTP-Authentifizierung?
Nein, eben nicht. Betrachte einen Loginprozess (Autentifizierung) als eine von Autorisierung unabhängige Sache (das ist NICHT Authorization Basic per HTTP).
Ich mache es nun aber komplett mit php und da muß es irgendwie in den Code. Oder was meinst du?
Ja, das Login wäre zu programmieren. Du baust eine Session auf und in der Logintabelle (die kannst Du in
$_SESSIONhalten) steht nach einer erfolgreichen Anmeldung der Name der Benutzergruppe drin.Auch noch zu Programmieren: Jeder Request schaut in die Logintabelle nach der Gruppe. Je nach Gruppe wird eine der Autorisierung entsprechende Routingtable geladen, so ist der Rest dann aus dem Code raus, d.h., das letzte Stück Code, was Inhalte oder Anwendungen ausliefert, muss sich um die Autorisierung nicht mehr kümmern.
Horst
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
So in der Art hatte ich das vor. So in der Art habe ich für Erweiterungen für mein phpBB auch das genutzt, was mir phpBB zur Verfügung stellt, if (eingeloggt(user)) {abdafür}.
Nur eine Gruppenverwaltung werde ich zum ersten mal selber anlegen müssen. Aber das wird schon.
-
-
-
-
-
-
-