Make /admin forbidden for one particular user (user_id ==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: [Select]

if ($_SESSION['USER_ID'] == 2) {  header('Location: https://www.homepage.nl'); exit; }
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: [Select]

if ($_SESSION[‚USER_ID‘] == 2) {  header(‚Location: https://www.homepage.nl‘); exit; }
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]

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 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...

[sternchen8875]

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...

Is this a decision the customer made based on WB's circumstances, or one they would like to have regardless of the CMS used? As far as I know, this solution (one password for everyone) doesn't exist in any modern CMS.

I followed your suggestion; it's an idea we've been discussing here for a long time: a new permission, with the example name "backend_user." This leaves the user with the backend login and the option to only change their profile data.
https://i.gyazo.com/7ecb68d722b9ebb23d645fbe8d2df867.png

The same options are then available in the frontend.
https://i.gyazo.com/a71882219c8121dd18fc1a6f9ab405bf.png

But that means: every user has their own password.
It's currently just a "rough fix," not a professional solution, and it's only a first step. If you go through with this, you'll have to secure every admin subpage, rewrite the frontend login, etc.

So it's not something that can be completed in 10 minutes.

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

Ist das eine Entscheidung, die der Kunde auf Grund der Gegebenheiten von WB getroffen hat oder ein, die er, unabhängig vom verwendetem CMS gern hätte?. Meines Wissens gibt es diese Lösung (ein Passwort für alle) in keinem modernen CMS.

Ich bin mal deinem Vorschlag gefolgt, ist ja eine Idee, die wir hier schon lange diskutierten, einem neuen Recht, als Bespielname "backend_user". Damit bleiben dem User der Backend-Login und dort die Möglichkeit, lediglich die Profildaten zu ändern
https://i.gyazo.com/7ecb68d722b9ebb23d645fbe8d2df867.png

im Frontend dann die gleichen Optionen
https://i.gyazo.com/a71882219c8121dd18fc1a6f9ab405bf.png

Heißt aber: jeder User hat sein Passwort
Ist aktuell nur "rein gewurstelt", keine Profi-Lösung und es ist nur ein erster Schritt. Zieht man das durch, muß man so jede Admin-Unterseite absichern, den Frontend-Login neu schreiben usw

Also nichts, was in 10 min fertig ist

[CodeALot]

Is this a decision the customer made based on WB's circumstances, or one they would like to have regardless of the CMS used? As far as I know, this solution (one password for everyone) doesn't exist in any modern CMS.

Ehm... Yes, it's very easy: create one user called "visitor" and give it a password. Tell everyone about the name and password. Done.

But I know, that's just a very simple 'barrier' to prevent a site to be 100% public. And that's all they needed in this case.

I followed your suggestion; it's an idea we've been discussing here for a long time: a new permission, with the example name "backend_user." This leaves the user with the backend login and the option to only change their profile data.
https://i.gyazo.com/7ecb68d722b9ebb23d645fbe8d2df867.png

That is the same as creating a user without any permissions - but they still can access /admin and change their profile. My "wish" is to have all that in the frontend. No access to the backend. Like you change your data in your Amazon account. For example

[sternchen8875]

Das ist das, was uns trennt, mein Freund:
du suchst eine Lösung: ein Password für alle, kein Admin-Bereich
Ich suche eine Lösung für WB - Frontend-User können sich anmelden, registrieren und erhalten kein Backend-Zugang, aber sehr wohl Zugang zum eigenem Profil (im Frontend)

Ich sagte ja, Obiges ist nur ein erster Schritt - der nächste war, das Backend zu sperren durch das neue Recht. Die Loginmaske bleibt, ohne Recht erfolgt eine direkte Ummeldung ins Frontend. Was nun bleibt, ist die Möglichkeit, über das Frontend (mein 1. Bild oben) die Profildaten zu ändern.
Bedeutet aber, jeder User kann SEIN Passwort, sein Profil ändern.
Wenn das nicht gefällt, bin ich raus

engl. Translation
This is what separates us, my friend:
You're looking for a solution: one password for everyone, no admin area.
I'm looking for a solution for WB - front-end users can log in, register, and don't get back-end access, but they do get access to their own profile (in frontend).

I told you, the above is just a first step - the next step was to block the back-end using the new permission. The login mask remains; without authorization, you are redirected to the frontend. What remains now is the ability to change profile data via the front-end (my first image above).
But that means every user can change THEIR password, their profile.
If I don't like that, I'm out.

Admin Comment: add the red marked info - is important on this place

[CodeALot]

We are not so much 'separated' in our wishes

My "wish" is to have all that in the frontend. No access to the backend. Like you change your data in your Amazon account. For example

That would give the option to leave the frontend part out completely (in case you need one password for all) or embed it if you want all individual logins. What remains is the original wish: no access to backend.

[crnogorac081]

Long time ago i tried to create new users class for this, new user and group table, $_SESSION["FE_User_Id"] insted User_id , but I stoped developing that Long time ago