• Hallo allerseits,
    Ich hatte grade aus reinem Interesse mehrfach eine Anfrage nach einem API-Key an den Server gestellt und musste zu meinem Entsetzen feststellen, dass der Key nicht statisch ist.
    Jetzt würde mich interessieren, welcher der Keys davon gültig ist und warum ein Nutzer (i.e. alle Daten in der Anfrage identisch) mehr als einen Key für seine Anwendung erhält.

  • Hallo Fisaga,
    Ich erhalte je Anfrage ein Keypaar, diese Keys ändern sich allerdings. Mich wunderte das daher ein wenig, da es einen Unterschied macht ob ich den Key "27eb7f9bc1e8908ea59704150ece5e0df" oder "2beb7f9bc1e8a6de29704150ece5e0df" verwende.(keine realen Keys)


    Die Verwendungsanleitung habe ich selbstverständlich bereits gelesen, wobei hier auch z.B. der access-token über den Hash des privaten API-Keys und den vom Nutzer angegebenen Token validiert wird. Das das Ergebnis gleich bleibt, wenn der Service verschiedene Keys für den privaten Key bekommt ist sehr, sehr unwahrscheinlich(Kollisionswahrscheinlichkeit md5 ist 0,5^128)

  • Es wird einfach IMMER ein neuer Key generiert. Welchen du davon dann wirklich benutzt, bleibt dir überlassen. Alle Keys bleiben gültig (bis wir vielleicht irgendwann mal doppelte Einträge löschen)

  • danke fürs aufklären :)
    Was mir auch grade auffällt ist, dass man Schlüssel als Nutzer nicht mehr ungültig machen kann - hätte ich einen Dual und würde den rauswerfen, hätte dieser extern bis zum Ende aller Tage Zugriff, da ja das Account-Token gültig bleibt-

  • Hallo,


    du kannst dir in diesem Fall beliebig viele Keys generieren lassen (Es gibt noch die Möglichkeit die Daten eines bestehenden API - Keys zu ändern, werde ich in meiner Anleitung noch ergänzen, hab ich aber vorerst weggelassen). In der Regel generiert man sich 1x pro Tool und Welt ein Key-Paar, welches dann immer wieder verwendet wird.


    Der accessToken ist pro publicSiteKey immer gleich. Dein Beispiel würde also wie du bereits geschrieben hast, dazu führen, dass ein Dual, sofern er sich den accessToken notiert hat, sich trotz Entfernung aus dem Account weiterhin gegenüber dem externen Tool (für das er den accessToken hat) authentifizieren kann. Dieses Problem lässt sich wahrscheinlich nicht alt zu leicht lösen (natürlich könnte man die Zeit mit einbeziehen, dass würde aber Bedeuten, dass man z.B. bei jedem Login einen neuen accessToken erzeugen müsste. Dies könnte man natürlich dahingehend umgehen, dass man den accessToken nicht als Login sondern nur zur Authentifizierung bzw. Autorisierung beim Anlegen eines Tool - Accounts verwendet.


    Ich werde das mal so weiterleiten, ggf. findet man ja noch eine vernünftige Lösung für das Problem.


    Grüße,
    Teekanne

  • Was das Token angeht, wie wäre es mit folgendem Verfahren:
    Nutzer müssen aktiv ein Token für ihren Account und einen publicSiteKey generieren und können die Generierung jederzeit wieder anstoßen. Hat ein Nutzer keinen Key generiert(oder einen Alten wiederrufen), erhält das Tool den Wert null anstelle eines Tokens.
    Was auf eurer Seite dann dazu kommt ist eine einfache Tabelle, die ähnlich wie die folgende aussehen könnte:

    Quote

    CREATE TABLE `player_site_mm` (
    `playerId` INT(11) UNSIGNED NOT NULL,
    `siteKey` CHAR(32) DEFAULT NULL,
    PRIMARY KEY (`playerId`, `siteKey`)
    );


    Würde dann noch etwas vorschlagen, was die Anmeldungen von Seiten speichert, dann müsste das zweite kein Char sein, z.B.


    Quote

    CREATE TABLE `player_site_mm` (
    `playerId` INT(11) UNSIGNED NOT NULL,
    `siteId` INT(11) UNSIGNED NOT NULL,
    PRIMARY KEY (`playerId`, `siteId`)
    );

    The post was edited 2 times, last by LordBJ: Versuch die Formatierung zu reparieren ().

  • Hallo,


    es gibt viele Varianten dieses Problem zu lösen, dies wäre sicher auch eine Option, wobei man hier wieder den Nachteil hat, dass der Token erst mit dem nächsten Update aktiv wäre, da die API Werte nur 1 mal am Tag generiert werden. Sprich der Spieler würde einen Token erzeugen, das externe Tool würde dies aber am nächsten Tag mitbekommen, was das Feature wieder uninteressant(er) macht.


    Ich habe es auf jeden Fall schon mal weitergeleitet, die Entwickler und Designer werden sich da sicher Gedanken drüber machen.


    Grüße,
    Teekanne

  • In dem Fall ist vielleicht ein API-Call wie folgender sinnvoll:

    Quote


    Quote


    {"time":123456,"response":{"players":[{'playerId':'11111', 'externalLoginToken':'a23c42aadf'},{'playerId':'11113', 'externalLoginToken':'a2942aad4f'}]}}


    Den könntet ihr notfalls ja auch einfach vorgenerieren nur in geringeren Abständen(stündlich vielleicht?), weil die Datenmasse und damit die verursachte Last deutlich kleiner sein müsste. Um die Größe zu minimieren, würde ich in dem Fall einfach alle Spieler überspringen, die keine Freigabe gegeben haben(i.e. keine Token haben).

  • Hallo,


    wie bereits geschrieben gibt es viele mögliche Variationen eine solche "Sicherheit" einzubauen. Nachdem wir die technische Funktionalität der API nicht genau kennen ist es auch schwierig zu sagen, ob sich die von dir vorgeschlagene Variante überhaupt (leicht) umsetzen lässt, da hier sicher viele Faktoren eine wichtige Rolle spielen (Datenmenge, Traffic, Last, usw.)
    Ich habe die Problematik auf jeden Fall an die entsprechende Stelle weitergeleitet diese wird sich der Sache annehmen und dann eine Entscheidung fällen, wobei ich mal davon ausgehe, dass dies ein Task mit niedriger Priorität sein wird. Sobald es Neuigkeiten dazu gibt, werden diese natürlich im Forum gepostet!


    Grüße,
    Teekanne

  • Also ich verstehe das Problem nicht. Der externalLoginToken ist ja eigentlich kein "LoginToken" sondern ein AuthToken. Mit diesem Token komme ich ja nicht in Travian rein oder habe Zugriff auf irgendwelche Informationen. Und der Token dient auch nicht als Ersatz für Passwörter. Wer hat denn schon Lust jedes mal den Token zu erstellen oder ihn auf dem PC zu speichern. Somit muss man bei Tools doch wieder mit Zugängen arbeiten und kann sich dann im Account über den Token authentifizieren.


    Aber er hat doch meinen AccessToken und kann sich damit einen Account unter meinem Profil anlegen?
    Das ist doch wirklich einfach zu lösen. Sollten in 2 Accounts der gleiche AccessToken auftauchen, werden beide Accounts erst mal deaktiviert und müssen sich neu authentifizieren. Dazu besorgt man sich einfach ein neues Paar Schlüssen und lässt sich den neuen AccessToken geben. Nur der echte Besitzer kann sich einen neuen AccessToken erstellen lassen. Hat sich der Besitzer 2 mal erfolgreich authentifiziert, kann man ihn "trusted" stellen. Sollte jetzt nochmal einer kommen und den Key verwenden, kann man diesen klar abweisen.
    Dazu muss man sich auch nicht jeden Tag doppelte Daten (getMapData) holen. Sollte so ein Fall eintreten, kann man sich die Daten mit dem 2. Key holen, speichern und eigentlich so lange verwenden, bis jemand kommt, der zum Zeitpunkt der letzten Doppel-Abfrage noch nicht auf der Map war. Das erkennt man ja auch an den normalen Daten, wann jemand in die Welt gekommen ist. Absolut kein Aufwand, kein Risiko und schnell gelöst. Der zusätzliche Traffic ist ein Witz. 1000 Spieler sind ca 1MB Daten (jaja ich weiß, hängt von der Anzahl der Dörfer ab)


    BTW: Es macht doch eh viel mehr Sinn, wenn jeder User (nicht Travian Spiele) in dem Tool seinen eigenen Account hat. So kann man z.B. Sitter einfacher verwalten, Spielwelten - Account Zuordnungen machen und es gibt so viele andere lustige Sachen, wie z.B. Netzwerkgrafiken o.Ä.

  • Also ich verstehe das Problem nicht. Der externalLoginToken ist ja eigentlich kein "LoginToken" sondern ein AuthToken. Mit diesem Token komme ich ja nicht in Travian rein oder habe Zugriff auf irgendwelche Informationen. Und der Token dient auch nicht als Ersatz für Passwörter. Wer hat denn schon Lust jedes mal den Token zu erstellen oder ihn auf dem PC zu speichern. Somit muss man bei Tools doch wieder mit Zugängen arbeiten und kann sich dann im Account über den Token authentifizieren.


    Aktuell kann der Account diese Authentifizierung nicht wiederrufen, also auch nicht verhindern, dass jemand anderes sich mit dessen Profil authentifiziert.

    Quote

    Aber er hat doch meinen AccessToken und kann sich damit einen Account unter meinem Profil anlegen?
    Das ist doch wirklich einfach zu lösen. Sollten in 2 Accounts der gleiche AccessToken auftauchen, werden beide Accounts erst mal deaktiviert und müssen sich neu authentifizieren.


    Du möchtest also verhindern, dass es Duals gibt? Die hätten ja in (externen) Tools durchaus mehr als einen Account.

    Quote

    Dazu besorgt man sich einfach ein neues Paar Schlüssen und lässt sich den neuen AccessToken geben. Nur der echte Besitzer kann sich einen neuen AccessToken erstellen lassen. Hat sich der Besitzer 2 mal erfolgreich authentifiziert, kann man ihn "trusted" stellen. Sollte jetzt nochmal einer kommen und den Key verwenden, kann man diesen klar abweisen.


    Der Besitzer kann mit der Zeit wechseln, zum Beispiel weil ein Dual kommt, jemand anderes für die Person weiterspielt etc. Das würde mit dem oben gennanten Verfahren verhindert werden.

    Quote

    Dazu muss man sich auch nicht jeden Tag doppelte Daten (getMapData) holen. Sollte so ein Fall eintreten, kann man sich die Daten mit dem 2. Key holen, speichern und eigentlich so lange verwenden, bis jemand kommt, der zum Zeitpunkt der letzten Doppel-Abfrage noch nicht auf der Map war.


    Du musst halt für jeden Nutzer festhalten, welchen aktuellen Schlüssel der Account zur Authentifizierung nutzt, die Anzahl an Abfragen hängt dann davon ab, wie oft sich Leute aus dem Authentifizierten Account kegeln, weil beide Duals ja das gleiche Anrecht hätten.

    Quote


    BTW: Es macht doch eh viel mehr Sinn, wenn jeder User (nicht Travian Spiele) in dem Tool seinen eigenen Account hat. So kann man z.B. Sitter einfacher verwalten, Spielwelten - Account Zuordnungen machen und es gibt so viele andere lustige Sachen, wie z.B. Netzwerkgrafiken o.Ä.


    Ja, das macht Sinn, weswegen der erste Bereich von dir so nicht geht. Ebenfalls macht es mMn keinen Sinn die Freigabe je Spieler zu machen, da dies zu viel über die Accountzusammensetzungen verrät und man dann von außen die realen Personen identifizieren könnte - so könnte ein Seitenbetreiber also z.B. nachverfolgen wo du spielst, egal welche Welt oder welcher Account es ist.

  • Hallo LordBJ,


    ich habe den Eindruck, dass du mich nicht ganz verstanden hast. Ein Dual/Multi kann sich bei Travian nicht anmelden. Im Anmeldefenster steht nichts von "Gib deinen Namen und den deiner Mitspieler ein". Ein Account gehört der Person, die ihn eröffnet hat und somit auch die Verantwortung dafür tragen muss. Wenn diese Person weiteren Personen Zugang gewährt, haftet der Inhaber für alle Aktionen, die mit diesem Account ausgeführt werden. Und genau bei diesem Punkt möchte ich ansetzen. Ein Account kann nicht einer Gruppe gehören. Ein Account kann nur einer Person und somit einem Account im externen Tool gehören. Über das externe Tool kann man so viele Möglichkeiten anbieten, Sitter/Duals/Multis "gleichberechtigt" zu machen. Aber am Ende gibt es nur einen Inhaber für einen Account; Egal ob in Travian oder im Tool.


    Ohne dich jetzt kritisieren zu wollen, stellt sich mir die Frage, wie viele Ahnung von der Entwicklung / Programmierung solcher Tools du hast. Auf der einen Seite soll alles absolut sicher sein und auf der anderen Seite soll jeder alles können. Das funktioniert ohne Einschränkungen nicht. Ein paar Beispiele.


    Jemand möchte seinen Travian-Account abgeben (Inhaberwechsel)
    Dazu kann er entweder sein Konto beim Tool löschen oder einen Button drücken, der die Verknüpfung zum Travian-Account löscht und somit seinen Travian-Account freigeben.


    Der Inhaber spielt nicht mehr / reagiert nicht mehr / ist nicht mehr erreichbar
    Also es wäre relativ einfach hier eine Lösung in das Tool einzubauen. Es erhöht geringfügig zwar das Risiko, dass einem der Account "geklaut" wird, ist aber machbar. Die andere Frage ist, ob man als Betreiber einer solchen Seite das überhaupt machen darf/soll. Sofern kein gültiger Vertrag geschlossen wurde, ist der Inhaber auch weiterhin der Inhaber und Haftbar. Daher stellt sich die Frage, ob man Dritten, u.U. auch unbefugten, überhaupt Zugriff auf Daten geben darf.


    Gegen eine Abgabe des Kontos, Travian-Accounts und aller angelegten Daten durch den Inhaber spricht absolut nichts. Ich würde dies einfach durch Eingabe des Passworts bestätigen lassen und somit gibt er, und nicht der Betreiber, die Daten weiter. Das ist auch technisch kein Hexenwerk. Man könnte auch noch ein kleines Hintertürchen offen lassen. Wenn ein Konto beim Inhaber als "Partner" hinterlegt ist/war, dann kann der Partner die Accountübernahme beantragen, sofern er eine doppelte Authentifizierung erfolgreich ausführen kann und der Inhaber auf eine E-Mail innerhalb einer bestimmten Zeit nicht antwortet. Die Frage bleibt aber, ob man das machen darf/soll.


    Quote

    Ebenfalls macht es mMn keinen Sinn die Freigabe je Spieler zu machen, da dies zu viel über die Accountzusammensetzungen verrät und man dann von außen die realen Personen identifizieren könnte - so könnte ein Seitenbetreiber also z.B. nachverfolgen wo du spielst, egal welche Welt oder welcher Account es ist.


    Ok, das verrät mir, dass du keine großen Erfahrungen im Bereich der Programmierung hast. Mir fallen auf der Stelle so viele Möglichkeiten ein, wie man noch so viel mehr machen könnte. Und das ohne dass der Spieler es merkt. Aber genau das ist der Punkt. Entweder man vertraut dem Betreiber und gibt ihm seine Daten. Oder man vertraut ihm nicht und schreibt sich das Tool selber...
    Was wohl Travian so alles über mich weiß :confused:


    Fakt ist, dass Travian kein Twitter oder Facebook ist. Die Funktion ist zwar sehr schlicht, aber ist zu gebrauchen. Und ich bin mir sicher, dass irgendwann noch ein Update kommt, wo man sehen kann, welche Webseite mit meinem Account verknüpft ist und ich diese Verknüpfung löschen kann. Aber das ist bei der aktuell verwendeten Technik nicht möglich. Dazu bräuchte Travian eine Art "LiveAccessApi" mit der die Anfragen direkt beantworten werden können.


    Viel besser fände ich es ja, wenn man über die API Daten aus dem Account ziehen kann. Z.B. welche Truppen vorhanden sind, wie die Produktion ist usw. Damit könnte man dann mal arbeiten :D

  • Also ich verstehe das Problem nicht. Der externalLoginToken ist ja eigentlich kein "LoginToken" sondern ein AuthToken. Mit diesem Token komme ich ja nicht in Travian rein oder habe Zugriff auf irgendwelche Informationen. Und der Token dient auch nicht als Ersatz für Passwörter. Wer hat denn schon Lust jedes mal den Token zu erstellen oder ihn auf dem PC zu speichern. Somit muss man bei Tools doch wieder mit Zugängen arbeiten und kann sich dann im Account über den Token authentifizieren.


    Wie ein Entwickler den externalLoginToken verwendet ist natürlich ihm überlassen. Der von dir hier skizzierte Weg ist, meiner Meinung nach und bei den aktuellen Gegebenheiten, einer der sinnvollsten Varianten.


    Aber er hat doch meinen AccessToken und kann sich damit einen Account unter meinem Profil anlegen?
    Das ist doch wirklich einfach zu lösen. Sollten in 2 Accounts der gleiche AccessToken auftauchen, werden beide Accounts erst mal deaktiviert und müssen sich neu authentifizieren. Dazu besorgt man sich einfach ein neues Paar Schlüssen und lässt sich den neuen AccessToken geben.


    Prinzipiell ist das natürlich eine Möglichkeit, wobei diese eigentlich nicht so schön ist, bedenke nämlich, dass es bei der Key - Erstellung das Feld "public" gibt. Wenn es dann mal eine Toolliste (gehen wir mal davon aus, dass die PublicSiteKeys mit veröffentlicht werden) gibt und jedes mal ein neuer Key erstellt werden würde, würde dies bedeuten, dass Tools mehrfach vorkommen und demnach nicht klar ist, welcher der aktuell gültige SiteKey ist.


    Ein Account gehört der Person, die ihn eröffnet hat und somit auch die Verantwortung dafür tragen muss. Wenn diese Person weiteren Personen Zugang gewährt, haftet der Inhaber für alle Aktionen, die mit diesem Account ausgeführt werden. Und genau bei diesem Punkt möchte ich ansetzen. Ein Account kann nicht einer Gruppe gehören. Ein Account kann nur einer Person und somit einem Account im externen Tool gehören. Über das externe Tool kann man so viele Möglichkeiten anbieten, Sitter/Duals/Multis "gleichberechtigt" zu machen. Aber am Ende gibt es nur einen Inhaber für einen Account; Egal ob in Travian oder im Tool.


    Hier gilt ebenfalls wieder: Es kommt auf die Entwicklung des Tools an. Wenn ich bei der Entwicklung Sitter/Duals/mehrere Welten berücksichtige, dann dürfte das kein Problem darstellen. Es spricht ja Beispielsweise nichts dagegen, dass ich mein Userkonzept so aufbaue, dass ich erstmal gar keine Verknüpfung zum Travian/Welt-Account habe. Eine Zuordnung kann dann ja auf verschiedenste Weise passieren (per Token oder per Rechtezuweisung durch xyz oder ...).



    Viel besser fände ich es ja, wenn man über die API Daten aus dem Account ziehen kann. Z.B. welche Truppen vorhanden sind, wie die Produktion ist usw. Damit könnte man dann mal arbeiten :D


    Ich glaube das würden sich viele wünschen, wäre aber auch zu Missbrauchszwecken sehr nützlich.



    Grüße,
    Teekanne

  • Quote

    Hier gilt ebenfalls wieder: Es kommt auf die Entwicklung des Tools an.


    Damit fasst du den Inhalt meiner Aussage schon zusammen.


    Eine LiveApi ist eigentlich nicht sooo schwer. Bei all meinen Ausführungen ist zu erkennen, dass mir die Sicherheit sehr wichtig ist. Auch in diesem Sinne, finde ich folgenden Ansatz gut.


    - User holt sich PublicKey und erstellt damit einen RequestToken
    - Betreiber sendet mit diesem RequestToken einmalig eine Ingame-Anfrage über die API
    - User sieht die Anfrage und die angefragten Rechte*
    - User kann die Anfrage annehmen oder ablehnen. Wurde abgelehnt, kann mit dem RequestToken keine neue Anfrage geschickt werden. (Spam, Fishing o.Ä.)
    - User kann aus der App Liste einzelne Genehmigungen jederzeit löschen und Zugriff direkt unterbinden


    *Wie genau man die Rechtevergabe macht, läge dann an Travian. Das könnte man sogar so detailliert machen, dass eine App lediglich Zugriff auf Kampfberichte hat (Kb-Parser) oder nur die Produktion auslesen darf. Wichtig ist dabei nur, dass der User erkennen und verstehen kann, welche Rechte er hier vergibt.

  • Hallo SteiniKeule,


    die technische Machbarkeit wird sicher niemand in Frage stellen. Technisch ist so gut wie alles umsetzbar.


    Trotzdem könnte eine solche API einiges an Problemen mit sich bringen. Auch wenn der User den Zugriff bestätigen muss bzw. bestätigt muss dies nicht unbedingt bedeuten das Verstanden wurde, was genau alles nun übertragen wird oder werden kann. Wenn der User die Daten händisch in ein z.B. TruppenTool eingeben muss, ist das ein bewusster Arbeitsschritt den er tätigt und ist (bzw. sollte) sich im klaren was nun für Daten einem Tool anvertraut wurde.


    Weiteres besteht trotz einer solchen Überprüfung die Möglichkeit des Missbrauchs auf die ich nicht genauer eingehen möchte.


    Zusammengefasst: Ich gehe nicht davon aus, dass es eine solche API, zu mindestens in naher Zukunft, geben wird.


    Die aktuelle API bietet genügend Informationen an mit denen man arbeiten kann, alles weitere muss der Spieler, sofern er das möchte und es von einem Tool benötigt wird, selbständig ergänzen.


    Grüße,
    Teekanne

  • Ein Account gehört der Person, die ihn eröffnet hat und somit auch die Verantwortung dafür tragen muss. Wenn diese Person weiteren Personen Zugang gewährt, haftet der Inhaber für alle Aktionen, die mit diesem Account ausgeführt werden. Und genau bei diesem Punkt möchte ich ansetzen.


    Ein Account gehört den Personen die ihn spielen, dass da einer möglicherweise die eMail stellt, die im Zweifel Verantwortung übernimmt ist außen vor. Worum es hier doch geht, ist, dass du verhindern willst, dass mehrere Personen sich für einen Account authentifizieren können, das aber aus meiner Perspektive vollständig normal und wünschenswert ist.

    Quote

    Ein Account kann nicht einer Gruppe gehören. Ein Account kann nur einer Person und somit einem Account im externen Tool gehören.


    Nein.

    Quote

    Über das externe Tool kann man so viele Möglichkeiten anbieten, Sitter/Duals/Multis "gleichberechtigt" zu machen. Aber am Ende gibt es nur einen Inhaber für einen Account; Egal ob in Travian oder im Tool.


    Im Tool ist ein Account für sich selbst verantwortlich, klar. Allerdings ist ein Account in einem beliebigen Tool nicht gleichbedeutend mit einem Account in Travian. Deine Ansicht, dass ein Spielaccount zwingend eine Person als Besitzer haben muss teile ich nicht, dass dieser Account-"Besitzer" dann auch alleinige Kontrolle über genutzte Tools haben soll halte ich dagegen für absurd.

    Quote

    Auf der einen Seite soll alles absolut sicher sein und auf der anderen Seite soll jeder alles können. Das funktioniert ohne Einschränkungen nicht.


    Ich habe ja bereits Einschränkungen vorgeschlagen, die gangbar sind, ohne dass ein Tool plötzlich versuchen muss verschiedene Spieler eines Accounts gegeneinander zu priorisieren - wie soll jemand die 3 Personen unterscheiden, die immer wieder passende Tokens eingeben?

    Quote

    Jemand möchte seinen Travian-Account abgeben (Inhaberwechsel)
    Dazu kann er entweder sein Konto beim Tool löschen oder einen Button drücken, der die Verknüpfung zum Travian-Account löscht und somit seinen Travian-Account freigeben.


    Sekunde, es gibt keine Verknüpfung zu einem Travian-Account, sondern zu einem Spieler, welcher durchaus durch mehrere Travian-Accounts gespielt werden könnte. Löscht die Person die einen Account abgibt die Freigabe nicht, gibt es deinem Vorschlag nach keine Möglichkeit für den neuen Besitzer dieses Tool zu verwenden - sein Token ist gesperrt und der andere ist bereits (mehrfach) validiert worden und damit deiner Beschreibung nach immun gegen die Resetversuche.

    Quote

    Der Inhaber spielt nicht mehr / reagiert nicht mehr / ist nicht mehr erreichbar
    Also es wäre relativ einfach hier eine Lösung in das Tool einzubauen. Es erhöht geringfügig zwar das Risiko, dass einem der Account "geklaut" wird, ist aber machbar. Die andere Frage ist, ob man als Betreiber einer solchen Seite das überhaupt machen darf/soll. Sofern kein gültiger Vertrag geschlossen wurde, ist der Inhaber auch weiterhin der Inhaber und Haftbar. Daher stellt sich die Frage, ob man Dritten, u.U. auch unbefugten, überhaupt Zugriff auf Daten geben darf.


    Der Inhaber eines Accounts ist für den Betreiber einer externen Seite völlig unerheblich. Zum Einen kann nicht kontrolliert werden, ob hier wirklich ein Spieler des Accounts aktiv ist, noch kann bestimmt werden welcher Spieler das ist - die Frage wem der Accountbesitz zuzuordnen ist stellt sich damit nicht einmal.

    Quote

    Gegen eine Abgabe des Kontos, Travian-Accounts und aller angelegten Daten durch den Inhaber spricht absolut nichts. Ich würde dies einfach durch Eingabe des Passworts bestätigen lassen und somit gibt er, und nicht der Betreiber, die Daten weiter. Das ist auch technisch kein Hexenwerk. Man könnte auch noch ein kleines Hintertürchen offen lassen. Wenn ein Konto beim Inhaber als "Partner" hinterlegt ist/war, dann kann der Partner die Accountübernahme beantragen, sofern er eine doppelte Authentifizierung erfolgreich ausführen kann und der Inhaber auf eine E-Mail innerhalb einer bestimmten Zeit nicht antwortet. Die Frage bleibt aber, ob man das machen darf/soll.


    Noch einmal, es gibt in der vorliegenden API keine möglichkeit die Spieler zu unterscheiden. Bestimmen wer dort Partner ist/war und wer der "Besitzer" ist, ist nicht machbar.

    Quote

    Mir fallen auf der Stelle so viele Möglichkeiten ein, wie man noch so viel mehr machen könnte. Und das ohne dass der Spieler es merkt. Aber genau das ist der Punkt. Entweder man vertraut dem Betreiber und gibt ihm seine Daten. Oder man vertraut ihm nicht und schreibt sich das Tool selber...


    Es geht um die bestehende API, ich habe mich nicht zu dem geäußert, was man später hinzufügen könnte im Bezug auf Funktionalität, ich habe nur einige Bedenken im Bezug auf die Art und Weise, wie die Auth-Keys nicht durch bekannte Spieler(i.e. mit eindeutig vorhandenem Accountzugriff) entfernt werden können.

    Quote

    Dazu bräuchte Travian eine Art "LiveAccessApi" mit der die Anfragen direkt beantworten werden können.


    Nicht wirklich, lies mal meinen Vorschlag, das geht durchaus anders und so gut wie mit den gegebenen Bordmitteln.