Hallo,
ich plane für mein Spiel das CMS als Anwendung für Windows in c# zu schreiben.
Auf dem Spielserver läuft Linux mit MySQL als Datenbank.
Jetzt ist meine Frage, habt ihr soetwas schon mal gemacht? Welche Schnittstelle macht da am meisten Sinn?
Oder sollte ich gleich die Datenbank für diese Verbindung nach aussen öffnen und direkt mit der Datenbank kommunizieren?
blum
CMS als lokale Anwendung
gepostet vor 17 Jahre, 9 Monate von blum
gepostet vor 17 Jahre, 9 Monate von TheUndeadable
Ich würde folgendes machen:
Du öffnest den Datenbankport nach außen, aber NUR über eine VPN-Verbindung. Ihn ganz offen zu lassen wäre meiner Meinung nach fahrlässig.
Über diesen kommunizierst du dann über eine Datenbankverbindung (ADO.Net, MySQL-Connector) mit deiner Anwendung.
Wenn du die Sache mit dem VPN nicht hinbekommen solltest, würde ich entweder einen Webservice aufbauen, was unter PHP nicht sonderlich trivial, aber schaffbar ist.
Oder du baust einfach ein 'Interface', wo du einfach nur Xml-Dateien hochlädst und Xml-Dateien wieder erhältst. Dies wäre eventuell die einfachste Variante.
Über die WebRequest und WebResponse-Klassen kannst du sehr einfach HTTP-Requests aufbauen und die Antwort wieder auslesen. So lässt sich ein Administrationsinterface einfach aufbauen.
Du öffnest den Datenbankport nach außen, aber NUR über eine VPN-Verbindung. Ihn ganz offen zu lassen wäre meiner Meinung nach fahrlässig.
Über diesen kommunizierst du dann über eine Datenbankverbindung (ADO.Net, MySQL-Connector) mit deiner Anwendung.
Wenn du die Sache mit dem VPN nicht hinbekommen solltest, würde ich entweder einen Webservice aufbauen, was unter PHP nicht sonderlich trivial, aber schaffbar ist.
Oder du baust einfach ein 'Interface', wo du einfach nur Xml-Dateien hochlädst und Xml-Dateien wieder erhältst. Dies wäre eventuell die einfachste Variante.
Über die WebRequest und WebResponse-Klassen kannst du sehr einfach HTTP-Requests aufbauen und die Antwort wieder auslesen. So lässt sich ein Administrationsinterface einfach aufbauen.
gepostet vor 17 Jahre, 9 Monate von exe
Ich hatte mal was ähnliches geplant, bin aber aus mehreren Gründen wieder davon abgekommen.
1) Die Datenbank muss dafür Verbindungen von aussen akzeptieren. Damit erlaube ich jedem Nutzer des CMS auch einen direkten Zugriff auf die Datenbank, was für mich ein ziemliches Sicherheitsrisiko darstellt. Man kann über ACL und Kontrolltrigger die Datenbank auch absichern, das ist aber sehr mühsam und auch kein wirklich praktikabler Schutz. Lässt man das CMS nicht direkt auf die Datenbank muss man auf dem Server eine Schnittstelle, also eine Art Datenbankwrapper, erstellen. Der damit verbundene Aufwand steht in keinem Verhältnis zu dem Gewinn einer lokalen CMS-Anwendung.
2) Man kann das CMS nur vom Client aus kontrollieren. Besonders zeitgesteuerte Veröffentlichung von Seiten fällt damit weg, solange ich nicht zusätzliche Dienste auf dem Server installiere. Hier habe ich wieder das gleiche Problem wie oben schon genannt.
Letztendlich sieht die geschichte mit dem CMS als lokale Anwendung so aus, dass die Anwendung nur ein, durch mächtigere GUI-Komponenten, besseres Interface zur Verfügung stellt, ein großer Teil des CMS aber trotzdem noch auf dem Server laufen muss.
Ich habe michfür Bricolage als CMS entschieden. Das ist ein sehr mächtiges Backoffice-CMS. Dadurch kann man den CMS-Server, genau wie bei deiner Idee, von der eigentlichen Website getrennt laufen. Bricolage generiert, ähnlich wie das vermutlich bei dir laufen würde, über sogenannte Burner und Output Channel statische Inhalte und verteilt die auf die Publishingserver. Man kann das auch mit dynamischen Websiten kombinieren. Bei mir in der Firma benutzen wir Bricolage z.B. um statische Seiten (Impressum, AGBs, FAQs etc.pp.) in unsere dynamischen Portale zu publizieren.
Ist am Anfang ein bisschen Tricky zu bedienen, belohnt einen dann aber mit allen Schikanen, die man von einem Backoffice-CMS erwarten könnte
1) Die Datenbank muss dafür Verbindungen von aussen akzeptieren. Damit erlaube ich jedem Nutzer des CMS auch einen direkten Zugriff auf die Datenbank, was für mich ein ziemliches Sicherheitsrisiko darstellt. Man kann über ACL und Kontrolltrigger die Datenbank auch absichern, das ist aber sehr mühsam und auch kein wirklich praktikabler Schutz. Lässt man das CMS nicht direkt auf die Datenbank muss man auf dem Server eine Schnittstelle, also eine Art Datenbankwrapper, erstellen. Der damit verbundene Aufwand steht in keinem Verhältnis zu dem Gewinn einer lokalen CMS-Anwendung.
2) Man kann das CMS nur vom Client aus kontrollieren. Besonders zeitgesteuerte Veröffentlichung von Seiten fällt damit weg, solange ich nicht zusätzliche Dienste auf dem Server installiere. Hier habe ich wieder das gleiche Problem wie oben schon genannt.
Letztendlich sieht die geschichte mit dem CMS als lokale Anwendung so aus, dass die Anwendung nur ein, durch mächtigere GUI-Komponenten, besseres Interface zur Verfügung stellt, ein großer Teil des CMS aber trotzdem noch auf dem Server laufen muss.
Ich habe michfür Bricolage als CMS entschieden. Das ist ein sehr mächtiges Backoffice-CMS. Dadurch kann man den CMS-Server, genau wie bei deiner Idee, von der eigentlichen Website getrennt laufen. Bricolage generiert, ähnlich wie das vermutlich bei dir laufen würde, über sogenannte Burner und Output Channel statische Inhalte und verteilt die auf die Publishingserver. Man kann das auch mit dynamischen Websiten kombinieren. Bei mir in der Firma benutzen wir Bricolage z.B. um statische Seiten (Impressum, AGBs, FAQs etc.pp.) in unsere dynamischen Portale zu publizieren.
Ist am Anfang ein bisschen Tricky zu bedienen, belohnt einen dann aber mit allen Schikanen, die man von einem Backoffice-CMS erwarten könnte