Löschen des Admin verhindern

Das geht verlässlich nur dann, wenn der andere Account innerhalb von WordPress weder Rechte zum Verwalten der Benutzer noch zum Verwalten von Theme oder Plugins hat (da Benutzer löschen auch einfach via PHP geht), also z.B. eine "Redakteur" bzw. englisch "Editor" Rolle.

Mehr zum Thema z.B. via Suchmaschine wordpress roles capabilities (google).

Natürlich darf der andere Benutzer auch keinen FTP-Zugang und keinen Zugang zu phpMyAdmin im Hosting o.ä. haben, denn darüber kann man das Löschen usw. auch ausserhalb von WordPress machen.

 

Du kannst z.B. der Rolle des Accounts die delete_users Capability entziehen, mehr dazu siehe Link oben, dann kann er aber auch keine sonstigen Accounts löschen.

Zusätzlich müsstest Du auch verhindern, dass der nicht vertrauenswürdige Account einen neuen Admin Account anlegen kann, der dann wiederum Dich löschen könnte.

Zusätzlich müsstest Du verhindern, dass der nicht vertrauenswürdige Account die Benutzerrolle Deines Accounts von Admin auf eine niedrigere Rolle ändern kann, da er Dich sonst auch "aussperren" könnte.

Alternativ kannst Du eine entspr. "Sperre" über eine delete_user Action programmieren, die auf Deinen Account "aufpasst".

Für Mitleser: Jemand (oder ein Kumpel von jemand) mit paar Minuten Google und etwas Programmiererfahrung kann all diese Ansätze aber meist sehr leicht umgehen, daher poste ich auch keinerlei Beispiele dazu.

 

Das funktioniert nicht. @b3317133 hat den möglichen Weg aufgezeigt.

 

Und beim nächsten Update wird die Datei überschrieben. Ausserdem verhindert das nicht die Löschung.

 

Wenn in einem Projekt ein Admin Angst haben muss, von einem anderen Admin gelöscht zu werden, dann wird der obsiegen, der als erster die Löschfunktion betätigt. Mag verstehen, wer will, ich würde mich in so einem Fall selbst löschen, um damit nichts mehr zu tun zu haben.

 

Für Mitleser: Die Lösung dafür, dass ein Kunde keinen "Unsinn" macht, ist ein o.g. "Redakteur" Account für den Kunden, damit kann man einen WordPress Website im Alltagsbetrieb komplett betreiben, evtl. die Rolle ganz leicht angepasst für spezielle Bedürfnisse, und dazu ein extra "Administrator" Account mit Kennwort in einem versiegelten Umschlag, und nach Öffnen des Umschlags endet der Support oder er wird teuer.

 

Man kann user verstecken, z. B. über solch eine Funktion

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

Das nur der Vollständigkeit halber. Einen Redakteur anzulegen ist dennoch die bessere Variante. Denn als Admin kommt man auch an die functions.php und kann das einfach auskommentieren etc.

 

@SirEctor Damit erscheint der versteckte Account zwar nicht mehr in der Liste selbst, wird aber nach wie vor noch oberhalb der Liste mitgezählt, was auffallen könnte, z.B.

Neben dem dann Suchen und Finden der geposteten Funktion kann man den Account auch einfach so löschen, wenn man den "Löschen" Link eines anderen Accounts in der Liste kopiert und die user ID im Link entspr. errät (oft 1 beim ursprünglichen Admin) und austauscht oder einfach einige IDs durchprobiert, es folgt eine Abfrage mit einer Löschbestätigung, wo der jeweils zugehörige Login angezeigt wird. Die _wpnonce im Link ist für alle Accounts der angezeigten Liste gleich, eigentlich ein Bug, wenn man das genau nimmt...

 

Ich weiß das man als Admiin immer Mittel und Wege hat andere zu löschen. Ich glaube aber auch, dass der TE keine 100% Lösung sucht.

 

Der sicherste Weg das Löschen eines Objektes (Post, Benutzer, Taxonomy, Term, usw.) zu verhindern ist die Nutzung des Filters 'map_meta_cap'. Ich nutze das z.B. in Plugins wenn es nicht möglich sein soll vordefinierte Produkteigenschaften, notwendige Seiten oder Rollen zu löschen. Durch hinzufügen von 'do_not_allow' zu den $required_caps wird es unmöglich die betroffene Aktion auszuführen - selbst der Admin kann es nicht.

 

Für Mitleser: Das ist natürlich keine sinnvolle Lösung, ganz im Gegenteil, man unterminiert mit solchen "Backdoors" die Sicherheit des entspr. Websites und bringt nebenbei den Websitebetreiber auch bzgl. DSGVO in Erklärungsnöte, da dieser seinen Besuchern sicher nichts von diesen Zugriffsmöglichkeiten Dritter auf ggf. übermittelte Daten mitgeteilt hat, da er nichts davon weiss. Den Rest hat @Kurt Singer bereits sehr gut erklärt.