spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »TrikkieMikkie«

Zitat von »Sneyke«

Ich kenne mich mit dem ganzen Web-kruscht nicht so gut aus. Aber was ist denn an Xampp als richtigen Server auszusetzen? Nur aus Interesse.

Aus Wikipedia (besser hätte ich's auch nicht sagen können...)

Zitat

XAMPP ist nicht für den Einsatz als Produktivsystem (z. B. als öffentlicher Webserver) gedacht, sondern für Entwickler, die möglichst schnell ein kompaktes Testsystem aufsetzen möchten. Dies erklärt auch die bewusst in Kauf genommenen Einschränkungen in Hinblick auf die Sicherheit von XAMPP. Die Missachtung dieser Warnung[1] führte z. B. zum Patras-Hack bei der Bundespolizei im Juli 2011.

Ok. Das erklärts natürlich

@webconqueror

niemals und auf garkeinen Fall schreibst du die Zugangsdaten zur Datenbank in den Qullcode den jede xBeliebige Person bekommen kann!
Den Qullcode kannst du ganz einfach Auslesen und somit hätte jeder 0815 Hacker deine Zugangsdaten zu deiner Datenbank! Sowas ist grob Fahrlässig (und sollte auch meiner Meinung nach bestraft werden!)
Den ganzen Käse mit XAMPP könntest du dir eigentlich sparen da du (glaube ich) garkeinen Webserver absetzen willst sondern nur eine Datenbank? XANPP ist ein "Tool" das mehrere Programme enthält. Die sind so eingerichtet das sie dir einen Webserver mit alles drum und dran (PHP, Datenbank, Java, Mailserver) einrichten. Ob du sowas brauchst weiss ich nicht?

da es dir nur um den Login für dne Spieler geht würde ich das nicht so regeln wie du das vor hast sondern ich würde zwischen Spiel und Datenbank einen weiteren Server (mehr oder weniger Anwendung) setzen.
Nenn wir die neue Anwendung einfach mal "Gameserver".
Dieser Gameserver baut eine Verbindung zu deiner Datenbank auf (Gameserver und Datenbank können ruhig beide auf dne gleichen Rechner liegen) und nur "DU" kennst diesen Gameserver und rückst die Quellcode Dateien auch nicht raus!
Das Spiel (also der Spieler/Client) baut eine Verbindung zu deinem "Gameserver auf. Ich würde dir zu TCP raten. Einfach weil es hier um die Logindaten der Spieler geht und weil die 100% übertragen werden müssen (keine Übertragungsfehler erlaubt).
Wenn dein Spiel/Spieler/Client eine erfolgreiche Verbindung zu deinem Gameserver aufgebaut hat schickt der Client dem Server die Logindaten vom Spieler, Also Bentzername und Passwort). Dein Gameserver verbindet sich nun zur Datenbank und prüft ob die E-Mail AAdresse und das Passwort stimmen. Sollte es stimmen schickt der Gameserver zu Client sowas ähnliches wie "JOa passt alles" zurück.
Wenn das am Client angekommen ist weiss der Spieler das seine Logindaten richtig sind und kann in die nächste Scene wechseln. Auf diese Art und Weisse funktionieren die meisten Gameserver. meistens (eigentlich fast immer) Verbindne sich alle Spieler mit diesem Gameserver und der Gameserver verarbeitet die Anfragen/Nachrichten die vom Client/Spieler geschickt werden.
wenn sich Spieler A bewegt schickt Spieler A das an den Gameserver und der Gameserver schickt es (nachdem er überprüft hat ob Spieler A das überhaupt darf) die neue Position an alle anderen Spieler weiter.
Auch so kannst du ein einfaches Chatprogramm erstellen. Die Nachrichten werden dabei im ms bereich verarbeitet und verschickt!

Für die Loginnachrichten würde ich dir eine Verschlüsselung empfehlen. Da gibt es unter .net schon vorgefertigte Libs von Microsoft. Falls du Mono benutzt musst du dich mal schlau machen welche da geeignet ist...

