mirror of
https://github.com/cypht-org/cypht.git
synced 2026-04-25 13:05:53 +03:00
[GH-ISSUE #405] Cypht not compatible with PHP Version 7.3 and 7.4 #339
Labels
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cypht#339
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Master0ne on GitHub (Jun 10, 2020).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/405
Originally assigned to: @jasonmunro on GitHub.
🐛 Bugreport
As it turned out, Cypht is not compatible with PHP Version 7.3 and 7.4, resulting in getting stuck at the login page, which just gets reloaded after entering correct credentials.
Version
Rev: master
Steps to reproduce
I have tried several different PHP versions between 5.6 and 7.4, and the conclusion is that the current version of Cypht (fresh git pull) is:
@jasonmunro commented on GitHub (Jun 10, 2020):
Cypht (current master branch) works fine with PHP 7.3 and 7.4 for me (and Travis CI as seen here: https://travis-ci.org/github/jasonmunro/cypht/builds/683660242) so I'm not sure why it's failing for you. Looking at the debug output you sent me via E-mail I noticed this:
LOGGED OUT: invalid methodwhich is odd and likely related. This message is logged if an HTTP request is made to cypht that is NOT either a GET or POST request. If that happens, the code logs you out.
@jasonmunro commented on GitHub (Jun 10, 2020):
https://gist.github.com/jasonmunro/f758e4a071b390881bbdc2d91f85d450 <- this patch will log the HTTP method being used that appears to be related to your issues with PHP > 7.2. You need to be running cypht in debug mode but it should log whatever unacceptable method type is being sent to cypht. Once we determine the offending method type, the next question is what is sending it, and why is it only happening in PHP > 7.2 if that is indeed the case.
@Master0ne commented on GitHub (Jun 10, 2020):
@jasonmunro thanks a lot for getting back to me, this really is very odd, because all I did during my tests with the different PHP versions is to switch between them by using the following
.htaccessentries as per instructions from Hetzner shared hosting support, and nothing else has been changed during these tests:So the webhost is configured to run the latest available PHP version 7.4.6, and that one just did not work with Cypht right from the beginning, and I tried with several fresh installations.
Just today in the morning it came to my mind that it may have to do with the PHP version, so I tried switching between the available versions on that webhost with the
.htaccessentries shown above, and starting with version 5.6 I was suddenly able to log in as suppsed to, however it stopped again when reaching version 7.3.18 with the same problem (stuck at login page, which just reloads after providing the proper credentials).The PHP error log did not reveal anything else in debug mode, so I will try your patch tomorrow morning (it's already evening here) and report back then.
@Master0ne commented on GitHub (Jun 11, 2020):
I have applied your patch and this is the output from the PHP errors log:
With PHP 7.4.6
With PHP 7.2.31
Nothing else than switching between the two PHP versions by using the shown
.htaccessmethod has been changed between the two runs.P.S. Sensible information in that output from the PHP errors log (
{domain},{MySQL host},{database name}and/path/to/lib/module.php) has been modified.@dumblob commented on GitHub (Jun 11, 2020):
That's interesting, your request in the former case is NOT done over SSL (TLS), but in the latter it is. It should be done over SSL (TLS) in both cases.
Did you try to run
sudo php ./scripts/config_gen.phpalways after switching to a different PHP version?@Master0ne commented on GitHub (Jun 11, 2020):
@dumblob I have not rerun
php ./scripts/config_gen.phpbefore when switching between PHP versions (and I see no relevance for this), but I tried just now and it did not change anything.Browser access to that Cypht installation is done over HTTPS only and the webhost is configured to redirect any HTTP to HTTPS automatically.
BTW for what it's worth, the webhost setup at Hetzner is running on Debian 10 with only official Debian packages / modules installed:
@dumblob commented on GitHub (Jun 11, 2020):
I also don't, but I didn't look at the source recently so I'm not sure whether it does something relevant (and there is plenty of space for that, believe me).
Hm, how does the switching between PHP versions actually work? Do all Cypht dependencies also get switched to versions compatible with the chosen PHP version? Or just PHP with some core modules gets switched? Google suggests issues with incompatible SSL libraries, but it'd be premature to say that's probably the reason 😉.
@jasonmunro thinking about deployment issues - could we somehow check beforehand whether installation is correct?
@Master0ne commented on GitHub (Jun 11, 2020):
@dumblob Please see above here where I've explained how switching between PHP versions works with
.htaccesson such a webhost at Hetzner.Would it help to give you access to my Cypht installation by ftp/sftp so that you can take a look for yourself?
Unfortunately I can not give you shell access as there is only one ssh account for the whole webhost.
@dumblob commented on GitHub (Jun 11, 2020):
@Master0ne sorry for not being clear. With
how does the switching between PHP versions actually work?and the subsequent questions I was mainly interested in what the*-fcgi-starter.fcgibinaries do. If it's not known, then we have to look elsewhere for the culprit 😢.This I'd leave to @jasonmunro as he's the main architect and dev, so he'd be much more efficient when looking around.
I still have a feeling from the log, that the chosen PHP version doesn't somehow load all modules correctly (maybe even the SSL lib is not loaded as expected). Or maybe in addition to
.phpfiles open.htmlfiles by the given PHP handler as well?In any case, Hetzner writes
You can set up the standard PHP version. All files ending in «.php» are automatically parsed with this PHP version. In addition the following attributions are standard:...(the list of .htaccess directives)on https://wiki.hetzner.de/index.php/KonsoleH:PHP-Konfiguration/en which I understand as there is yet another way of switching PHP versions than just by using.htaccess(wouldn't.htaccessbe needed in all directories including all Cypht subdirectories recursively)?Could you try to switch PHP version using this different method (i.e. by removing anything PHP-related from all
.htaccessfiles or better by removing all.htaccessfiles recursively?@Master0ne commented on GitHub (Jun 11, 2020):
@dumblob I don't know how the actual switching between PHP versions works and this definitely is of no concern, because I've configured the whole webhost (which is running multiple websites) to use the latest available PHP version (7.4.6).
I've used the PHP version switching feature by
.htaccessonly for downgrading particular websites from PHP version 7.4.6, so for testing if Cypht is working with an older PHP version, and I'm using that feature for two other older websites on that webhost, which do not work with anything newer than PHP version 5.6.So the default is to have no
.htaccessfile at all for Cypht, then it's running on PHP 7.4.6 and not working with the shown problem of being stuck at the login page.As said, there are multiple websites on that webhost, even things like Nextcloud and Matamo, all running the same PHP version 7.4.6 and every other website works without any problems, only Cypht is not working.
You may be on the right path with the differences shown in the PHP error logs, so why it shows a TLS request on PHP v7.2.31 but none on PHP v.7.4.6, and why it shows
/as request path on PHP v7.2.31 but an empty request path on PHP v.7.4.6.My (unqualified) guess is, that there is a bug in the Crypt code that manifests itself only in PHP versions >= 7.3, has something to do with TLS and obviously does not occur in other setups.
Is it possible, that there is anything hard-coded (in lack of a better wording) to use HTTP instead of HTTPS during the login process in a way that works differently between PHP versions <= 7.2 and >= 7.3?
All websites on that webhost are configured to use server side HTTPS redirect ("With this function, you can automatically redirect all request and create a secure connection for all visitors to your site."), so there is no need to take care of this using the RewriteEngine in
.htaccess.@jasonmunro commented on GitHub (Jun 11, 2020):
The problem is very clearly the lack of HTTP method value with PHP 7.4 which is present with PHP 7.2.
From your 7.4 log:
[11-Jun-2020 05:09:27 UTC] boolean:7.2 log
[11-Jun-2020 05:13:20 UTC] string: POSTWe pull this from the REQUEST_METHOD value in the $_SERVER array. If it's not set to either POST or GET we log the user out which is what is happening here. This is odd and very much NOT the case with my PHP 7.4 installation on Debian. @Master0ne can you capture the output of this patch: https://gist.github.com/jasonmunro/bb58729e546ee9258865213450c37acc so we can see what is in the $_SERVER array?
@Master0ne commented on GitHub (Jun 11, 2020):
Output with patch applied:
With PHP 7.4.6
With PHP 7.2.31
P.S. Sensible information (
IP addresses,{domain},{MySQL host},{database name}and/path/to) anonymized.@jasonmunro commented on GitHub (Jun 11, 2020):
The above is the problem. Cypht uses a handful of values that are almost always present in $_SERVER and they are all missing from your setup for some reason. For comparison, here is the same output on my Debian PHP 7.4.5 setup:
This appears to be the same issue we ran into here: https://github.com/jasonmunro/cypht/issues/370 I'm not sure exactly how to resolve this as we need those values in a couple of key bits of code.
If you replace the debug in the patch that is currently:
elog($this->server);with
elog($_ENV)what does it produce in the log for PHP 7.4? Maybe we can fallback to using $_ENV if $_SERVER does not have what we need.
@Master0ne commented on GitHub (Jun 12, 2020):
@jasonmunro I have sent you an email with the link to
phpinfo()if that is of any help.Output with
elog($_ENV):With PHP 7.4.6
With PHP 7.2.31
@Master0ne commented on GitHub (Jun 12, 2020):
I don't know the relevance, but I have just taken a look at PHP :: Bug #49184 | INPUT_SERVER returns NULL for set variables (CLI) and testing on CLI gives the following results, which are the same with all available PHP versions:
INPUT_SERVER
INPUT_ENV
@jasonmunro commented on GitHub (Jun 18, 2020):
@Master0ne sorry for the delay, working on a fix now that will try to use $_ENV if $_SERVER is missing the bits we need. Should resolve your issue. I will let you know when it's ready to test. Thanks for your patience!
@Master0ne commented on GitHub (Jun 19, 2020):
@jasonmunro super, thanks a lot for taking care of this.
@jasonmunro commented on GitHub (Jun 19, 2020):
@Master0ne thank you for working with me to get it resolved! Could you try the latest master branch? I pushed a change that enables a fallback that I hope will resolve this issue (
github.com/jasonmunro/cypht@0ab3184560)@Master0ne commented on GitHub (Jun 23, 2020):
@jasonmunro you did it, it's finally working!
@jasonmunro commented on GitHub (Jun 25, 2020):
@Master0ne thanks for the confirmation. Closing this as it should be resolved. Please re-open or submit a new issue if you have further problems. Thanks again!
@marclaporte commented on GitHub (Sep 17, 2020):
@Master0ne please join us at https://gitter.im/cypht-org/community
@mijofa commented on GitHub (Nov 20, 2023):
Sorry for some thread necromancy, but I'm running into what looks like this same issue with PHP 8.2.
Both
$this->serverand$this->envare coming up completely empty for me with v1.4.1 on PHP 8.2.I'm working around this myself by setting
$this->server = $_SERVER&$this->env = $_ENVfilter_request_input, but I'm not sure if this is suitable long-term.I'm not fluent with PHP, but I think this would likely have issues with type conversions, although I haven't run into any with initial testing.
@marclaporte commented on GitHub (Nov 20, 2023):
"thread necromancy": I am quite OK with this as I think it's relevant info.
But the bigger topic deserves its own task:
https://github.com/cypht-org/cypht/issues/829