Vorgehensweise bei der (Um)Programmierung unserer Seite (PHP/SQL)

Werner S

Werner S

Member
Grüß euch,

wir betreiben seit 2015 ein Erotikportal mit Shop inkl. Loginbereich etc. und verwalten ca. 9000 aktive Kunden, Tendenz in letzter Zeit extrem Steigend.
Es wurde in PHP5 geschrieben und seit 2016 nicht mehr aktualisiert oder irgendwas am Code verändert, zum Glück geht das nicht auf meine Kappe, ich hatte bis Mai 2020 nichts mit dem Projekt zu tun bzw. bin erst Mai2020 der Firma beigetretten.

Unser System bietet sowohl für User als auch für Admins ein Login. Beide, sowohl der User als auch der Admin nutzen die gleichen Klassen, Templates etc. Nichts wurde getrennt. Im Adminbereich werden Bestellungen freigegeben und Verwaltet, neue Produkte eingetragen oder auch Kunden bestimmte Funktionen freigegeben.

Derzeit wird es von mir komplett überholt, nicht nur der Code sondern der ganze Aufbau.

Bei mir ist diesbezüglich noch eine Frage offen wo ich gerne von euch die Erfahrung einholen will.

Angedacht sind was den Login angeht mehrere Lösungen.

Lösung 1: User und Adminbereich komplett getrennt, 2 Systeme. Einzig die Datenbank teilen sich beide
Lösung 2: User und Adminbereich getrennt. Zugriff vom Adminbereich aus auf die Usertabellen via SOAP
Lösung 3: User und Adminbereich weiter zusammen laufen lassen und nur den Code aktualisieren

Ich hoffe auf konstruktive Vorschläge wie Ihr sowas handhabt oder es Lösen würdet.

LG und einen schönen Abend
 
... das kommt wohl sehr auf den aktuellen Code an bzw. wie viel gemeinsame Features Admin und User-Bereich haben.

wenn man es richtig macht ist jede Variante ok. Wenn man es falsch macht hat jede Variante Desaster-Potential.

Ein Charme, den Admin-Bereich komplett herauszutrennen, wäre ggf. daß man den dann auch zugriffstechnisch komplett isolieren könnte (eigener Server, nicht aus dem Internet direkt erreichbar sondern nur via z.B. VPN, ...) - ob das bei euch aber möglich ist wisst auch nur ihr.
 
Lösung 3: Wozu das Frontend auftrennen, wenn das gemeinsame Backend das (Sicherheits-)Problem darstellt.


Optimal wäre Lösung 1 mit völlig getrennten Backends, siehe Antwort von marce
 
marce said:
... das kommt wohl sehr auf den aktuellen Code an bzw. wie viel gemeinsame Features Admin und User-Bereich haben.
Click to expand...

Für die User Loginfunktion für den Shop und andere Dienste.
Der admin geht einfach in den Subfolder example.de/admin, logt sich ein und kann neue Produkte einstellen, Bestellungen verwalten oder auch dem User bestimmte Bereiche frei schalten.
Sowohl der User als auch der Admin nutzen die gleichen Config Files, Klasse etc..
Quasi mit den gleichen Funtionen 2 seperate Loginbereiche mit unterschiedlichen Inhalten, der Adminbereich kann aber aufgrund der Funktionen in der aktuellen Funktion nicht getrennt werden.

marce said:
Ein Charme, den Admin-Bereich komplett herauszutrennen, wäre ggf. daß man den dann auch zugriffstechnisch komplett isolieren könnte (eigener Server, nicht aus dem Internet direkt erreichbar sondern nur via z.B. VPN, ...) - ob das bei euch aber möglich ist wisst auch nur ihr.
Click to expand...
Genau das habe ich mit der ersten Lösung vor. Die Seite für Kunden komplett neu aufbauen.
Den Adminbereich ebenfalls, dies mal aber getrennt auf einem anderen Server und via Remotezugriff vom Adminbereich auf die Usertabelle zugreifen. Natürlich via VPN.
Erfordert zwar was mehr Arbeit, finde aber was die Sicherheit angeht das es die beste Lösung ist.
 
