Libelektra: Anmelden/Registrieren schlägt fehl

Wird mit dem neuesten Commit von #1213 behoben.

Funktioniert bei mir nicht, anscheinend werden die zusätzlichen Argumente ignoriert.

Übrigens. die Anmeldung funktioniert nicht (Verbindungsprobleme). Zuerst dachte ich, das Backend ist ausgefallen, aber die Konvertierung funktioniert?

Funktioniert bei mir nicht, anscheinend werden die zusätzlichen Argumente ignoriert.

Haben Sie % % oder format=% % eingegeben? Letzteres funktioniert.

Übrigens. die Anmeldung funktioniert nicht (Verbindungsprobleme). Zuerst dachte ich, das Backend ist ausgefallen, aber die Konvertierung funktioniert?

Mir ist es auch schon einmal aufgefallen, aber ich konnte das Problem nicht erkennen. Ich denke, es hat mit Backend-Abstürzen zu tun. Wenn Sie sich abmelden und erneut anmelden, funktioniert es interessanterweise.

Danke, meine Schuld. Ich habe format verpasst.

Aber ich kann mich immer noch nicht einloggen... ;-(

Sagt die Browserkonsole etwas / erhalten Sie eine Antwort von nicht 200?

Ich denke, wir sollten in der Lage sein, solche Probleme mit der Browser-Konsole zu lösen.

Die Fehlermeldung lautet:

Connection issues
It seems as if the service is not reachable. This may be either due to a downtime of the service or because of your internet connection.

Die Serverkonsole sagt:

19:44:27.712 [#][INFO]  Failed login! ____ [application.js:40852:28]1 application.js:258:21

und dann:

19:44:27.714 Error: response.data is null
[213]</module.exports/this.doLogin/<<strong i="13">@https</strong>://www.libelektra.org/assets/js/application.js:89460:17
processQueue<strong i="14">@https</strong>://www.libelektra.org/assets/js/application.js:40852:28
scheduleProcessQueue/<<strong i="15">@https</strong>://www.libelektra.org/assets/js/application.js:40868:27
$RootScopeProvider/this.$get</Scope.prototype.$eval<strong i="16">@https</strong>://www.libelektra.org/assets/js/application.js:42159:16
$RootScopeProvider/this.$get</Scope.prototype.$digest<strong i="17">@https</strong>://www.libelektra.org/assets/js/application.js:41973:15
$RootScopeProvider/this.$get</Scope.prototype.$apply<strong i="18">@https</strong>://www.libelektra.org/assets/js/application.js:42267:13
done<strong i="19">@https</strong>://www.libelektra.org/assets/js/application.js:36248:36
completeRequest<strong i="20">@https</strong>://www.libelektra.org/assets/js/application.js:36457:7
createHttpBackend/</requestError<strong i="21">@https</strong>://www.libelektra.org/assets/js/application.js:36395:9
1 application.js:38356:18
consoleLog/<() application.js:38356
$ExceptionHandlerProvider/this.$get</<() application.js:34879
processQueue() application.js:40860
scheduleProcessQueue/<() application.js:40868
$RootScopeProvider/this.$get</Scope.prototype.$eval() application.js:42159
$RootScopeProvider/this.$get</Scope.prototype.$digest() application.js:41973
$RootScopeProvider/this.$get</Scope.prototype.$apply() application.js:42267
done() application.js:36248
completeRequest() application.js:36457
createHttpBackend/</requestError() application.js:36395

Das bedeutet, dass die Anforderung keinen 200-Status zurückgibt. Können Sie sehen, was die Netzwerkanfrage zurückgibt? Ich habe eine Idee, was das Problem sein könnte, aber ich brauche eine Bestätigung dafür.

500 Internal Server Error, also nicht wirklich hilfreich? Hier die vollständigen Anfragen/Antworten:

curl 'https://restapi.libelektra.org/auth' -X OPTIONS -H 'Host: restapi.libelektra.org' -H 'User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:49.0) Gecko/20100101 Firefox/49.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'DNT: 1' -H 'Access-Control-Request-Method: POST' -H 'Access-Control-Request-Headers: content-type' -H 'Origin: https://www.libelektra.org' -H 'Connection: keep-alive'

HTTP/1.1 200 OK
Date: Mon, 19 Dec 2016 19:39:05 GMT
Server: Apache/2.4.10 (Debian)
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Allow-Methods: POST,OPTIONS
Access-Control-Allow-Origin: *
Allow: POST,OPTIONS
X-Powered-By: CppCMS/1.0.5
Content-Length: 15
Connection: close
Content-Type: application/json
{"status":"OK"}

curl 'https://restapi.libelektra.org/auth' -H 'Host: restapi.libelektra.org' -H 'User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:49.0) Gecko/20100101 Firefox/49.0' -H 'Accept: application/json, text/plain, */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'DNT: 1' -H 'Content-Length: 64' -H 'Content-Type: application/json;charset=utf-8' -H 'Origin: https://www.libelektra.org' -H 'Connection: keep-alive'

HTTP/1.1 500 Internal Server Error
Date: Mon, 19 Dec 2016 19:39:05 GMT
Server: Apache/2.4.10 (Debian)
Content-Length: 626
Connection: close
Content-Type: text/html; charset=iso-8859-1

curl 'https://www.libelektra.org/templates/notification.html' -H 'Host: www.libelektra.org' -H 'User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:49.0) Gecko/20100101 Firefox/49.0' -H 'Accept: application/json, text/plain, */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'DNT: 1' -H 'Connection: keep-alive'

<div class="ui-notification">
    <div class="alert" ng-class="{'alert-success': t === 's', 'alert-danger': t === 'e',
            'alert-warning': t === 'w', 'alert-info': t === 'i'}" style="margin-bottom:0px;">
        <div class="ui-notification-icon">
            <span class="fa fa-check-circle-o" ng-show="t === 's'"></span>
            <span class="fa fa-times-circle" ng-show="t === 'e'"></span>
            <span class="fa fa-info-circle" ng-show="t === 'i'"></span>
            <span class="fa fa-exclamation-circle" ng-show="t === 'w'"></span>
        </div>
        <h4 class="ui-notification-title" ng-show="title">{{ title | translate }}</h4>
        <div class="ui-notification-text">{{ message | translate }}</div>
    </div>
</div>

Übrigens. hast du schon profiliert warum das laden der seite manchmal so lange dauert?

Übrigens. warum wird charset=iso-8859-1 für das restapi verwendet?

Und warum wird etwas von gravatar.com geladen? (Ist das von asciinema.org? Können wir das Asciinema einbetten?)

(für Login-Problem wieder öffnen)

Übrigens. hast du schon profiliert warum das laden der seite manchmal so lange dauert?

Hängt davon ab, wo Sie lange Lasten erlebt haben. Auf der Detail-/Bearbeitungsseite ist dies ganz normal, da wir eine beträchtliche Anzahl von Plugins (/variants) aktiviert haben und der Export einige Zeit in Anspruch nimmt. Deshalb habe ich auch gesagt, wir sollten einige deaktivieren..

Übrigens. warum wird charset=iso-8859-1 für das restapi verwendet?

Wo hast du das gefunden? Für mich sieht es so aus, als ob cppcms den Zeichensatz verwendet, der den Anforderungen am besten entspricht, wenn keiner explizit angegeben wird. ZB https://restapi.libelektra.org/database?filter=a&filterby=all&offset=0&rows=10&sort=asc&sortby=key verwendet us-ascii (habe noch nie davon gehört).

Edit: Ok, habe es in deinem Snippet oben gefunden. Die gleichen Anfragen geben us-ascii auf meinem System. Ich würde kein Problem in Betracht ziehen, solange der Browser und die API sich richtig verstehen?

Und warum wird etwas von gravatar.com geladen? (Ist das von asciinema.org? Können wir das Asciinema einbetten?)

Ja, es ist vom Asciinema und das Asciinema ist bereits eingebettet?!

Der obige 500-Fehler sieht für mich sehr nach einer Ausfallzeit des Backends aus (also vom Apache). Andernfalls sollte die Antwort ein X-Powered-By:CppCMS/1.0.5 .

Deshalb habe ich auch gesagt, wir sollten einige deaktivieren..

Komplett deaktivieren?

Wo hast du das gefunden?

In den Anfragen/Antworten zwischen Frontend und Backend.

Verwenden des Zeichensatzes, der den Anforderungen am besten entspricht, wenn keiner explizit angegeben wird

Warum nicht UTF-8 oder us-ascii explizit angeben?

Ich würde kein Problem in Betracht ziehen, solange der Browser und die API sich richtig verstehen?

Die REST-API sollte auch eine eigenständige Funktion sein.

Ja, es ist vom Asciinema und das Asciinema ist bereits eingebettet?!

Ich meine, von unserem Apache geliefert.

Der obige 500-Fehler sieht für mich sehr nach einer Ausfallzeit des Backends aus

Also stürzt das Backend ab, wenn ich versuche mich anzumelden?

Komplett deaktivieren?

Jawohl. Sie können einige Testschnipsel erstellen und selbst nachsehen, oft sind die Formate sehr, sehr ähnlich, weil das Format gleich ist. Ich glaube, wir brauchen sie dann nicht zweimal. (Das einzige Problem ist, dass Benutzer dann wahrscheinlich kein Plugin/Objektiv für ihr Format finden...)

Warum nicht UTF-8 oder us-ascii explizit angeben?

Ich kann sehen, ob das Hinzufügen von UTF-8 in meinem Helfer ausreicht.

Die REST-API sollte auch eine eigenständige Funktion sein.

Sicher, wenn der Browser und das Frontend dies tun, dann tun curl und andere Tools auch.

Ich meine, von unserem Apache geliefert.

Denke nicht, dass sie einen Download usw. anbieten.

Also stürzt das Backend ab, wenn ich versuche mich anzumelden?

Nein, ich würde sagen, es war nicht nur zu dieser Zeit aus einem anderen Grund. Ich habe schon einiges ausprobiert, aber ich kann nicht reproduzieren, was Sie bekommen haben.

Das einzige Problem ist, dass Benutzer dann wahrscheinlich kein Plugin/Objektiv für ihr Format finden

Ja, leider kann dies ein großes Problem sein (für Leute, die ein bestimmtes Plugin benötigen). Was wir tun könnten, ist, nach dem Hochladen des Snippets nicht alle anzuzeigen. Aber das scheint eine ziemlich komplizierte Änderung im Frontend und Backend zu sein (und welche soll man auswählen?).

Denke nicht, dass sie einen Download usw. anbieten.

http://blog.asciinema.org/post/self-hosting/

Nein, ich würde sagen, es war nicht nur zu dieser Zeit aus einem anderen Grund. Ich habe schon einiges ausprobiert, aber ich kann nicht reproduzieren, was Sie bekommen haben.

Habe ich schon öfter probiert. Die Registrierung scheint jetzt auch unten zu sein. (wie Login: Verbindungsprobleme)

Entschuldigung, aber dann scheinen Sie ein Problem auf Ihrer Seite zu haben, denn beides funktioniert einwandfrei, ohne dass ich etwas geändert habe. Meine Vermutung ist ein Skriptblocker - wieder.

Ich habe versucht, alle Plugins mit Firefox zu entfernen und 3 andere verschiedene Browser (Chromium, Tor-Browser, Konqueror) ausprobiert, immer gleich. Ich bin im TU-Netzwerk, daher bezweifle ich, dass es sich um ein Verbindungsproblem handelt, mein Kollege hat gerade in wenigen Minuten eine Ubuntu-ISO heruntergeladen ;)

