WebsiteBaker Support (2.13.x) > General Help & Support

Make /admin forbidden for one particular user (user_id ==2)

(1/2) > >>

CodeALot:
A new little problem:

I have a website that is not accessible without logging in first. Nothing top-secret, but there's only one group of people that are allowed to see the website.
I made a user ("visitor") that has access. Works fine.

Problem: I do NOT want them to be able to access /admin. There's nothing there for them, they are not allowed to change the profile (since many people use that login). All login-stuff is handled on the front-end.
I tried stuff with

--- Code: ---if ($_SESSION['USER_ID'] == 2) {  header('Location: https://www.homepage.nl'); exit; }
--- End code ---

in several places but it doesn't work...

I do not have a fixed IP for myself, and to make things more complicated: there ARE more users (ID 3, 4, 5) who DO need access to /admin. So the only user that needs to be kicked out of /admin is user_id 2

Any idea where I should look or how I should handle this?

---------------------

Ein neues kleines Problem:

Ich habe eine Website, auf die man nur zugreifen kann, wenn man sich vorher einloggt. Es handelt sich um nichts Geheimhaltungsbedür ftiges, aber es gibt nur eine Gruppe von Personen, die die Website sehen dürfen.
Ich habe einen Benutzer („Besucher”) angelegt, der Zugriff hat. Das funktioniert gut.

Problem: Ich möchte NICHT, dass diese Benutzer auf /admin zugreifen können. Dort gibt es nichts für sie, sie dürfen das Profil nicht ändern (da viele Personen diesen Login verwenden). Alle Login-Angelegenheiten werden im Frontend abgewickelt.
Ich habe an mehreren Stellen Folgendes ausprobiert:

--- Code: ---if ($_SESSION[‚USER_ID‘] == 2) {  header(‚Location: https://www.homepage.nl‘); exit; }
--- End code ---

an mehreren Stellen ausprobiert, aber es funktioniert nicht...

Ich habe keine feste IP-Adresse für mich selbst, und um die Sache noch komplizierter zu machen: Es gibt weitere Benutzer (ID 3, 4, 5), die Zugriff auf /admin benötigen. Der einzige Benutzer, der aus /admin ausgeschlossen werden muss, ist also user_id 2.

Haben Sie eine Idee, wo ich suchen sollte oder wie ich damit umgehen sollte?

crnogorac081:
Can you be more specific ? You want them not to be able to log in to /admin/preferences/index.php ? Put your code there

CodeALot:
No, my goal was to prevent them from having access to /admin alltogether. I solved it now with a redirect in the admin templates based on a user_id. Not the most elegant way but OK.

Which brings me to a new suggestion:
When you create a user, you can specify what that user can do. View pages, edit pages, view media etc etc. This is all based on the assumption that every logged in user has a role in maintaining the website.
Now what if there is a checkbox that says "Allow user access to admin-screens"? Like a "on/off" switch for users that have some sort of admin-role and those who only need a login to access the website?
Giving those users access to the /admin will only confuse most of them since it's a completely different environment. I prefer to handle login and change password stuff within the website (frontend) itself.

------------------------

Nein, mein Ziel war es, ihnen den Zugriff auf /admin insgesamt zu verwehren. Ich habe das Problem nun mit einer Weiterleitung in den Admin-Vorlagen auf Basis einer user_id gelöst. Nicht die eleganteste Lösung, aber OK.

Das bringt mich zu einem neuen Vorschlag:
Wenn Sie einen Benutzer anlegen, können Sie festlegen, was dieser Benutzer tun darf. Seiten anzeigen, Seiten bearbeiten, Medien anzeigen usw. Dies basiert alles auf der Annahme, dass jeder angemeldete Benutzer eine Rolle bei der Pflege der Website hat.
Was wäre nun, wenn es ein Kontrollkästchen mit der Bezeichnung „Benutzerzugriff auf Admin-Bildschirme zulassen” gäbe? Wie ein „Ein/Aus”-Schalter für Benutzer, die eine Art Admin-Rolle haben, und solche, die nur eine Anmeldung benötigen, um auf die Website zuzugreifen?
Diesen Benutzern Zugriff auf /admin zu gewähren, würde die meisten von ihnen nur verwirren, da es sich um eine völlig andere Umgebung handelt. Ich ziehe es vor, die Anmeldung und die Änderung des Passworts innerhalb der Website (Frontend) selbst zu handhaben.

Übersetzt mit DeepL.com (kostenlose Version)

sternchen8875:
The old problem: backend users vs. frontend users
Web administration is one of the most secure areas of any CMS. What it lacks, and has been since the beginning, is the separation of frontend and backend permissions. Many of us who have addressed this issue have been dismissed with the words: "It's not possible without completely redesigning the CMS." I've had my share of experience with this, too.
My idea was not to weaken the system, but rather to add a few more permissions, frontend user permissions.
I don't think much of the solution: one access for everyone in the frontend, one password that everyone shares. That's no protection. It's just a solution born out of necessity. I'm of the opinion that a registered user must always be able to change their own data, their profile; a freely selectable password, an email address—that must be mandatory.

But it's not something you can quickly add with three lines of code, so at the moment we can only offer one solution: use .htaccess/.htpasswd to protect the admin folder. This requires a double login for the admins, but it's the only viable option at the moment.

What we can do in this thread is gather ideas for how things could proceed.

---------------------------

Das alte Problem: Backend-Nutzer vs. Frontend-Nutzer
Der WB-Admin-Bereich ist einer der sichersten Bereiche aller CMS. Was ihr seit jeher fehlt, ist die Trennung von Frontend- und Backend-Berechtigungen. Viele von uns, die sich mit diesem Thema befasst haben, wurden mit den Worten abgetan: „Ohne eine komplette Neugestaltung des Codes geht das nicht.“ Auch ich habe damit meine Erfahrungen gemacht.
Meine Idee war nicht, das System aufzuweichen, sondern ein paar zusätzliche Berechtigungen hinzuzufügen, Frontend-Nutzerberechtigungen.
Ich halte nichts von der Lösung: Ein Zugang für alle im Frontend, ein gemeinsames Passwort. Das ist kein Schutz. Es ist nur eine aus der Not geborene Lösung. Ich bin der Meinung, dass ein registrierter Nutzer jederzeit seine eigenen Daten, sein Profil, ändern können muss; ein frei wählbares Passwort, eine E-Mail-Adresse – das muss Pflicht sein.

Da sich das aber nicht schnell mit drei Zeilen Code hinzufügen lässt, können wir derzeit nur eine Lösung anbieten: Verwende .htaccess/.htpasswd, um den Admin-Ordner zu schützen. Dies erfordert zwar eine doppelte Anmeldung für die Administratoren, ist aber derzeit die einzige praktikable Option.

Wir können in diesem Thread nur Ideen sammeln, wie es weitergehen könnte.

CodeALot:

--- Quote from: sternchen8875 on September 19, 2025, 10:41:09 AM ---I don't think much of the solution: one access for everyone in the frontend, one password that everyone shares. That's no protection. It's just a solution born out of necessity.

--- End quote ---
I agree, although in this case it's a website for elderly people, locked behind at least some sort of security to prevent people from 'outside' to be able to access the website. Getting them to use the website is a task in itself, and the client decided not to make things more complicated by issuing every single user a separate login...

Navigation

[0] Message Index

[#] Next page