Posts by LordBJ#DE

    Es geht um genau diese Tage, es ist doch spielentscheident, dass man zumindest einen "brauchbaren" Start hat, landet man als König nur bei inaktiven Statthaltern oder als Statthalter bei einem inaktiven König ist dieser brauchbare Start wesentlich weniger wahrscheinlich.
    In meinem Fall hätte ich z.B. gerne Algareb in der Nähe gehabt, für den müssen wir aber jetzt nicht nur das siedeln durchführen, sondern auch einen Abnehmer für das Startdorf finden, der sinnvolle Preise zahlt.

    Das fände ich auch schön, ich hätte da nen par Leute gehabt, die ich gern im Gebiet haben würde...
    Könnte aber für größere, organisierte Gruppen zu viele Vorteile geben.

    Generell habe ich mir zunächst folgende Aufgaben gesetzt:
    - Bereitstellen von Oasen für alle Untertanen
    - Sicherung der Dörfer meiner Untertanen


    Das ist in etwa das, was früher ein Allyleiter getan hätte.

    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).

    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`)
    );

    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 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)

    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.

    Ich muss zugeben, ich habe meinen inzwischen (aus eigener Dummheit) bereits zwei mal wiederbeleben müssen, das war zwar teuer aber es ging noch. Was mir da wichtiger wäre ist den Menge an Regeneration dezent zu erhöhen(15 statt 10 Basis z.B.) damit die Ausfallzeiten deutlich geringer sind.