WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: dbs on March 29, 2019, 11:13:15 PM
-
Hi, da WB noch nicht unterscheidet zwischen Frontend- und BackendUser, könnte man ja was basteln.
In einem aktuellen Projekt brauche ich keine User im Backend, die dürfen sich nur im Frontend anmelden.
Mein Versuch: in der admin/start/index.php z21 nach $admin = new \admin('Start','start');
if ( $admin->is_authenticated() && $_SESSION['GROUPS_ID'] !=1 ) { header ("Location: " . WB_URL); exit;} // nur Administratorgruppe darf ins Backend
Hängt man nun im Frontend /admin an, kommt wie immer das Loginfenster. Nach dem Login wird nun festgestellt, dass es nicht GROUPS_ID 1 ist und wirft den User auf die Startseite (wo er hin gehört). Angemeldet bleibt er praktischerweise. Nur wenn er die Adresse zu preferences kennt, kommt er ins Backend, alle anderen Seiten zeigen "Ungenügende Zugriffsrechte".
Das ist schonmal mehr als die halbe Miete. Die obige Zeile könnte man auch noch in die preferences/index setzen.
Aber lieber wäre mir ein zentraler Punkt wo man das checken kann.
-
andere Varianten
1. Verzeichnis "admin" umbenennen, z.b. in MyWBAdmin_ZkY234F12, 1x den Ordner, einmal in der config.php
2. das "admin"-Verzeichnis per .htacces + htpasswd schützen, das nur der Super-Admin kennt.
3. sich einen fiktiven Ordnernamen ausdenken, z.b. "MyWBAdmin_ZkY234F12", den nur der SuperAdmin kennt. in der .htaccess eine Weiterleitung einrichten von diesem fiktiven Ordner auf die Datei admin/login/index.php und vielleicht noch eine weitere Umleitung vom fiktiven Link "MyWBAdmin_ZkY234F12/forgot" zur admin/login/forgot/index.php
Alle anderen Zugriffe leitest du auf die index.php im Root. Nur wer diesen Ordnernamen kennt, kommt zum Backend-Login, durch umbenennen der .htaccess auch leicht wieder entfernbar.
-
Ich glaube 1. nehme ich. Einfach und schnell. Danke (Y)
Die Loginmaske hat nur User, Pass und Senden, ganz simple.
-
Gute Idee,...
... aber was machen wir mit den vielen Autoren, die mir meine / unsere Seiten mit Inhalt / Bildern / Terminen pflegen?
Mittelfristig sollten wir die Trennung von FE und BE Usern anstreben, da FE-Editierung aller Jommla wird es ja in absehbarer Zeit nicht geben
Oder wäre das ein Lösungsansatz?
Beispiel:
Unseren ProCalendar pflegen "alle USER" der Gruppe "Mitarbeiter" wenn die nicht mehr ins BE kommen, gibt es keine Termine mehr.
-
Ganz früher gab es mal ein Modul mail2news. Da schreibst du also nur eine Email an eine bestimmte Adresse und das wird dann als News dargestellt. Bestimmte Platzhalter in der Mail damit man weiß was was ist. Sowas könnte man sich auch für Termine vorstellen.
Und die bräuchten dann nicht mal auf die Webseite gehen. :)
Aber Frontendedit ist auch gut.
-
da FE-Editierung aller Jommla wird es ja in absehbarer Zeit nicht geben
Oder wäre das ein Lösungsansatz?
Frontend-Edit: hatte ich schon einmal eine Weile auf meiner Homepage auf Wysiwyg-Seiten so eingebaut, aber irgendwann wieder verworfen, weil es Quatsch ist. Ich hatte ja mehr als nur ein Wysiwyg zu pflegen und dann wird es einfach zu komplex. Und wenn ich mir das anschaue bei Modulen aus dem Land in den Bergen, wo Frontend-Administration eingebaut wurde, gefällt mir das schon von der Sicherheit nicht. Da gibt es nur eine Hürde zu überwinden.
Nach meiner Meinung: Wer eine Seite zu administrieren hat, sollte nicht zu faul sein, sich im Backend anzumelden. Punkt
Aber nur meine Meinung.
mail2news
hatte ich mal auf einer Seite eines Fußballvereins. Technisch soweit akzeptabel, allerdings: wenn am Wochenende die Spiele waren, hat fast jeder Spieler, von Klein bis groß eine solche Mail geschickt. Der eine das Ergebnis seines Spiels, der nächste einen Spielbericht, am Ende waren das 200 Mails pro Wochenende, ein wildes Durcheinander von Schreibstilen, Rechtschreibung, vom Deutsch usw.
Und begrenz ich das wieder auf Paul und Hans, weil diese beiden eingewiesen sind und wissen, was läuft, stellt sich die gleiche Frage: warum loggen die sich nicht ein und nutzen da die Maske und die Werkzeuge.
Grundsätzlich bin ich seit Jahren der Meinung, das die FrontendUser-Geschichte nur eine Frage der Rechte ist. Es ist ja nicht so, das die aktuelle Rechteabfrage nicht funktioniert, im Gegenteil. Es war immer so, das zwei Dev's mit mehr Ahnung immer schon beim Aufkommen des Themas abgewunken haben, vielleicht auch zu Recht, aber bis zum "Beweis des Gegenteils" bleib ich bei meiner Meinung, dafür kenn ich WB zu gut.
Wenn ich mir ein neues Recht "backendUser" setze, ist automatisch jeder angelegte und registrierte User ein Frontend-User, ist ja jetzt auch so. Und wenn ich dieses "backendUser"-Recht beim BackendLogin abfrage und es nicht erteilt ist, bleibt der Kollege eben draußen. Zugang gibt es dann nur auf die jetzt auch mögliche Frontend-Bearbeitungsmöglichkeit im Eigenem Profil. Ist natürlich eine komplexere Sache, wenn man das durch den Core ziehen will, aber muß man das? Wenn Hans garnicht erst rein kommt, brauch ich drinnen auch nicht mehr fragen.
Das Problem dabei sind wohl eher die alten Scripte zum Frontend-Login, die in diversen Templates rumgeistern und z.b. Links zum Bearbeiten einer Seite oder zur Verwaltung von WB haben, aber die Rechteabfrage funktioniert da ja. Und wenn ich über solch alten Links auf eine der Seiten komme, muß da halt die Rechteabfrage auf BackendUser erfolgen.
Vielleicht denk ich mir das auch zu einfach, aber viel mehr als "vergiß es, geht nicht" hab ich da nie als Antwort bekommen.
Der große Haken ist eben, das ich diese Rechte zum Backend-Login auch erstmal setzen muß. Kann in Streß ausarten, wenn man da zig User hat
-
Das funktioniert ja auch ohne Problme, Der USER mit der Berechtigung "Mitarbeiter" kommt im BE nur an die Seite ProCalendar mit einem Link im FE wenn er sich im FE angemedet hat.
Missbrach durch die "gute Gruppenverwaltung" ausgeschlossen.
Träumen darf man ja mal.
-
I see this that can easily be done by adding beUser field in users table and that it is set true or false. Then in class.admin.php to create simple function if_beUser(user_id) ( - true- confinue, false - redirect to WB_URL)
-
Das funktioniert ja auch ohne Problme, Der USER mit der Berechtigung "Mitarbeiter" kommt im BE nur an die Seite ProCalendar mit einem Link im FE wenn er sich im FE angemedet hat.
Missbrach durch die "gute Gruppenverwaltung" ausgeschlossen.
ein "FrontendUser" kommt garnicht erst ins Backend, darum geht es
-
I see this that can easily be done by adding beUser field in users table
Also a good idea. But would be a group based setting a little bit better?
-
It could be both user and group , user to inherit group setting by default, but poasibility to override for some specific user.. anyway i think for this is required minimal code modification..
-
Wenn's geht, bitte auch 'ne eigene Session_id.
Hatte schon mal intern angeregt grundsätzlich unterschiedliche Session_id für FE und BE zu vergeben.
Hintergrund ist die manchmal gewollte Unterdrückung von FE-SessionCookie (kann man im Template über set header anweisen). Dabei entstehen unerwünschte Nebenwirkungen im BE, wenn man ein und denselben Browser für FE und BE nutzt. -wenn man's weiß, benutzt man unterschiedliche...
MfG. Evaki
-
Ich denke, es wird hier der Fehler gemacht, FrontendUser mit FrontendEdit gleich zu setzen
Ich verstehe den Eingangsthread so, das es im Projekt Seiten gibt, die eine Registrierung erfordern, die die Sichtbarkeit "registriert" haben. Nebeneffekt dieser Registrierung ist aber, das jeder registrierte User automatisch in das Backend kommt bzw kommen kann. Mit einer entsprechenden Rechtesetzung kann ich die Permissions aber auf das persönliche Profil beschränken. Das funktioniert im Backend wie auch im Frontend.
Aufgabenstellung (nach meinem Verständnis): wie verhindere ich den Login ins Backend?
am sichersten ist die Lösung .htaccess +.htpasswd. Nur sie verhindert, das man überhaupt zur Login-Maske kommt. Denn ist der User einmal da, darf er sich mit seinen gültigen Logindaten dort auch anmelden. Ich setze nun voraus, das dort wiederum die Rechteverwaltung entsprechend eingestellt wurde, aber das war ja nicht die Frage.
Diese Variante wäre unabhängig von der Core-Entwicklung und gilt auch als sicher. Man könnte hier ein gemeinsames Passwort benutzen, das man den Redakteuren mitteilt oder eine Userliste anlegen. Scheidet dann jemand aus, entfernt man ihn aus der Liste. Vor- und auch Nachteil ist es, das die Redakteure hier kein Passwort selbständig ändern können
Alle anderen Lösungen, auch die von mir mit einem separatem Recht, erfordern einen Eingriff in den Core, der auch recht umfangreich sein müßte
-
am sichersten ist die Lösung .htaccess +.htpasswd.
Das einzige was -nur aus meiner aktuellen Sicht- dagegen spräche, ist die Äbhängigkeit von einem Server(typ), WB war bis dato nicht serverabhängig -z.B. auch nicht in Sachen Sicherheit.
Bin mir aber relativ sicher, daß irgendwem aus der WB-Gemeinschaft noch was einfällt oder eine Idee verdichtet. Immerhin kommen da einige Jahre an Erfahrung zusammen.
Sollte es als unabhängige Lösung vom Core stehenbleiben, spricht natürlich überhaupt nichts dagegen, bzw. spielt das überhaupt keine Rolle. Alternativen für .htaccess +.htpasswd stellen einige Server bereit (auch der von mir genutzte NGINX)
MfG. Evaki