Bei den meisten Systemen dieser Art, die ich kenne, ist der Admin nichts anderes, als ein Benutzer mit erweiterten Rechten.

Meiner Meinung nach macht es nicht viel Sinn getrennten Code für Admin und normale Benutzer zu entwickeln. Ich sehe da auch nicht wirklich einen Sicherheitsgewinn. Im Gegenteil, da bei getrennten Systemen mehr Programmieraufwand ist, schleicht sich auch eher ein Fehler ein.
Ein flexibles Benutzer-/Rechtesystem und einen robusten sicheren Code müsste hier eigentlich reichen.

Ich vote für Lösung 3 :)
 
Eine Trennung von Kundenfrontend und (Admin-)Backend macht durchaus Sinn, wenn man letzteres auf einem separaten System laufen lässt und diese in einem abgeschotteten Bereich steht wie beispielsweise einer Firmenfirewall. Dann liegen auf dem Frontend-Server nämlich nur die Daten, die für den direkten Betrieb des Shops notwendig sind und alles weitere wie beispielsweise Kreditkarten-Daten werden dann nur auf dem Backend-System abgelegt, um sie besser zu schützen. Und eine Trennung ist hier ja möglich. Dann sollte es was in der Art von Lösung 2 sein.
Bei vielen kleinen Shops muss hingegen alles auf dem gleichen Server laufen, weil es z.B. kein umfangreiches Firmennetz gibt oder das ganze als kleiner Nebenerwerb läuft. In dem Fall bringt eine Code-Trennung keinen Sinn, dann wäre Variante 3 die richtige.
Die Variante 1 bringt in meinen Augen keinen SIcherheitsgewinn, braucht aber deutlich mehr Arbeit.
 
Reden wir über systemtechnische oder codetechnische Trennung von Backend und Frontend?
Bei Code bin ich ein grosser Fan von "shared Code" (develop once, use often) auf Ebene der Businesslogik.
Einzig die Zugriffslogik (Frontend bei serverseitiger Template-Generierung, Middleware bei bei zB Angular) sollte man tunlichst trennen und nicht auf "if(isAdmin())" zurückgreifen.

Systemtechnisch wiederum macht es absolut Sinn beide Frontends zu trennen - schon allein aus dem Grund dass man dann die Admin-Systeme entweder nur (VPN)-intern oder aber über striktere Zugriffsregeln zugänglich macht. Zusätzlich muss das Kundenfrontend ja skalierbar sein, das Adminfrontend hingegen generell nicht.

Um konkreter antworten zu können müsste man den internen Businesslogik- und Sicherheitsaufbau des Systems kennen.

PS: " Tendenz in letzter Zeit extrem Steigend.". Hehe, die Leute sind wohl noch noch viel zuhause :p
 
Grüß euch,

d4f said:
Reden wir über systemtechnische oder codetechnische Trennung von Backend und Frontend?
Bei Code bin ich ein grosser Fan von "shared Code" (develop once, use often) auf Ebene der Businesslogik.
Einzig die Zugriffslogik (Frontend bei serverseitiger Template-Generierung, Middleware bei bei zB Angular) sollte man tunlichst trennen und nicht auf "if(isAdmin())" zurückgreifen.
Click to expand...

Wir reden über systemtechnische oder codetechnische Trennung des Shops, Userlogin und Adminlogin.
Aktuell geschieht alles über eine einzige Domain auf einem einzigen Server.
Der Admin hat schon seinen eigenen Bereich unter /admin, alles andere wie Funktionen oder Klassen läuft mit shared Code!

d4f said:
Um konkreter antworten zu können müsste man den internen Businesslogik- und Sicherheitsaufbau des Systems kennen.
Click to expand...

Nunja, es gibt keine Businesslogik- und Sicherheitsaufbau. Ich bin Mai 2020 in die Firma gewechselt, alle Mitarbeiter haben die Bestellungen etc. so abgewickelt, ohne irgendwas von VPN oder Firewal einzusetzen, nur die Fritz.Box zwischen PC's und Leitung.
Juni 2020 gab es einen wechsel der Geschäftsführung und jetzt wird alles auf einen guten Stand gebracht.
Hardwarefirewall und VPN wird gerade Installiert. Zugriff auf den Server gibt es nur noch von der Firma aus so wie andere Sicherheitsrelevante Dingen die gerade umgesetzt werden.

