[PHP & MySQL] Verbinden met DB op andere locatie

[Verwijderd]

Beste allemaal,

Ik ben bezig een CMS te maken voor een klant wat ik vervolgens later van plan ben om voor meerdere klanten te gaan gebruiken.
Dit CMS wil ik het liefst alleen op mijn eigen domein hebben staan en dat klanten dan kunnen inloggen met hun domeinnaam, gebruikersnaam en wachtwoord op MIJN domein.
Op mijn domein moeten ze dan hun data/content kunnen bewerken die op het domein van de klant moet komen te staan.

Zoiets dus:

mijnDomein => klantDomein
CMS (bewerken van content) => database met content (die dus in het cms te bewerken moet zijn)

Kan iemand mij uitleggen hoe ik dit voor mekaar kan gaan krijgen? Op internet heb ik niet veel gevonden, kan misschien ook zijn omdat ik niet precies weet waarop ik moet zoeken.
Het enige dat ik weet, is dat het mogelijk is.. daar blijft het dan ook bij.

Alvast bedankt....

[Caddy]

het kan soms het geval zijn dat de MYSQL server alleen via localhost te bereiken is.
Dit kan je gewoon aanpassen in de config als het goed is. Verder moet het denk ik geen probleem zijn.
Je loopt wel 2x zoveel risico dat de website niet werkt als 1 van de servers down is.

suc6!

[S_tef]

Je tekst en uitleg snap ik niet, je topic titel echter wel .
Als je simpelweg wilt verbinden met een externe database moet je simpelweg bij het connecten geen localhost invoeren.

De hostingprovider van de klant moet echter wel instellen / ingesteld hebben dat de poort van buitenaf te bereiken is.

Overings zal het geheel wel langzamer worden, aangezien alle data over internet verstuurd zal moeten worden.

[Tux]

Behalve dat het risico op downtime groter is op deze manier zullen de websites ook niet heel erg snel zijn (tenzij de verschillende servers aan dezelfde switch hangen). De queries moeten over het internet en het resultaat ook, dus tweemaal latency van de verbinding.

Waarom wil je dit eigenlijk op je eigen server?

[nika]

Zoals hierboven al wordt gesteld kan je MySQL of MSSQL gewoon benaderen vanaf een extern IP adres (dus vanaf het domein van je klant).

Dit kan standaard niet. En dat is voornamelijk uit het oogpunt van beveiliging. Je kan dat wijzigen als je controle hebt over de betreffende databaseserver, maar dat kan problemen met zich meebrengen:

- hacks (je database is benaderbaar vanaf een extern IP adres, dus als IP adres wordt gespoofd, kunnen anderen aanvallen proberen)
- als je klant geen statisch IP adres heeft, kan hij/zij voor de situatie komen te staan dat de website geen toegang meer heeft
- het is potentieel traag
- het is potentieel onveilig als de data niet encrypted tussen databaseserver en webserver heen en weer wordt gestuurd

Ik zou heroverwegen.

[CodeCaster]

Je wil er waarschijnlijk voor zorgen dat je klanten blijven betalen voor z'n website, en niet aan de haal gaan met je code.

Dit is op meerdere manieren te doen, en de content van een andere server halen is hiervoor niet zo'n geschikte optie. Waarom niet? Twee zaken: onbereikbaarheid bij het niet beschikbaar zijn van jouw server, en snelheid die de bezoeker ervaart. Wat denk je wat er gebeurt als er voor iedere request verbinding gemaakt moet worden met een remote databaseserver?

Het lijkt mij verstandiger om bijvoorbeeld bij het inloggen in je admin-panel even contact te leggen met jouw CRM, waarbij je controleert of de klant nog recht heeft op de door jou geleverde diensten.

[S_tef]

CodeCaster schreef op woensdag 13 mei 2009 @ 22:04:
Het lijkt mij verstandiger om bijvoorbeeld bij het inloggen in je admin-panel even contact te leggen met jouw CRM, waarbij je controleert of de klant nog recht heeft op de door jou geleverde diensten.

Dit kunnen klanten er natuurlijk ook uitslopen, tenzij je alles encrypt maar dan moet er weer software op de servers geïnstalleerd zijn.

[CodeCaster]

S_tef schreef op woensdag 13 mei 2009 @ 22:20:
[...]

Dit kunnen klanten er natuurlijk ook uitslopen, tenzij je alles encrypt maar dan moet er weer software op de servers geïnstalleerd zijn.

Dat hou je toch. Als een klant zo snugger is dat 'ie een "phone home"-actie eruit kan slopen, kan 'ie ook wel de content-tabel lokaal namaken en het CMS daarheen laten verbinden.

