Libelektra: Sign in/Register fails

Is fixed with the latest commit of #1213.

Does not work for me, it seems like the additional arguments are ignored.

Btw. the login does not work (connection issues). First I thought the backend is down, but the conversion works?

Does not work for me, it seems like the additional arguments are ignored.

Did you enter % % or format=% %? The latter works.

Btw. the login does not work (connection issues). First I thought the backend is down, but the conversion works?

I noticed it one time too already, but I couldn't make out the issue. I think it has to do with backend crashes. If you logout and login again, it works interestingly.

Thank you, my fault. I missed format.

But I am still not able to login... ;-(

Does the browser console say something / do you get a non-200 response?

I think we should be able to solve such problems with browser console.

The error message is:

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.

The server console says:

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

and then:

19:44:27.714 Error: response.data is null
[213]</module.exports/this.doLogin/<@https://www.libelektra.org/assets/js/application.js:89460:17
processQueue@https://www.libelektra.org/assets/js/application.js:40852:28
scheduleProcessQueue/<@https://www.libelektra.org/assets/js/application.js:40868:27
$RootScopeProvider/this.$get</Scope.prototype.$eval@https://www.libelektra.org/assets/js/application.js:42159:16
$RootScopeProvider/this.$get</Scope.prototype.$digest@https://www.libelektra.org/assets/js/application.js:41973:15
$RootScopeProvider/this.$get</Scope.prototype.$apply@https://www.libelektra.org/assets/js/application.js:42267:13
done@https://www.libelektra.org/assets/js/application.js:36248:36
completeRequest@https://www.libelektra.org/assets/js/application.js:36457:7
createHttpBackend/</requestError@https://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

That means the request is not returning a 200 status. Can you look what the network request is returning? I've an idea what the problem could be, but I need a confirmation for it.

500 Internal Server Error, so not really helpful? Here the full requests/responses:

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>

Btw. did you already profile why loading the page sometimes takes so long?

Btw. why is charset=iso-8859-1 in use for the restapi?

And why is something loaded from gravatar.com? (Is this from asciinema.org? Can we embed the asciinema?)

(reopen for login issue)

Btw. did you already profile why loading the page sometimes takes so long?

Depends on where you experienced long loads. On the details/edit page, it is quite normal because we have a significant amount of plugins (/variants) enabled and the export takes time. That's also why I said we should disable some..

Btw. why is charset=iso-8859-1 in use for the restapi?

Where did you find this? To me it seems like cppcms is using the charset that fits best the needs if none is given explicitely. E.g. https://restapi.libelektra.org/database?filter=a&filterby=all&offset=0&rows=10&sort=asc&sortby=key uses us-ascii (never heard of that one before).

Edit: Ok found it in your snippet above. The same requests gives us-ascii on my system. I wouldn't consider an issue as long as the browser and the API understand each other properly?

And why is something loaded from gravatar.com? (Is this from asciinema.org? Can we embed the asciinema?)

Yes it is from the asciinema and the asciinema is already embedded?!

The 500 error above looks very much like a downtime of the backend for me (so it is from the apache). Otherwise there should be a X-Powered-By:CppCMS/1.0.5 in the response.

That's also why I said we should disable some..

Deactivate completely?

Where did you find this?

In the requests/responses between frontend and backend.

using the charset that fits best the needs if none is given explicitely

Why not give UTF-8 or us-ascii explicitely?

I wouldn't consider an issue as long as the browser and the API understand each other properly?

The REST API should also be a standalone feature.

Yes it is from the asciinema and the asciinema is already embedded?!

I mean delievered from our apache.

The 500 error above looks very much like a downtime of the backend for me

So the backend crashes when I try to login?

Deactivate completely?

Yes. You can create some test snippets and look yourself, often the formats are very, very similar, because the format is the same. I don't think we need them twice then. (Only issue is that users won't find a plugin/lens for their format then probably...)

Why not give UTF-8 or us-ascii explicitely?

I can see if adding UTF-8 in my helper is sufficient.

The REST API should also be a standalone feature.

Sure, if the browser and the front-end does, then curl and other tools will do also.

I mean delievered from our apache.

Don't think they offer a download, etc.

So the backend crashes when I try to login?

No, I would say it wasn't only at this time for some other reason. I've tried quite some things already, but I cannot reproduce what you got.

Only issue is that users won't find a plugin/lens for their format then probably

Yeah, unfortunately this might be a major issue (for people that need a specific plugin). What we could do is to not show all of them after snippet uploading. But that seems like a quite complicated change in frontend and backend (and which ones to select?).

Don't think they offer a download, etc.

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

No, I would say it wasn't only at this time for some other reason. I've tried quite some things already, but I cannot reproduce what you got.

I tried it quite often already. Registration seems to be down now, too. (like login: connection issues)

Sorry but then you seem to have an issue on your side, because both works properly without me changing anything. My guess is a script blocker - again.

I tried to remove all plugins with firefox and tried 3 other different browsers (chromium, tor browser, konqueror), always the same. I am in the TU network, so I doubt it is a connection problem, my colleague just downloaded an ubuntu ISO in some minutes ;)

You are right, it is no connection issue. The sha256_encrypt function fails for some inputs, I'll fix it.

So my passwords were too long :see_no_evil: ?

Please also try to give better feedback for such errors.

No it was not too long, something else was broken, you'll see it in the PR in a moment.

How did it work for you?

Btw. should we also push the user database to a private repo? Actually we could make a backup of other things in a private repo, too.

It worked for some passwords, but not for others. Blubblub123 worked for example while NotSecure1 didn't.

I tried ch1iDoeGhoo9VhohJ1oh3phie9PhesaiSh maybe you should add longer passwords for the unit tests, too. (you can use this password for the test if you want)

Much better, login and changing of password works like a charm now!

I'll merge when the unit tests are ready.

Had to delete your account as you might noticed because hashes were broken, but shouldn't happen in the future anymore. :+1:

Yeah, is already recreated ;)

shouldn't happen in the future anymore

It is okay till release of the homepage ;)

Btw. please submit the apache config and so on to our snippet service. We should really add much more there!