Schon seit längerer Zeit existiert im Uservoice der Wunsch Kommunikation nach außen. Hierbei sollen wir ermöglichen, dass Entwickler auf Domains in der Aussenwelt zugreifen können. Ich habe mir bereits Gedanken dazu gemacht, wie eine API hierzu aussehen könnte und bin auf eure Meinung hierzu gespannt. (Beitragsbild von Marcelo Graciolli via Flickr – Creative Commons)
Zuerst muss man sich bei der Weiterentwicklung unserer API stets die Gedanken machen, welche Probleme auftauchen könnten. Probleme bedeuten nicht automatisch, dass wir Dinge nicht realisieren. Vielmehr heisst es oft, dass wir kreative Lösungsansätze finden müssen, um Dinge ermöglichen zu können.
Mögliche Probleme
Bei der Kommunikation nach außen sehe ich das Problem, dass Server angefragt werden könnten, die dem entsprechenden Entwickler gar nicht gehören und der Knuddels-Server missbraucht werden könnte, um andere Server mit DoS-Angriffen zu versehen.
Aus dieser Problematik resultieren zwei Kerngedanken:
- Die Anzahl der Anfragen pro Zeit und die Menge der zu übertragenden Daten ist begrenzt
- Entwickler können nur auf Server zugreifen, die sie für sich selbst auf eine Whitelist gesetzt haben
Begrenzung der Anfragen
Ich bin der Meinung, dass zehn gleichzeitige offene Anfragen und 60 Anfragen pro Minute mit einem Maximum von 10KB Daten pro Anfrage ausreichen sollten, um die meisten Ideen zu realisieren. Diese Art Begrenzung ließe sich leicht im AppServer realisieren.
Whitelisting von Domains
Um bestimmte Domains für eine App freizuschalten stelle ich mir vor, dass der Entwickler von Knuddels eine Datei erhält, die er auf einen Webserver mit dieser Domain legen muss. Einmal pro Woche crawlt Knuddels die Datei. Falls die Datei in einer Woche nicht verfügbar war, so wird der Entwickler über den Fehler informiert und hat eine Woche Zeit das Problem zu beheben. Fehlt die Datei auch beim zweiten Versuch, so wird der Zugriff auf diese Domain automatisch gesperrt.
Neben diesen Whitelist-Domains stelle ich mir vor, dass gewisse Internet-Standards alá api.twitter.com auf einer globalen Whitelist stehen.
Mein API-Vorschlag
Über den KnuddelsServer könnte man auf ein Objekt der Klasse ExternalServerAccess Zugriff erhalten mit dem man Abfragen vornehmen kann.
Beispiel einer GET-Requests
var externalServerAccess = KnuddelsServer.getExternalServerAccess();
var domainName = 'knuddels-wiki.de';
if (externalServerAccess.canAccessDomain(domainName))
{
var domain = externalServerAccess.getDomain(domainName);
domain.get('index.php/Ironis {
onSuccess: function(data, header)
{
// Arbeit mit den Daten
},
onFailure: function(header)
{
// Fehlerbehandlung
}
});
}
Beispiel eines POST-Requests
/* ...Boilerplate Code... */
domain.post('index.php/Ironist', {
data: { 'user' : 'Ironist', 'points' : 1000 },
onSuccess: function(data, header)
{
// Arbeit mit den Daten
},
onFailure: function(header)
{
// Fehlerbehandlung
}
});
Auflistung aller zugreifbaren Domains
var externalServerAccess = KnuddelsServer.getExternalServerAccess(); var allAccessibleDomains = externalServerAccess.getAllAccessibleDomains();
Eure Meinung ist gefragt
- Wäre mit dieser Art der API der Wunsch nach Kommunikation nach außen (nicht GameSocket) soweit erfüllt?
- Welche Probleme könnte diese Lösung für euch machen
- Was würde euch fehlen?
- Wie würdet ihr die Kommunikation nach außen nutzen?
Der offizielle Knuddels Blog 
Mir wäre es wichtig, dass die user die eine App benutzen, die mit einen Externen Server kommuniziert auch darüber aufgeklärt wird (mind. wenn man daten nach außen sendet und nicht nur welche empfängt). Auch wenn in klammern (nicht Gamesocket) steht, wäre gerade bei diesen Punkt eine erhebliche! erleichterung festzustellen. (Server 2 Server Kommunitkation)
Was ich nur negativ sehe ist, wenn ich z.b. eine App schreiben möchte die bei Regen jeden Knuddelt dieses nicht so einfach umsetzen kann, da ich auf server zugreifen muss, worüber ich nicht verfüge.
LikeLike
Ich sehe das genauso kritisch wie Jan. Kommunikation nach außen heißt immer, man weiß nie, was nach außen geht. Werden ganze User-Objekte übertragen, um eine eigene Datenbank an Informationen über User aufzubauen? Man kann sehr viele böse Sachen damit anstellen.
Wenn die Whitelist beliebig lang sein kann, kann ich mir auch beliebig viele Subdomains anlegen und somit das Limit erhöhen. Oder eine Catch-All-Domain.
Ich würde es besser finden, wenn User nicht die Möglichkeit haben, eigene Server anzusteuern. Gibt es denn schon einen sinnvollen Anwendungsbereich? Stattdessen sollte es eine globale Whitelist geben. Entwickler können dann APIs angeben, die sie anbinden wollen und Knuddels entscheidet selbst, ob sie diese zulassen.
Dann muss es auch keine Abfrage geben, da externe APIs wie Twitter oder Wetterdienste nichts mit Nicks oder anderen Informationen anfangen können, einfach, weil sie nicht in der Hand des Entwicklers liegen.
LikeLike
Zum Thema ”user informieren”: Ja, volle zustimmung, der user sollte dem zustimmen MÜSSEN, also opt-in. Bisher ist es so das die app zugriff auf den user hat sobald er den channel betritt bzw. den bot anschreibt, das müsste dahingehend geändert werden das wenn eine app im channel installiert ist, die externe verbindungen aufbaut, erst eine Anfrage an den user geht ob er damit einverstanden ist oder eben nicht. Wenn ja dann alles so wie bisher, wenn nein, dann erhält die app keinen zugriff auf das userobjekt, der user existiert also für die app nicht, und der user erhält automatisch von knuddels eine meldung das er in diesem channel keine apps nutzen kann. (Problem hierbei allerdings das das ganze relativ leicht für datensammler umgehbar ist indem im hauptchannel einfach keine externe kommunikation durch apps erfolgt sondern die apps im hauptchannel einfach einer app in einem anderen channel ihre daten schicken und eine app in dem zweiten Channel dann einfach nach aussen ”telefoniert”. Es müsste also eine einschränkung in der api erfolgen das eine app nur anderen app bots schreiben kann die im gleichen channel mit apps gebunden sind. Das verschlechtert bzw. verhindert dann aber eben die allgemeine kommunikation von appbots verschiedener channels untereinander.)
Zum Thema ”ich will zu einem Server der aber nicht meiner ist”: Das ist kein Problem, schließlich kannst du Deinen Server in der API whitelisten und von deinem Server dann jeden beliebigen Server ansprechen. Das whitelisting hat ja nur den sinn das Du nicht die Knuddelsserver dazu nutzen kannst direkt jeden beliebigen Server zuzumüllen mit deinen Anfragen, das musst du dann eben über deinem Server machen. 😉
Zum Thema ”böse sachen”: jap, da kann man viele böse sachen mit machen, kann man aber mit allem in der API machen. Zudem muss man sich darüber im klaren sein das wenn man hier anfangen sollte bigdata oder ähnliches aufzuziehen, und das ohne den user irgendwie darüber zu informieren bzw. ohne ein opt-in anzufordern, man im grunde sofort im strafrechtlichen bereich landet und nicht nur gegen eventuelle Richtlinigen von Knuddels verstößt. Eine Möglichkeit dem etwas vorzubeugen könnte vielleicht sein das knuddels nur .de domains per API whitelisten lässt? Hätte schonmal den vorteil das der server bzw. serverbetreiber somit auf jedem fall deutschem recht unterliegt und auch direkt eine ladungsfähige Person hinterlegt ist.
Zum Thema ”Catch-All-Domain”: Ja, sehe ich aber kein problem, sofern eben domain eine .de ist, oder?
Zum Thema: ”globale Whitelist”: Wer soll die pflegen? Wie man im Artikel erkennen kann soll die whitelistung im grunde automatisch erfolgen. Im übrigen sind API von anderen webseiten wie z.b. wetter u.s.w. entweder gar nicht verfügbar oder kostenpflichtig. (ausnahmen bestätigen natürlich immer die regel) Zumal dann die anfragen alle zentral von knuddels.de kommen, das dürften sich die webseiten dann ganz schnell gern bezahlen lassen wenn eine offensichtlich kommerzielle Seite auf solche daten ständig zugreifen will. 😉
Allgemein zum Thema Datenschutz:
Auch ohne zugriff auf externe server kann jemand der es drauf anlegt schon jetzt fleißig Daten sammeln und diese auch nach extern bringen, vielleicht nicht so bequem, aber es ist eben auch jetzt schon möglich. Daher sollte nicht im vordergrund stehen das datensammeln zu verhindern sondern die Nutzer der App bzw. die User die den Channel betreten darüber zu informieren das dies möglich ist und anfragen ob sie dies wollen und ggf. ermöglchen das sie auch zu einem späteren zeitpunkt ihre einwilligung jederzeit widerrufen können. Wo wir wieder bei einem vernüftigen Rechtemanagment für die User währen. 😉
Zur Idee selbst:
Nimmt man den Gameserverbereich aus (da dürften die latenzen einfach zu groß werden wenn alle anfragen über den appserver laufen) dann ist ja im grunde schon fast alles abgedeckt. Die limits sind ja soweit ganz okay finde ich. Vielleicht könnten die ja im einzelfall, falls erforderlich, auch angepasst werden?
Was mir fehlt ist ein event in der API wenn der externe server daten schicken will ohne vorherige anfrage der app. Aktuell müsste ich in der app polling verwenden was irgendwie ja nicht so schicki ist.
Also auf dem externen server passiert etwas und das will der server der app mitteilen, da wäre ein event super finde ich.
LikeLike
Ich bin mir unsicher, ob es reicht den Zugriff auf Domains zu beschränken. Bestes Beispiel ist hier knuddelsseiten.de. Hierauf läuft eine Vielzahl an verschiedenen Projekten. Jedes Projekt hat eine bestimmte Subdomain. Wenn Subdomains damit auch abgefackelt sind, dann passts.
LikeLike
Hier sind durchaus interessante Ansätze mit drinnen. Ich bin aber der Meinung, dass sämtliche Apps, die Daten zu einem externen Server senden, vor der Veröffentlichung zwingend überprüft werden MÜSSEN. Somit sind zwingend Regeln notwendig, was an externe Server übertragen werden darf und was nicht.
Natürlich kann serverseitig nicht überprüft werden, was mit den Daten angestellt wird. Empfängt dieser aber nur unproblematische Daten, kann damit nicht viel angestellt werden.
User sollten ebenfalls darüber informiert werden, dass Daten in dieser App an externe Server weitergegeben und dort verarbeitet werden. Dies muss er erst bestätigen, bevor die Daten tatsächlich gesendet werden. Ansonsten artet es in Extremfällen so aus wie bei der Newsletter-Geschichte.
Kev hatte ja den Vorschlag, nur .de-Domains zuzulassen. Da halte ich erst einmal wenig von. Eine .de-Domain ist kein Beweis, dass die Server auf deutschen Boden stehen. Jeder kann sich eine Domain mit solcher TLD reservieren und der Server kann sonstwo stehen. Die Endung ist kein Anhalt für den Serverstandort.
Ansonsten wurde hier in den Kommentaren alles weitere wichtige bereits gesagt.
Um die Fragen aus dem Artikel zu beantworten:
Wäre mit dieser Art der API der Wunsch nach Kommunikation nach außen (nicht GameSocket) soweit erfüllt?
Für mich wäre er erfüllt, ja.
Welche Probleme könnte diese Lösung für euch machen
Ich denke, ich hätte damit so, wie ich es geplant habe, keine Probleme.
Was würde euch fehlen?
Im Grunde ist alles vorhanden, was ich benötigen würde.
Wie würdet ihr die Kommunikation nach außen nutzen?
Ich programmiere aktuell ein Spiel, welches mit haufenweise Daten arbeitet. Die maximale Größe der Persistence ist aktuell ausreichend. Soll aber mehr Abwechslung mit rein gebracht werden, kann die Datenmenge gerne mal auf über einen Gigabyte anwachsen. Ich würde also die Daten serverseitig im Hintergrund in einer Datenbank halten und abfragen.
LikeLike
Gefällt mir sehr gut. Die ganzen Bedenken kann ich nicht verstehen. Da das ganze Serverseitig abläuft können keine geheimen Informationen vom Client ermittelt werden (IP, …). Außerdem ist es bereits jetzt ziemlich einfach möglich, Daten zu sammeln und mir als Entwickler in einem Format anzuzeigen welches ich dann extern einpflegen kann. Würde die Möglichkeit gerne nutzen.
LikeLike