Admin Backend auf separater Domain

[StandardTR]

Hallo,
ich weiß nicht ob ich hier in der richtigen Section bin. Habe eine bisschen komische Frage: Ja ich habe eine ganz normale Webseite in Laravel erstellt. So jetzt möchte ich ein Admin Panel coden, auf der man User und so weiter verwalten kann. Jetzt wollte ich fragen ob es irgendwelche Vorteile in Sachen Sicherheit oder so gibt wenn ich das Admin Panel als separate Webanwendung erstelle und diese dann z.B nur über die Domain "admin.domain.com" erreichbar ist. Bis jetzt habe ich meine Admin Panels immer direkt in meine normale Website integriert und der Zugang wurde dann durch ein Rollen System geschützt . Das würde mich einfach interessieren, wie dass größere Anwendungen machen und wie gesagt ob es irgendwelche Vorteile gibt.

[protestix]

Wo ist deine Frage zu PHP?
PHP-Fortgeschrittene - Wer darf hier posten?

[StandardTR]

Sry wie gesagt habe keine Ahnung wo das hingehört. Wäre nett wenn das ein Moderator verschieben könnte.

[tomBuilder]

Jetzt wollte ich fragen ob es irgendwelche Vorteile in Sachen Sicherheit oder so gibt wenn ich das Admin Panel als separate Webanwendung erstelle und diese dann z.B nur über die Domain "admin.domain.com" erreichbar ist.

Üblicherweise nutzt man für die Graduierung der Rechte Nutzer Rollen:
https://de.wikipedia.org/wiki/Berechtigungskonzept

Deswegen sehe ich bei einer "normalen" Anwendung wenig Sinn eine neue Anwendung zum Administrieren zu schreiben.
Wenn Du willst kann Du das aber in der selben App über eine Subdomain routen.

[JaMa]

Ich kenne nur den sicherheitsrelevanten Vorteil der Verhinderung von XSS Attacken zwischen den zwei Bereichen (da unterschiedliche Origins). Aber da du in beiden Anwendungen vermutlich auf eine ähnliche Codebase zugreifen musst, dürfte es vernünftiger sein, alles in einer Anwendung abzuwickeln.

Just my 2 cents.

[Arne Drews]

[MOD: verschoben]

[Gast]

Die Frage ist eigentlich nicht, ob zwei Domains, sondern, ob zwei Applikationen. Aber das hängt ganz von den Umständen ab.

[Zeichen32]

Ich denke es macht je nach Anwendungsfall Sinn Backend und Frontend in zwei Applikationen aufzuteilen oder nicht. Ich mache dies häufig, das liegt aber 1. daran, dass das Frontend bei mir meistens Angular ist und PHP nur die API bereit stellt und 2. das Backend oft auf internen Servern liegt und das Frontend auf öffentlichen erreichbaren. Diese brauchen nicht auch den ganzen Code vom Backend dabei haben, wenn sie nur das Frontend bedienen.

[tomBuilder]

Ich habe schon mehrere definitionen in dem Kontext gehört, was mit Backend und frontend gemeint sein könnte:
Ich kopier mal nur.

In webbasierten Anwendungssystemen mit getrennten Nutzeroberflächen für reguläre Benutzer und Systemverwaltung bezeichnet der Begriff Front-End die der Öffentlichkeit zugänglichen Internetseiten, während der Begriff Back-End für den nur dem eingeschränkten Benutzerkreis zugänglichen Bereich verwendet wird.

Bei Content-Management-Systemen (CMS) wird die Administrationsoberfläche zum Erstellen und Pflegen von Inhalten (Content) häufig auch als Back-End bezeichnet, während die vom CMS generierte Webseite als Front-End angesehen wird.

Front-End bezeichnet, eng an obige Bedeutung angelehnt, auch grundsätzlich die Benutzeroberfläche, die z. B. in Form einer grafischen Benutzeroberfläche (englisch graphical user interface, kurz GUI) oder mittels Bildschirmmasken implementiert sein kann.

Bei Client-Server-Anwendungen wird das auf dem Client laufende Programm als Front-End (also hier: Dienstnutzer), das auf dem Server laufende als Back-End (hier: Dienstleister) bezeichnet.
Traditionell kommt ein Fat Client und ein Fat-Server zum Einsatz. Auf dem Server läuft eine Datenbankanwendung. Die Clients übernehmen dabei die Logik und die Darstellung der Benutzerschnittstelle.