Du hast Recht, es ist kein Verbindungsproblem. Die Funktion sha256_encrypt schlägt bei einigen Eingaben fehl, ich werde es beheben.

Also waren meine Passwörter zu lang :see_no_evil: ?

Bitte versuchen Sie auch, bei solchen Fehlern ein besseres Feedback zu geben.

Nein, es war nicht zu lange, da war noch was kaputt, ihr seht es gleich in der PR.

Wie hat es bei dir funktioniert?

Übrigens. sollten wir die Benutzerdatenbank auch in ein privates Repository verschieben? Eigentlich könnten wir auch ein Backup von anderen Dingen in einem privaten Repo machen.

Bei einigen Passwörtern hat es funktioniert, bei anderen nicht. Blubblub123 hat zum Beispiel funktioniert, während NotSecure1 nicht funktioniert hat.

Ich habe es mit ch1iDoeGhoo9VhohJ1oh3phie9PhesaiSh versucht, vielleicht sollten Sie auch längere Passwörter für die Unit-Tests hinzufügen. (Sie können dieses Passwort für den Test verwenden, wenn Sie möchten)

Viel besser, das Einloggen und Ändern des Passworts funktioniert jetzt wie ein Zauber!

Ich werde zusammenführen, wenn die Komponententests fertig sind.

Musste Ihr Konto löschen, wie Sie vielleicht bemerkt haben, weil Hashes kaputt waren, aber in Zukunft nicht mehr passieren sollte. :+1:

Ja, ist schon neu erstellt ;)

sollte in Zukunft nicht mehr passieren

Bis zur Veröffentlichung der Homepage ist es ok ;)

Übrigens. Bitte senden Sie die Apache-Konfiguration usw. an unseren Snippet-Service. Da sollten wir wirklich noch viel mehr hinzufügen!