Bug : Oops something went wrong on Login (and a dirty fix)

[jacquarg]

Durring login, when the user enter its valid credentials, the popup show a red message 'Oops something went wrong, you should relaod the page'.

After some investigation, it appears that the response from the server to the request /login , is troncated, and then, not a valid JSON.

I am not a PHP expert, so I don't know where the problem come from. But, I found a quick and totally dirty fix which seems to work for my installation:
I just add a line of code with print_r($response); just there : https://github.com/flarum/core/blob/06c32b668d87e88eddd928b470299e308b46fa42/src/Forum/Controller/LogInController.php#L86

and magically, the bug is fixed : )

I hope you will find the valid fix for this issue : )

Bug report

• Version of Flarum: Flarum core 0.1.0-beta.6 (but I had the same difficulties with beta 5)
• Website URL where the bug is visible: http://mesinfos.fing.org/forum
• Apache
• PHP version: 5.6.21
• Hosted environment: shared
• Hosting provider: http://ovh.com

Flarum info

Flarum core 0.1.0-beta.6
PHP 5.6.21
Loaded extensions: Core, date, ereg, libxml, openssl, pcre, sqlite3, zlib, bcmath, bz2, calendar, ctype, curl, dba, dom, hash, fileinfo, filter, ftp, gd, gettext, gmp, SPL, iconv, session, intl, json, mbstring, mcrypt, mysql, mysqli, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, standard, posix, pspell, Reflection, imap, SimpleXML, soap, sockets, Phar, exif, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, memcache, mhash, ionCube Loader, Zend OPcache
EXT flarum-approval v0.1.0-beta.6
EXT flarum-bbcode v0.1.0-beta.5
EXT flarum-emoji v0.1.0-beta.6
EXT flagrow-upload 0.4.2
EXT flarum-flags v0.1.0-beta.6
EXT milescellar-french v1.0.6
EXT flarum-likes v0.1.0-beta.6
EXT flarum-lock v0.1.0-beta.6
EXT flarum-markdown v0.1.0-beta.5
EXT flarum-mentions v0.1.0-beta.6
EXT flarum-sticky v0.1.0-beta.6
EXT flarum-subscriptions v0.1.0-beta.6
EXT flarum-suspend v0.1.0-beta.6
EXT flarum-tags v0.1.0-beta.7
EXT avatar4eg-users-list 0.1.1
Base URL: http://mesinfos.fing.org/forum
Installation path: /home/fingyqpv/www/WordPress3/forum

Additional comments

Log files

NONE

[luceos]

If I try logging in at discuss.flarum.org with incorrect details it simply adds the "details incorrect message". What I can imagine is that you have debug enabled which returns more detailed information when the authentication fails. Can you confirm this issue cannot be reproduced on discuss.flarum.org?

[jacquarg]

Yes, I can't reproduce with discuss.flarum.org .

But I encounter the problem when the authentication success ( when it fails, there is a specific message, as expected).
But when it success, the flarum interface show an error (Oops, ...) and , in the developper console in firefox, I got 200 Ok on /login POST request, but the body is troncated (only half of the expected JSON object ).

[luceos]

I'd really like to see the json response that is truncated. We can't evaluate whether this is a bug in Flarum without steps to reproduce.

[jacquarg]

That's what I get from the developer console in firefox :
{"token":"B3sOdw5C3hvD5HfNEVUWrUj0PRB9mDhXDbyKfFkS","u

[luceos]

If you cannot reproduce this on discuss.flarum.org you can safely assume the issue has already been resolved (for the upcoming version). Feel free to reopen if you think closing this issue is a mistake.

[franzliedke]

@luceos Well, to be honest, this doesn't look like something that was wrong in Flarum, not even in the past. I am curious what it could be, though. Maybe a misconfigured server or some weird combination that leads to problems.

@jacquarg Can you show us the entire HTTP response from the server, please - including headers? You can find (and copy to clipboard) this in your browser's developer tools, network tab.

[luceos]

@franzliedke I was assuming the same. But without more information it's hard to further identify a cause.

[jacquarg]

@franzliedke:
Here is the whole response, as the debugger shows it:

Header:

HTTP/1.1 200 OK
Date: Mon, 23 Jan 2017 09:15:32 GMT
Server: Apache
X-Powered-By: PHP/5.6.21
X-CSRF-Token: pOuURcyKhklEGUbCljdZOubkh90YF2aYxTlGzaRa
Set-Cookie: mailplan=R1919031339; path=/; expires=Mon, 23-Jan-2017 10:22:52 GMT
flarum_remember=RxWfS7VrhN8t85bcE9CJqVrLlTQmV2yNG9gWJJ5P; Path=/; Max-Age=1209600; HttpOnly
flarum_session=0afb2b3da5a6af58789a2a4affa20c4f; Path=/; HttpOnly
Content-Length: 65
Cache-Control: max-age=0
Expires: Mon, 23 Jan 2017 09:15:32 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: application/json

body

{"token":"RxWfS7VrhN8t85bcE9CJqVrLlTQmV2yNG9gWJJ5P","u

[luceos]

Some research based on this:

• Setting Content-length might throw incorrect length, SO

[luceos]

Another report of this issue, also on OVH. Not sure, but this seems to be related to the hosting environment.

[dav-is]

I've noticed this issue on Laravel homestead before.

[luceos]

@dav-is any explanation back then, because this is the second report for a customer on OVH..

[dav-is]

It seemed to appear repeatibilly on certain errors when debugging extensions. I don't know what those errors were because it seemed to cut off most of it but I would refresh and get the same cut off message.

[Cadiducho]

Hi. I have the same bug, also with OVH hosting. When i write print_r($response); at the line that @jacquarg said, yup, the bug is gone. And I don't know why.
Flarum 0.1.0-beta.6, PHP 5.6

[franzliedke]

Where is that Content-Length header coming from? I do see that on discuss.flarum.org, too, but it should not be needed...

[franzliedke]

Looks like this actually has to do with our use of zend-diactoros, which does set the header.

[einworB]

I don't know if this information helps you, but I can confirm this issue (including the truncated response) for shared hosting with another hoster than ovh.com (german hoster called strato.de)

Login with right credentials leads to the Oops...you should reload error, debug shows 200 and truncated response and after reload the user is actually logged in.

[dsevillamartin]

Is this still an issue? Looks like zendframework/zend-diactoros removed the Content-Length header in v1.6.0 (zendframework/zend-diactoros#270), and we updated to ^1.7 last year (3680d88).

[franzliedke]

Yeah, I think we can close this. See zendframework/zend-diactoros#251 (comment).

If somebody has a problem like this again, feel free to comment - we can reopen then.