[Delphi + Serverside] MySQL connecten op alternatieve manier

[pelleke]

Hallo!

Ik wil een app maken die met een MySQL database communiceert. Deze database draait op een server die aan een internetverbinding hangt. Mijn MySQL-account kan alleen inloggen vanaf 'localhost'. Ik kan dus geen gebruik maken van een directe MySQL verbinding van bijvoorbeeld dbExpress.

Op dit moment heb ik een PHP-pagina geschreven die XML uitpoept. Die XML kan dan worden ingevoerd in een XmlData property van een TClientDataSet. Zo'n zelfde PHP-pagina verzorgt ook de veranderingen van de data in de ClientDataSet, en voert die weer door naar de MySQL.

Nou vind ik echter dat gedoe met die PHP-pagina's een wat onhandige omweg; ik moet voor elke update namelijk een remote HTTP request uitvoeren, en dat kost nogal veel tijd. Ik vroeg me af of het ook anders kan. Het communiceren gaat nu namelijk veruit te traag. Heeft iemand een idee wat ik kan doen om wat vaker data te kunnen sturen zonder steeds al die requests te doen?

Wat voor oplossing ik eventueel in mijn hoofd had:

Een soort proxy server-app die een poort opengooit en alles direct doorpasst naar MySQL, dan kan ik toch een soort directe-MySQL verbinding maken, die via die proxy toch bij 'localhost' vandaan komt. Ik weet alleen niet of ik dat in PHP of Perl wel kan maken. Als iemand kan bevestigen dat dat mogelijk is, dan ga ik er wel een studie van maken.

BTW: Server-side kan ik daar PHP gebruiken, en volgens mij ook Perl, mocht dat nodig zijn.

[Verwijderd]

Als je MySQL alleen maar via localhost kunt benaderen, gaat 't waarschijnlijk om een webserver waar je zelf niks over te zeggen hebt?
PHP en Perl zijn in zo'n geval ook alleen maar te gebruiken via bv. Apache (als module of via cgi), en dan blijf je nog steeds zitten met die HTTP requests. Technisch kan 't zondermeer om een soort 'doorgeefluik' deamon te realiseren in Perl, Python, en zelfs PHP, maar ik geef je weinig kans dat de provider van die webserver dat ook toestaat...

[pelleke]

Die server is bij een kennis van mij, in principe mag ik ermee doen wat ik wil. Ik denk dat het met PHP (module) idd niet gaat werken, maar in perl zou het misschien kunnen, als je de webserver het proces constant aan het lijntje laat houden, of gewoon 3 keer forkt (een voor inkomende en een voor uitgaande data, en een om de andere twee weer af te sluiten als je klaar bent). Ik weet niet of dat wel kan als je perl als module draait, maar misschien is dat een optie.

[BCC]

Wat providers normaal doen is een bepaald (trusterd) IP toestaan om direct een verbinding met de MySQL server te leggen. Dat lijkt mij hier toch ook geen probleem?

[pelleke]

Dat is het ook niet, maar mijn client app moet overal kunnen werken. De authenticatie heb ik zelf op een hoger niveau geprogrammeerd. Een enkel IP is hier dus niet aan de orde.

[Janoz]

De 'hoger niveau security' wordt (of is) zo lek als een mandje. Wanneer je rechtstreeks zou verbinden met de database betekent dit dat je dus ergens in je programma een inlog met wachtwoord hebt staan. Dit alles is niet zo heel moeilijk te achterhalen waneer het complete programma bij de client draait.

Deze inlog gegevens kunnen vervolgens worden gebruikt om vanaf elke plek op internet op die database te komen. Aangezien dat account ook update rechten heeft kan die persoon je hele content verneuken.

Er is niet een heel andere oplossing mogenlijk dan via een proxy achtig iets, en in principe voldoet php hier prima in. Als het te traag gaat dan zou je misschien beter kunnen kijken of je niet teveel communiseerd of of je php efficienter kan.

[pelleke]

Dat is helemaal niet nodig... Je kan gewoon je wachtwoord van je database storen op de server, en vervolgens versleuteld laten downloaden als de authenticatieprocedure (via PHP!) is voltooid. Dat is echt het kleinste probleem. (Bovendien wordt deze manier van doen heel vaak toegepast, het kost je eenmalig 1 HTTP request.)

Ik ben er echter al achter dat dat niks gaat worden, en ga maar afzien van realtime aanpassen van de database. Ik probeer een andere oplossing te maken: elke record krijgt gewoon een timestamp + uid van de laatste wijziging. Als iemand gaat updaten en die info correspondeert niet meer met wat het was toen hij de database downloadde, volgt er gewoon een vraag: 'wat wilt U nu doen?'

edit:

[quote]Kwoot:
Er is niet een heel andere oplossing mogenlijk dan via een proxy achtig iets, en in principe voldoet php hier prima in. Als het te traag gaat dan zou je misschien beter kunnen kijken of je niet teveel communiseerd of of je php efficienter kan.[/quote]
De communicatie op zich is OK, het gaat mij meer om de HTTP-requests die tijd kosten. En ik communiceerde idd te veel, ik wilde namelijk de database updaten bij het invoegen/wijzigen van elk veld, maar het is niet eens nodig... Kijk maar eens hoe dit forum werkt Daar kunnen ook 2 modjes aan 1 post editten, dan doet 1 het toch voor niks.

[ Voor 32% gewijzigd door pelleke op 10-02-2005 13:16 ]

[Janoz]

Versleuteld laten downloaden is net zo veilig als niet versleuteld downloaden aangezien de ontsleutel methode compleet bij de client bekend is (want het is immers een programma dat daar draait). Daarnaast kan je 'hoger level security' alleen maar bepalen of iemand er wel of niet bij kan. Zodra iemand in kan lioggen kan hij alles wat de gebruikerinlog kan op die database. Er is geen mogenlijkheid tot afschermen van bepaalde acties wat bij een tussenstaande proxy wel kan.

Het is inderdaad veiliger waneer dit niet in het programma zelf staat en via een authenticatie pas kan worden opgevraagd, maar feit blijft dat het onderdeel van je programma is dat inloggegevens die je helemaal niet bij de gebruiker in een untrusted omgeving wilt hebben daar wel terecht komen.

[Verwijderd]

Een jaar geleden heb ik voor dezelfde probleemstelling gestaan:
- een e-commerce website(mysql/php) waar online bestellingen worden gedaan
- een offline facturatiepakket(ms-access) waarbij de online bestellingen automatisch in zouden moeten terecht komen
ik heb simpelweg:
1) een vlagje toegevoegd “Uploaded” op de order tabel, dat default op N staat
2) een php script geschreven dat alle orders met Uploaded=N uitleest en in een XML bestand plaatst
3) een toepassing geschreven die op achtergrond op bepaalde tijdsintervallen een HTTP request doet naar het PHP script en de XML file download, parst en in de database van het facturatie pakket insert.
Deze interface werkt al een tijdje erg goed, en veilig. Het is makkelijk uit te bereiden naar andere tabellen, er zit een configureerbare “interface mapper” ingebouwd zodat velden uit online tabel op de offline tabel kunnen gemapt worden.
Geen behoefte aan een directe connectie met de database hier