Wie auch andere schon gesagt haben: NIEMALS Passwörter im Klartext in deiner Datenbank speichern! DICH geht es NICHTS AN welches Passwort der Spieler hat! im schliessten fall kannst du NUR das Passwört ändern! aber NIEMALS solltest du das passwort sehen können! egal auf welche Art und Weisse!
Das ganze was du da über php treibst is auch total unsicher. Sobald ein Hacker rausfindet das du über PHP den Spieler einloggst kann er sich selber ein Script basteln und die Adresse (bei sich Lokal) so abändern und auf eine andere Website weiterleiten. er kennt dann die Eingaben und Ausgaben der PHP Datei und kann die Ausgabe (also den erfolgreichen Login) simulieren und kann sich so einen Login ercheaten. Will mir garnich ausmalen was er noch so alles machen könnte... (Ich erkläre hier nicht wie es geht! wer sowas wissen will muss einfach nur mal auf anständige Programmiererseiten vorbei schauen!)

Wenn du ein Gameserver hast kannst du immerwieder abfragen ob Spieler A das was er machen will überhaupt darf. und wenn nich... dann einfach Verbindung trennen (also rauskicken)


Um das ganze zu testen kannst du dir Lokal einen (Test-)Gameserver erstellen (das is ein eigenes Programm! Versteht sich eigentlich von selber?) dein dein Spiel verbindet sich (also dann lokal) zu deinem Gameserver.
Was du früher oder später brauchst ist ein PC der 24/7 läuft. Sowas nennt man auch "Server". Ist im prinzip nur ein Rechner der eben 24/7 läuft ich würde dir da den Windows Server empfehlen. Ich gehe einfach mal davon aus das du dich mit Linux nichts aus kennst? (Windows Server haben als Betriebsystem zb Windows Server 2012).
Sowas bekommst du billig oder auch teuer... für 20€ im Monat solltest du einen einigermassen Guten (Windows-)Server bekommen.

die Photon Network Engine (oder die Unet Engine oder wies heisst) nehmen dir zwar viel von der kommunikation zwischen Server und Client ab... Wenn du da aber etwas eigenes Basteln willst... wird es meistens schwerer...

