SSL Unterstützung in unterschiedlichen Szenarios

Für SSL werden zwei Unterschiedliche Szenarios unterstützt:

  • Standardmäßig wird das Protokoll der Seite auch für die Requests zum Server verwendet. Daher wird die Seite mit “https” aufgerufen werden auch “https” Requests zum Server gesendet
  • Unterscheidet sich die URL neben dem Protokoll können beide URLs angegeben werden. Dies ist beispielsweise beim Anbieter all-inkl der Fall. Dort wird “https://ssl-account.com/%domain%” für SSL Aufrufe verwendet

Beispiel zur Konfiguration verschiedener URLs für “http” und “https”:

return [
    'dragonjsonserver' => [
        'serverurl' => [
            'http'  => '%httpurl%',
            'https' => '%httpsurl%',
        ],
    ],
];

Wenn man die Konfiguration aus PHP heraus an das JavaScript übergibt muss man beachten, dass die “serverurl” sowohl ein String als auch ein Array sein kann:

<script>
    <?php if (is_array($this->serverurl)) { ?>
    var serverurl = JSON.parse('<?= \Zend\Json\Encoder::encode($this->serverurl) ?>');
    <?php } else { ?>
    var serverurl = '<?= $this->serverurl ?>';
    <?php } ?>
</script>

Der JavaScript Connector unterscheidet dann selbst anhand des Protokolls der aktuellen URL welche der ServerURLs verwenden werden muss.

Betakeys für Accounts und Sessiondaten abfragen

Die Accounterweiterung hat zwei neue Features bekommen:

  • Mit einer Konfiguration ist es nun möglich die Abfrage von Betakeys bei der Accounterstellung zu aktivieren.
    Auf diese Weise lässt sich die Accounterstellung kontrollieren (vor allem vor einem Release innerhalb einer Betaphase) und nachvollziehen welcher Account mit welchem Betakey erstellt wurde
  • Die Daten einer Session können nun vom Client abgefragt werden.
    Daher kann ein Client der nicht direkt den Account selbst erstellt oder authentifiziert sondern durch eine Weiterleitung einen Sessionhash bekommen hat auf die Daten der Session zugreifen

Serverseitige Unterstützung mehrerer Sprachen

Ein Backend das nur Daten bekommt und Daten ausliefert benötigt eigentlich keine Unterstützung mehrerer Sprachen. Es gibt allerdings eine Ausnahme: Das Versenden von E-Mails.

Aus diesem Grund wurden die I18n Erweiterung hinzugefügt die Einstellungen (Fallbacksprache “en”, Servicealias “translator”) vornimmt und es dem Client ermöglicht die unterstützen Sprachen abzufragen. Dadurch konnte die Emailaddress Erweiterung geändert werden und unterstützt nun mehrere Sprachen für die E-Mails von Passwort vergessen und Validierungsanfragen.

Erweiterung des JavaScript Connectors

Ich habe den JavaScript Connector analysiert und optimiert. Vor allem folgende Punkte wurden überarbeitet:

  • Die Parameterliste von “DragonJsonServer.Request” ist nun variabler. Sie erlaubt es nun die Params für den Request wegzulassen
  • Clientmessages werden nur noch vom Server abfragt wenn der Client mindestens für einen Key Callbacks definiert hat
  • Der Client kann dem Server die Keys der Clientmessages liefern für die Callbacks definiert sind sodass der Server nur diese Keys sammeln muss
  • Success/Error Callbacks der Sendoptionen und der Clientoptionen werden nun immer aufgerufen wenn sie definiert sind

Des Weiteren hab ich Beispiele für die Verwendung der variablen Parameterlisten in die API Dokumentation der beiden Klassen aufgenommen und die Setter für Defaultparameter und Clientmessage Callbacks erweitert.

DragonJsonServer 2.x auf Github verfügbar

Da die Arbeit am Framework noch recht flexible voran geht habe ich mich vorerst gegen eine Vergabe von Versionsnummern und damit der Erstellung von Branches und Tags entschieden. Änderungen am Kern des Frameworks sind nicht ausgeschlossen und der Overhead einer Versionierung samt Changelogs wäre etwas überdimensioniert für die noch unerprobte Version. Somit werde ich die Version fortlaufend anpassen und nur größere Änderungen mit eigenen Posts ansprechen.

Neue Homepage für DragonJsonServer 2.x online

In der ersten Version hatte ich mich dazu entschieden die Homepage samt Neuigkeiten, Dokumentation und Changelog in das Framework selbst einzubetten. Dies hatte Vorteile: Alle Inhalte konnten direkt mit dem Framework ausgeliefert und aktualisiert werden. Aber auch Nachteile: Das Framework wirkte sehr aufgebläht, ist es doch ein API Framework für einen Server ohne eigenes Frontend. Daher habe ich mich nun entschieden die Homepage vom Framework zu trennen und diese mit WordPress aufzusetzen.