[Cartman!]

Of koop (ja, duur) Zend Guard en stel een licence in op een bepaalde tijdperiode. Als dat de reden is van de workaround die de TS beschrijft dan

edit:
sowieso leg je in contract vast dat de klant geen eigenaar is van de code en als ie iets verandert dan is ie de zak (boeteclausule bijv).

[ Voor 33% gewijzigd door Cartman! op 13-05-2009 22:25 ]

[Verwijderd]

Het belangrijkste is dat een klant straks niet zelf op de ftp kan en dan de code van het CMS kan verwijderen en/of jatten. En ze moeten natuurlijk wel de wachtwoorden van hun eigen server in beheer hebben.

Dit leek mij opzich een goede oplossing maar er zijn blijkbaar genoeg argumenten om het niet te doen.

Hebben jullie een ander idee? De /cms map moet dus niet bereikbaar/zichtbaar zijn voor de klant, komt het ongeveer op neer..

[S_tef]

Dan moet je alles in eigen beheer nemen.

[Gomez12]

Tja eigen server neerplanten dan, ftp-toegang tot enkele mappen regelen en je cms buiten de ftp-mappen houden

[Verwijderd]

Ik ben zelf op dit moment in een vergevorderd stadium van een dergelijk CMS.
Wanneer een klant verbinding maakt met het CMS met z'n gebruikersnaam en wachtwoord wordt in mijn CMSDB de database gegevens van de klant opgevraagd.
Op die manier kan ik dan een connectie maken met de database van de klant, die overigens wel verplicht extern te benaderen moet zijn.

Belangrijk is dat in het CMS wordt geschreven op de database van de klant, de website draait op de server van de klant en maakt verbinding met zijn database gewoon via localhost. Enkel het inschieten en wijzigen van content gebeurd elders.

[ Voor 25% gewijzigd door Verwijderd op 14-05-2009 12:50 ]

[Cartman!]

Wat is de reden van die constructie?

[Verwijderd]

Cartman! schreef op donderdag 14 mei 2009 @ 13:17:
Wat is de reden van die constructie?

Bij mij is voornamelijk de reden: onderhoud. Ik probeer het CMS zoveel mogelijk continu te verbeteren. Hier en daar wat gebruiksvriendelijkheid en optimalisatie.
Wanneer het een apart CMS is voor vele sites, dan hoef ik enkel 1 keer de code te schrijven. En is uitrollen heel gemakkelijk.

[Hydra]

Verwijderd schreef op woensdag 13 mei 2009 @ 22:29:
Het belangrijkste is dat een klant straks niet zelf op de ftp kan en dan de code van het CMS kan verwijderen en/of jatten. En ze moeten natuurlijk wel de wachtwoorden van hun eigen server in beheer hebben.

Waarom is het voor jou zo'n risico dat klanten je werk 'jatten'? Ze zijn dan namelijk gewoon illegaal bezig. Als je ziet dat je CMS draait bij een klant van wie de licentie verlopen is, dan kun je die gewoon juridisch aanpakken?

Verwijderd schreef op donderdag 14 mei 2009 @ 14:15:
Bij mij is voornamelijk de reden: onderhoud. Ik probeer het CMS zoveel mogelijk continu te verbeteren. Hier en daar wat gebruiksvriendelijkheid en optimalisatie.
Wanneer het een apart CMS is voor vele sites, dan hoef ik enkel 1 keer de code te schrijven. En is uitrollen heel gemakkelijk.

Maar je zegt net dat het CMS bij de klant draait (je hebt het over de website)? Wat versta jij onder 'de website'?

[ Voor 32% gewijzigd door Hydra op 14-05-2009 14:17 ]

[CodeCaster]

Verwijderd schreef op donderdag 14 mei 2009 @ 12:47:
Ik ben zelf op dit moment in een vergevorderd stadium van een dergelijk CMS.
Wanneer een klant verbinding maakt met het CMS met z'n gebruikersnaam en wachtwoord wordt in mijn CMSDB de database gegevens van de klant opgevraagd.
Op die manier kan ik dan een connectie maken met de database van de klant, die overigens wel verplicht extern te benaderen moet zijn.

Belangrijk is dat in het CMS wordt geschreven op de database van de klant, de website draait op de server van de klant en maakt verbinding met zijn database gewoon via localhost. Enkel het inschieten en wijzigen van content gebeurd elders.

Waarom gebruik je daar geen (zelfgeschreven) interface voor? Of sta je enkel localhost plus jouw IP-adres toe? Anders heb je een beveiligingslek van hier tot Tokio, omdat er wanneer er wachtwoorden lekken iedereen toegang heeft tot de databaseserver.

