nicht angemeldet
Moin!
Die Vorteile stehen eigentlich schon recht griffig im Betreff. "WhiteLabel" bedeutet, dass ich (in diesem Fall mein Auftraggeber) einen Service anbietet, den ein ihm bekannter zahlender Kunde auf seiner Seite nutzen kann. Die Daten liegen aber auf der Seite des Anbieters d.h. in dessen Datenbank und auf dessen Server.
So muss das Script nicht preisgegeben werden (bitte nicht gleich schlachten - so wünschen es sich eben die Auftraggeber)
Nochmal langsam zum mitmeißeln - folgende Fixpunkte habe ich aus deinen Schilderungen bislang entnommen:
1. Das Skript ist auf "deinem" Server gespeichert (also dem, der von deinem Auftraggeber verwaltet wird).
2. Die Datenbank ist auf dem Server des Kunden gespeichert (Kunde = der, der "deinen" Server nutzen will, um Dinge zu erledigen).
3. Sinn der Übung soll sein, dass der Kunde nicht das Skript ausgehändigt bekommt.
Dann würde ich doch mal ganz spontan sagen: Funktioniert nicht, wenn nicht gewisse Sicherheitsmechanismen komplett außer Acht gelassen werden sollen.
Damit du dein Skript nicht aus der Hand gibst, muß es zwingend von "deinem" Server ausgeführt werden. D.h. du mußt die Rechenleistung zur Verfügung stellen und darfst dann außerdem nur generierte Daten (wie HTML, Bilder etc.) ausliefern. Das Problem ist dann: Wie kommst du an die Datenbank deines Kunden ran? Wenn der Kunde dir da keinen remote zugänglichen Zugang einrichtet (wobei die Frage ist, ob er das überhaupt kann), dann kannst du seine Daten nicht mit deinem Skript auf "deinem" Server verarbeiten. Ich hätte als Kunde jedenfalls aus zwei Gründen ein ungutes Gefühl bei dieser Sache: 1. bedeutet ein offener Datenbankzugang natürlich ein zusätzliches Risiko, und 2. bedeutet das Nutzen einer entfernten Datenbank auch zusätzlichen Traffic und eine eingeschränkte Performance.
Was natürlich funktionieren würde, wäre das Ausführen des Skriptes auf dem Kundenserver. Dann wäre es relativ egal, wo die Datenbank des Kunden untergebracht ist, solange man vom Kundenserver aus drauf zugreifen kann (z.B. ein Datenbankserver im Intranet des Providers, oder eben auch lokal). Das Problem dabei ist aber, dass der Kunde in diesem Fall den PHP-Quellcode kriegt.
Abgesehen davon hat dieses Szenario auch noch ein ungutes Gefühl: Der Kunde muß remote codeinclude erlauben, d.h. über das Internet und wohlmöglich über eine ungesicherte Verbindung ausführbare Skripte auf seine Maschine laden. Sowas ist grundsätzlich böse, weil es zwingend tendentiell unsichere Einstellungen für PHP erfordert. Außerdem sind die Angriffsszenarien auf den Kundenserver sofort vervielfacht. Könnte ja sein, dass "dein" Server übernommen wird, es wird böser Code eingespeist und auf allen fremden Servern ausgeführt, die den Dienst nutzen. Wenn man sowas subtil genug macht, ist das ein schönes Spielzeug.
- Sven Rautenberg