Du kannst auch in Unity ein Script (ok viele Scripte) erstellen das dein Spiel auch gleichzeitig als Server erstellt bzw gestartet werden kann (sieht man oft in viele Spiele wenn das sowas steht wie "Host Server). Viele gehen aber auch hin und trennen Gameserver und Client komplett... Wie du es machst ist dir überlassen... Aber bitte... Keine Zugangsdaten zur Datenbank oder sonstwo reinschreiben... immer damit rechnen das ein Hacker drankommen könnte... und selbst wenn nur 1 Hacker von 100Spieler online ist... er kann das ganze Gameplay kaputt machen!

Zitat von »webconqueror«

Jo langer Text
Nur eine Sache noch:
"Das ganze was du da über php treibst is auch total unsicher."
Okay, nehme ich mal so hin. Wie würdest du dann dazwischen kommunizieren? Vllt. hab ich auch einfach
was nicht mitbekommen

Liebe Grüße

Zitat

da es dir nur um den Login für dne Spieler geht würde ich das nicht so regeln wie du das vor hast sondern ich würde zwischen Spiel und Datenbank einen weiteren Server (mehr oder weniger Anwendung) setzen.
Nenn wir die neue Anwendung einfach mal "Gameserver".

eine Anwendung erstellen die sich mit Client und Datenbank verbindet!

Zitat von »MVN050«

niemals und auf garkeinen Fall schreibst du die Zugangsdaten zur Datenbank in den Qullcode den jede xBeliebige Person bekommen kann!

Wo hat er das gemacht? Und wenn wir von z.B. PHP reden, da ist das Gang und Gebe und da kann nicht jeder den Source auslesen.

Zitat von »MVN050«

da es dir nur um den Login für dne Spieler geht würde ich das nicht so regeln wie du das vor hast sondern ich würde zwischen Spiel und Datenbank einen weiteren Server (mehr oder weniger Anwendung) setzen.

Zitat von »MVN050«

eine Anwendung erstellen die sich mit Client und Datenbank verbindet!

Genau das macht er ja mit PHP. Was genau hast du denn verstanden? Sein Client schickt eine Anfrage zu einem PHP-Script, das checkt die Datenbank und gibt dann dem Client eine Antwort. Das ist absolut sauber.
Ich hoffe du schlägst ihm nicht vor er solle eine lokale Anwendung schreiben, wo dann irgendwo das Passwort für die DB drin steht. Das wäre fatal. Wenn die Anwendung aber auf einem Server läuft, wieso ist es dann wichtig, ob die Anwendung mit PHP oder etwas anderem geschrieben wurde? Das ist total egal. Lediglich das Passwort zur Datenbank muss geschützt bleiben und da erfüllt ein kleines PHP-Script auf einem Server absolut den Zweck.
Allerdings werfe ich mal die Frage in den Raum wie die von dir vorgeschlagene Anwendung sich mit dem Client verbinden sollte. Erstens kennt sie die IPs der möglichen Clients nicht und zweitens stecken die Clients höchstwahrscheinlich hinter einem Router oder einer Firewall. Da kann sich diese Anwendung gar nicht verbinden. Wenn sie es könnte, wen würde es davon abhalten seine eigene Anwendung zu schreiben, die sich zu beliebigen Clients verbindet und sich dann als das echte System ausgibt? Damit könnte man ja jeden beliebigen Spieler täuschen, weil niemand verifizieren kann, wer da 'anruft'.

Zitat von »MVN050«

Ich würde dir zu TCP raten. Einfach weil es hier um die Logindaten der Spieler geht und weil die 100% übertragen werden müssen (keine Übertragungsfehler erlaubt).

HTTPS ist sogar noch besser als nur TCP! Es ist nämlich verschlüsselt, was für Passwörter ziemlich sinnvoll ist. Und da muss er sich nichtmal selbst um die Verschlüsselung kümmern. Er braucht nur einen Webserver mit einem SSL-Zertifikat (solchen Space gibt's dank Letsencrypt ja mittlerweile recht günstig).

Zitat von »MVN050«

Das ganze was du da über php treibst is auch total unsicher. Sobald ein Hacker rausfindet das du über PHP den Spieler einloggst kann er sich selber ein Script basteln und die Adresse (bei sich Lokal) so abändern und auf eine andere Website weiterleiten.

Was hätte ein Hacker davon, wenn er seinen eigenen Client gegen einen anderen Server laufen ließe? Dann kann er sich mit einem Fake-Account auf einem Fake-Server einloggen. Und dann? Hacken kann er damit überhaupt niemanden außer sich selbst. Oder er könnte sich einen Freeshard-Server bauen. Unsicher ist das aber nicht.

Insgesamt wirkt es ein bisschen so, als ob du den Thread überhaupt gar nicht gelesen oder keine Ahnung von der eigentlichen Materie hast, MVN050. Also bitte stifte hier keine weitere Verwirrung, webconqueror war bisher schon auf einem sehr guten Weg.

@BlueCobold
Tut mir leid. Hab nich gesehen das es hier um ein Singleplayer spiel geht.

Single- oder Multiplayer macht da überhaupt keinen Unterschied.

Ich weiss nicht ob das schon zur Sprache kam. Aber du solltest "parameterized queries" verwenden. SQL injection solltest du nicht riskieren.

Beim Passwort in plain text gabs ja schon glaube ich den Ratschlag ein hash anstatt das direkte Passwort abzuspeichern. Und dann später hash gegen hash matchen. Der hash kann dann auf userseite generiert werden und du risikierst nicht dass passwörter übers web geschickt werden oder die Datenbank gehackt wird und das Passwort direkt lesbar ist.