[Mike2k]

Mocht je dan toch willen verbinden aan een database op een remote server voor je cms, raad ik je aan om daar in ieder geval een vpn tunnel heen te leggen. Je gegevens zijn dan tenminste wel beveiligd...
Ook hoef je daarmee je mysql poort niet open te zetten naar het internet maar alleen naar het lan.

[Verwijderd]

Verwijderd schreef op woensdag 13 mei 2009 @ 22:29:
Het belangrijkste is dat een klant straks niet zelf op de ftp kan en dan de code van het CMS kan verwijderen en/of jatten. En ze moeten natuurlijk wel de wachtwoorden van hun eigen server in beheer hebben.

Dit leek mij opzich een goede oplossing maar er zijn blijkbaar genoeg argumenten om het niet te doen.

Hebben jullie een ander idee? De /cms map moet dus niet bereikbaar/zichtbaar zijn voor de klant, komt het ongeveer op neer..

Je kan ook gewoon copyrights op je producten zetten en klanten in contract laten tekenen dat ze eraf blijven.

[Cartman!]

Dat zei ik al ja, zulk soort zaken neem je op in je contract. En als je para bent dat iemand je code steelt dan neem je een encoder zoals Zend Guard. Remotecontructies staan me altijd enorm tegen vanwege latencies. Plus dat als jouw server (om welke reden dan ook) er even uit knalt dan liggen de sites van je klanten er ook allemaal uit.

Het updaten van een CMS is leuk, maar betalen ze daar ook voor Als alles werkt en doet wat het zou moeten doen, waarom zou je hun code dan continu updaten?

[Hydra]

Cartman! schreef op donderdag 14 mei 2009 @ 14:44:
Het updaten van een CMS is leuk, maar betalen ze daar ook voor Als alles werkt en doet wat het zou moeten doen, waarom zou je hun code dan continu updaten?

Inderdaad. Onze klanten betalen maintenance geld voor nieuwe versies e.d. Die krijgen ze echt niet gratis.

[Verwijderd]

Het is inderdaad 'n prima idee om dat contractueel vast te leggen, maar momenteel heb ik nog geen KvK (van de zomer pas) en heeft zo'n contract dan wel nut? lijkt mij niet toch?

En dan nog, hoe kom je er achter of je CMS ergens anders draait dan jij weet.. dus dat het gestolen is?

[Voutloos]

Verwijderd schreef op donderdag 14 mei 2009 @ 19:00:
Het is inderdaad 'n prima idee om dat contractueel vast te leggen, maar momenteel heb ik nog geen KvK (van de zomer pas) en heeft zo'n contract dan wel nut? lijkt mij niet toch?

Kvk is niet relevant. Je hebt hopelijk toch wel 'iets' met klant vastgelegd?

[Gomez12]

Verwijderd schreef op donderdag 14 mei 2009 @ 19:00:
Het is inderdaad 'n prima idee om dat contractueel vast te leggen, maar momenteel heb ik nog geen KvK (van de zomer pas) en heeft zo'n contract dan wel nut? lijkt mij niet toch?

Een kvk heeft niets met een contract te maken, zonder kvk is je contract nog 100% rechtsgeldig...
KvK straalt enkel wat vertrouwen uit en geeft wat extra verplichtingen en voordelen, het heeft niets met contractstatussen te maken...

En dan nog, hoe kom je er achter of je CMS ergens anders draait dan jij weet.. dus dat het gestolen is?

Simpel gezegd, niet. ( je kan wat google alerts etc instellen zodat google voor je speurt maar als iemand het op een intranet draait dan heb je gewoon pech )
Maar hoe detecteer je het nu dan als een klant je cms gekopieerd heeft en de code aangepast heeft?

[Cartman!]

Waarom zou je pas vanaf de zomer een KVK inschrijving doen? Je betaalt nu een paar tientjes of dan, later in t jaar is niet goedkoper bij KVK Maar zoals gezegd maakt dat voor je contract niet uit. Gewoon simpele afspraken van wie de code is en hoe de betaling geschied en welk bedrag. Handig is ook om vast te leggen welke functionliteiten de site heeft.

[Verwijderd]

Je hebt een vrij betrouwbare website omdat het er goed uitziet. Het feit dat ik je nergens in het handelsregister van de KvK kan terug vinden zou mij als klant meteen doen afhaken. Het kost inderdaad een paar tientjes maar per jaar maar het straalt een stuk meer vertrouwen uit.

Maar ontopic: contracten staan los van KvK

[Cartman!]

Overigens toch een toevoeging: met alleen KVK ben je er niet, je moet ook een BTW-nummer aanvragen bij de Belastingdienst