Der Shop mit Frontend und Backend wird definitiv komplett neu geschrieben und aufgebaut. Wir müssen uns nur für eine Lösung Entscheiden wobei es und das nicht um die Mehrarbeit bei getrennten System geht sondern in erster Linie um die Sicherheit.

d4f said:
PS: " Tendenz in letzter Zeit extrem Steigend.". Hehe, die Leute sind wohl noch noch viel zuhause :p
Click to expand...

Allerdings. Anfang des Jahres waren es gerade knapp 200 Kunden. Mitte Mai als ich in die Firma kam waren es schon knapp 5000 Kunden.
 
Der Shop mit Frontend und Backend wird definitiv komplett neu geschrieben und aufgebaut. Wir müssen uns nur für eine Lösung Entscheiden
Click to expand...
Wenn es "from scratch" sein darf/soll (durchaus selten dass die Geschäftsführung es erlaubt!) sollte man davon vollends Gebrauch machen und die Technologiewahl je nach Expertise und Bedarf neu definieren und auswählen.

Grundsätzlich ist aber auch immer eine Kostenfrage verbunden und um Entwicklungskosten/Betriebskosten zu senken will man möglichst viel bestehende Technologien verwenden. Entweder bestehende Shop-Systeme (opensource oder kommerziell) oder zumindest shop-taugliche Frameworks. Potentiell relevant für euch kann ja die PCI-DSS Zertifizierung zur Abwicklung von Kreditkarten-Bezahlungen werden, somit sollen auch solche Voraussetzungen mit einfliessen.

Zu Bevorzugen wäre insgesamt eine opensource Lösung mit kommerziellemen Support und signifikanter Userbases.
- Opensource damit man es selbst anpassen und analysieren kann
- kommerzieller Support wenn es knallt
- Userbasis damit der Shophersteller nicht verschwunden ist bevor ihr mit dem System im Netz seit.

Von dieser Entscheidung abhängig ist dann wie die Struktur aussieht. Es gitb Systeme welche "api-first" auf Microservice-Basis laufen, andere die extrem monolithisch aufgebaut sind.
 
d4f said:
Wenn es "from scratch" sein darf/soll (durchaus selten dass die Geschäftsführung es erlaubt!) sollte man davon vollends Gebrauch machen und die Technologiewahl je nach Expertise und Bedarf neu definieren und auswählen.
Click to expand...

Genau so sieht es aus. Der Shop soll komplett neu Geschrieben werden. Der neue Chef brachte gleich 2 festangestellte Programmierer und einen Sysadmin mit (Fusion von 2 Firmen). Um die Kosten machen wir uns da also weniger sorgen da wir nicht nur den XXX Shop betreiben, sondern mehrere Standbeine haben.
Die 2 können sich nur nicht Entscheiden welche der 3 Lösungen Sie nutzen wollen und der Chef will sich da nicht Einmischen bzw. einen von beiden nicht übergehen. Chef hat mich als "Aussenstehender" beauftragt, es wird also das genommen wofür ich mich Entscheide.

Wir verkaufen nicht nur XXX Produkte auf der Seite, sondern Streamen auch gleichzeitig + kleine Singlebörse. Stream und Börse laufen gerade auch gut an. Fertige Shops, auch Kostenpflichtige haben wir schon getestet, sie bieten aber nicht das was wir oben für Features brauchen, auch nicht durch Plugins.

Was bis jetzt nur Sicher steht, das ganze System wird auf Laravel aufgebaut, das war die einzige Vorgabe.
Derzeit tendiere ich selber zu User und Adminbereich komplett getrennt, 2 Systeme, entweder über die gleiche Datenbank (Remote) oder aber SOAP.

Montag würde ich das gerne abliefern, kann mich aber selber noch nicht wirklich Entscheiden.
 
You must log in or register to reply here.
Back
Top