[Alg] Server-Client App. Protocol of rechtstreeks met de db?

[Av3ng3rtje]

Hallo,

Ik zit een beetje met een dilemma , ik ben bezig met een applicatie aan het bouwen voor een gaming site van mij. De game die we spelen spugt een file uit waar informatie staat over je vorderingen , deze wil ik verwerken op een site. De site is geprogrammeerd in PHP en gebruikt MySQL.

Nu was ik bezig geweest om een Server en een Client te schrijven in C#.NET met een eigen protocol wat ik zelf nogal gammel in elkaar vond zitten. Veel geneste if's , een rommeltje eigenlijk dus. De client logt eerst in op de server en de server stuurt terug of de gebruiker de info mag uploaden Dit wordt gecheckt via de MySQL database. Nu vroeg ik me af , is het niet makkelijker om direct verbinding te maken met de database, maarja daar zitten natuurlijk risco's aanvast dacht ik , ik had ergens gelezen dat het mogelijk is om sommige applicaties te disasm'en en zo vervolgens de username en password van de database er uit te vissen zodat je hele database in een keer bloot komt te liggen.

Dus mijn vraag is nu "hoe" zouden jullie het doen? Als iemand een idee heeft om makkelijk een protocol te verwerken zonder dat je broncode een grote geneste if's wordt is dat ook welkom, andere ideeen ook natuurlijk.

Of is het toch veilig genoeg om gewoon connectie te maken met een MySQL database server?

[Paul]

Av3ng3rtje schreef op dinsdag 13 september 2005 @ 18:41:
Dus mijn vraag is nu "hoe" zouden jullie het doen? Als iemand een idee heeft om makkelijk een protocol te verwerken zonder dat je broncode een grote geneste if's wordt is dat ook welkom, andere ideeen ook natuurlijk.

Zowat ieder protocol gebruikt iets wat uiteindelijk uitgelegd kan worden als een stapel ifjes, of het nu subklassen zijn die zich ergens registreren waar in een mooi loopje door de array gelopen wordt en wordt vergeleken of het die opdracht is waarna SubKlasse.Execute(OntvangenPakketje) wordt uitgevoerd, of hardcoded "if opdracht=save then SaveOpdracht(OntvangenPakketje) else if opdracht=open then OpenOpdracht(OntvangenPakketje).
Aan het testen WAT je nu ontvangen hebt ontkom je gewoon niet aan. Wel zou ik je aanraden iets als een public/private key versleuteling te gebruiken, de clients weten je public key, de server je private key en encrypten maar.

Over rechtstreeks over internet je database aan laten spreken door clients: Ik heb letterlijk geen idee of MySQL-data nu encrypted over een socket gaat of niet. Zo nee, dan kun je inderdaad met een simpele sniffer het ww van je database opvragen. Zelfs als je (de user die door) die client (gebruikt wordT) alleen maar insert-rechten geeft, zonder verdere select of update (of nog erger: with grant option) dan kan men al nep-info in je db stoppen.

[Wim Leers]

Misschien handiger: laat je clients inloggen op de server, en wanneer ze ingelogd zijn, geef je toegang tot de database, met welk protocol dan ook.

En waarschijnlijk is het handiger om met .ini, .inf of .xml of eender wat te gebruiken, in plaats van een 'protocol'?

[Paul]

Bashrat schreef op dinsdag 13 september 2005 @ 18:59:
Misschien handiger: laat je clients inloggen op de server, en wanneer ze ingelogd zijn, geef je toegang tot de database, met welk protocol dan ook.

Al dan niet "inloggen" is hier niet de vraag. Het is niet alsof "inloggen" (lees: een paar wederzijds bekende stukjes tekst van de client naar de server sturen) er opeens voor zorgt dat je verbinding encrypted is of zo?
Daarnaast is juist de vraag _welk_ protocol te gebruiken

En waarschijnlijk is het handiger om met .ini, .inf of .xml of eender wat te gebruiken, in plaats van een 'protocol'?

En een geuploade .ini, .inf of .xml hoeft niet meer geparsed te worden?

[MisterData]

Paul Nieuwkamp schreef op dinsdag 13 september 2005 @ 19:06:
[...]
Al dan niet "inloggen" is hier niet de vraag. Het is niet alsof "inloggen" (lees: een paar wederzijds bekende stukjes tekst van de client naar de server sturen) er opeens voor zorgt dat je verbinding encrypted is of zo?
Daarnaast is juist de vraag _welk_ protocol te gebruiken

[...]
En een geuploade .ini, .inf of .xml hoeft niet meer geparsed te worden?

Voor ini's en xml's zijn meestal wel standaard API's aanwezig die het vervelendste parse-werk uit handen nemen

[Av3ng3rtje]

Hmm ff wat gekeken naar de MySQL API in .NET en zag dit staan bij de connection string:

Encrypt
When true, SSL encryption is used for all data sent between the client and server if the server has a certificate installed. Recognized values are true, false, yes, and no.

Note This parameter currently has no effect

Lekker weer , bouw je iets in je API wat nog niet eens werkt =x

[djc]

Av3ng3rtje schreef op dinsdag 13 september 2005 @ 19:19:
Lekker weer , bouw je iets in je API wat nog niet eens werkt =x

Waarschijnlijk om de API meer consistent te maken met andere databases, of omdat die feature er wel in gaat komen.

[Verwijderd]

Het meest logisch lijkt me om een webservice te bouwen waarnaar je een dataset met de gegevens opstuurt. Dan beveilig je dit met een username en password voor iedere gebruiker op de webservice, maar gebruik je de username / password van de database alleen intern in de webservice.

Succes

[Verwijderd]

Verwijderd schreef op woensdag 14 september 2005 @ 11:03:
Het meest logisch lijkt me om een webservice te bouwen waarnaar je een dataset met de gegevens opstuurt. Dan beveilig je dit met een username en password voor iedere gebruiker op de webservice, maar gebruik je de username / password van de database alleen intern in de webservice.

Succes

Exact, een webservice is een prima oplossing in deze situatie. Maar in hoeverre valt zoiets eenvoudig te bouwen in PHP?

De gegevens kun je overigens dan prima als XML document versturen richting je webservice. PHP heeft geloof ik wel wat libs waarmee XML en XSLT eenvoudig vallen in te zetten.

[dingstje]

In PHP5 zitten de klasses SoapServer en SoapClient (zie manual over SOAP in PHP) waarmee je eenvoudig een webservice kan maken en uitlezen in PHP.

Als je PHP4 gebruikt moet je eens kijken naar NuSOAP. Dat is volgens veel artikelen de beste SOAP library voor PHP4.

Edit: om XML te parsen in PHP5 gebruik je best SimpleXML of PEAR::XML_Parser voor PHP4.

[ Voor 22% gewijzigd door dingstje op 14-09-2005 16:06 . Reden: typo ]

[Av3ng3rtje]

Bedankt mensen , ik ga eens kijken wat ik er van kan maken