Ob es jetzt zwei odr drei möglichkeiten sind welche ich hier sinnlos aufspalte sei mal egal,
jedenfalls scheint mir die unterteilung front/backend mehrdeutig.
kannst Du das etwas präzesieren ?

[JaMa]

Die Frage ist eigentlich nicht, ob zwei Domains, sondern, ob zwei Applikationen. Aber das hängt ganz von den Umständen ab.

Eingangs ist von der Überlegung hinsichtlich zweier Webanwendungen die Rede, also war das wohl auch seine Frage. Wenn es dann schon zwei verschiedene Anwendungen sein sollen, dann würde ich den Vorteil von verschieden Origins (Domains/Subdomains) mitnehmen.

[VPh]

Ich habe schon mehrere definitionen in dem Kontext gehört, was mit Backend und frontend gemeint sein könnte:

Ich nutze jetzt die erste und zweite Definition


Ein Vorteil den ich bei einer seperaten Applikation für das Backend sehe ist, dass man sich wohl keinerlei Sorgen mehr um das Rollensystem beim "Frontend" machen muss.
Gib dem Pflege-Backend eine eigene Userverwaltung, eventuell an dieser Stelle mit fancy Berechtigungssystem, aber im Frontend gibt es nur normale User. Dann besteht gar nicht erst die Gefahr, dass die normalen User durch einen Bug oder eine Sicherheitslücke mehr Rechte bekommen als sie haben dürfen - einfach weil es in der Applikation gar keine zusätzlichen Rechte gibt.

Dann gibt es die logistischen Vor- und Nachteile. Eigenes Repository für die Backend-Anwendung, eigene Build-Pipeline? Möglichkeit ein anderes Framework oder eine andere Sprache zu verwenden.
Da kann man schon kreativ werden was es so für Vor- und Nachteile gibt.

Ich habe in den letzten Jahren schon öfter mit solchen Konstrukten gearbeitet. In meinem Browsergame habe ich das Admin-Backend direkt in die Website integriert, auf Arbeit hatte ich ein Projekt bei dem das Backend eine eigene Anwendung war - hat dort aber auch noch zusätzliche Funktionalitäten bereitgestellt. Wir haben auf Arbeit aber auch zwei Anwendungen bei denen das Backend mit in der "Kundenanwendung" integriert ist, bei denen ist das aber so umfangreich, dass sich wirklich schon eine eigene Anwendung dafür lohnen würde.

Meine Entscheidungskriterien wären wohl:

• erspart mir das seperate Backend das Rechtesystem im Frontend?
• könnte eine einzelne Backend-Applikation mehrere Frontend-Applikationen verwalten bzw. wäre das eine realistische Anforderung?
• würde es Sinn machen für das Backend und Frontend andere Stacks zu nutzen?
• ist der Code im Backend (zu) umfangreich (um ihn noch ans Frontend ranzuhängen)?

Rein aus den Bauch heraus: Das Backend in eine eigene Anwendung zu packen schadet selten. Bei den Projekten auf der Arbeit war es bzw. wäre es eine gute Entscheidung und auch beim Browsergame würde es einiges angenehmer machen.

[tomBuilder]

Danke für die ausführlichen Erläuterungen VPh. (die verlinkte Anrede klappt nicht -wie jetzt doch ?)
Nicht zum ersten mal konntest Du eine neue Sichtweise jedenfalls teilweise eröffnen .
Deine Checkliste erscheint mir logisch und die ersten beiden Punkte sind durchaus als hinreichende Argumente zu bezeichnen.
Ich habe mich sogar bei statischen Seite um eine Auslagerung aus der gedrückt, was mir nach Deiner Argumentation als eindeutiger Fehler erscheint.

Eine Frage liegt mir da noch auf dem Herzen, wie sieht es mit CSS und JS aus?
Dort sind ja je nach Anforderung große bis sehr große Überschneidungen zu erwarten.

[VPh]

Eine Frage liegt mir da noch auf dem Herzen, wie sieht es mit CSS und JS aus?
Dort sind ja je nach Anforderung große bis sehr große Überschneidungen zu erwarten.

Jep, das ist eine der logistischen Fragen zu denen mir noch nie was gutes eingefallen ist.
Das hängt dann, denke ich, auch stark von der Art des Projektes bzw. der Größe und der Größe des Projektteams ab.

Wenn da wirklich 2 verschiedene Teams dran sitzen, wird man die kaum dazu überreden können zwischendurch immer mal wieder ihre CSS-Dateien abzugleichen. Wenn ich da alleine daran sitze... kopiere ich die einfach hin und her