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

Created on 20 Jan 2017 · 19Comments · Source: flarum/core

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

typbug

Source

jacquarg

Most helpful comment

Yeah, I think we can close this. See https://github.com/zendframework/zend-diactoros/issues/251#issuecomment-329754127.

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

franzliedke on 1 Oct 2019

👍2

All 19 comments

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?

luceos on 20 Jan 2017

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

jacquarg on 20 Jan 2017

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.

luceos on 20 Jan 2017

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

jacquarg on 20 Jan 2017

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.

luceos on 20 Jan 2017

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

franzliedke on 20 Jan 2017

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

luceos on 20 Jan 2017

@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

jacquarg on 23 Jan 2017

Some research based on this:

[ ] Setting Content-length might throw incorrect length, SO

luceos on 23 Jan 2017

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

luceos on 26 Jan 2017

I've noticed this issue on Laravel homestead before.

dav-is on 26 Jan 2017

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

luceos on 26 Jan 2017

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.

dav-is on 26 Jan 2017

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

Cadiducho on 12 Mar 2017

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

franzliedke on 13 Mar 2017

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

franzliedke on 13 Mar 2017

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.

einworB on 12 Jun 2017

Is this still an issue? Looks like zendframework/zend-diactoros removed the Content-Length header in v1.6.0 (https://github.com/zendframework/zend-diactoros/pull/270), and we updated to ^1.7 last year (https://github.com/flarum/core/commit/3680d88fb76ddc4277d3062e313aaab8c2f63279).