CORE-POS / IS4C

Cooperative Operational Retail Environment
http://www.core-pos.com
GNU General Public License v2.0
64 stars 44 forks source link

composer install Problems #1072

Open flathat opened 3 years ago

flathat commented 3 years ago

I'm installing CORE from the current master, following the Wiki for Composer. This is on a shared host; I installed Composer locally.

$ cd /path/to/webroot/IS4C
$ cp composer.json.dist composer.json
# You may need to install composer. On Ubuntu:
#  $ apt-get install composer
$ composer install
# ... about PHP gd module ...
# $ composer update
# If it succeeds composer.lock is created.
$ composer install
No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires corepos/composer-installer ^2.0 -> satisfiable by corepos/composer-installer[2.0.0].
    - corepos/composer-installer 2.0.0 requires composer-plugin-api ^1.0 -> found composer-plugin-api[2.1.0] but it does not match the constraint.
  Problem 2
    - oomphinc/composer-installers-extender[v1.1, ..., v1.1.2] require composer-plugin-api ^1.0 -> found composer-plugin-api[2.1.0] but it does not match the constraint.
    - Root composer.json requires oomphinc/composer-installers-extender ^1.1 -> satisfiable by oomphinc/composer-installers-extender[v1.1, v1.1.1, v1.1.2].

With the supplied composer.lock present:

$ composer install
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Your lock file does not contain a compatible set of packages. Please run composer update.

  Problem 1
    - corepos/composer-installer is locked to version 2.0.0 and an update of this package was not requested.
    - corepos/composer-installer 2.0.0 requires composer-plugin-api ^1.0 -> found composer-plugin-api[2.1.0] but it does not match the constraint.
  Problem 2
    - oomphinc/composer-installers-extender is locked to version v1.1.2 and an update of this package was not requested.
    - oomphinc/composer-installers-extender v1.1.2 requires composer-plugin-api ^1.0 -> found composer-plugin-api[2.1.0] but it does not match the constraint.
  Problem 3
    - robloach/component-installer is locked to version 0.2.3 and an update of this package was not requested.
    - robloach/component-installer 0.2.3 requires composer-plugin-api ^1.0 -> found composer-plugin-api[2.1.0] but it does not match the constraint.
  Problem 4
    - robloach/component-installer 0.2.3 requires composer-plugin-api ^1.0 -> found composer-plugin-api[2.1.0] but it does not match the constraint.
    - components/jquery 1.11.1 requires robloach/component-installer * -> satisfiable by robloach/component-installer[0.2.3].
    - components/jquery is locked to version 1.11.1 and an update of this package was not requested.

composer update gives the same Problems as composer install without composer.lock present.

What to do about the Problems?

gohanman commented 3 years ago

You probably need to run composer self-update --1 to drop down to a 1.x version.

flathat commented 3 years ago

The Composer website has a fair bit to say about upgrades and downgrades.

I set aside composer.lock and vendor/ and then:

$ composer self-update --1
Warning: You forced the install of 1.10.22 via --1, but 2.1.1 is the latest stable version. Updating to it via composer self-update --stable is recommended.
Upgrading to version 1.10.22 (1.x channel).
Use composer self-update --rollback to return to version 2.1.0

and $ composer update, which ran successfully and created new composer.lock and vendor.

Fannie Install Necessities now reports:

I don't know how significant those warnings are. bootstrap is still being used to lay out form and some pages that use jquery are working but there are also some strange problems:

    mod.deptSave = function() {
        var fields = $('.deptFields :input').serialize();

        $.ajax({
            url: 'DepartmentEditor.php',
            type: 'post',
            timeout: 5000,
            data: fields,
            dataType: 'json'
        }).fail(function(){
            /* This message is displayed for any Save */
            showBootstrapAlert('#deptdiv', 'danger', 'Error saving department1');
        }).done(function(resp){
            if (resp.did && resp.msg) {
                showBootstrapAlert('#deptdiv', 'success', resp.msg);
            } else {
                showBootstrapAlert('#deptdiv', 'danger', 'Error saving department2');
            }
        });
    };
flathat commented 3 years ago

While staying with Composer version 1.10.22 I restored composer.lock to the version in the CORE release and vendors/ to one I imported from CORE 2.11.

The Warnings in Install > Necessities are now different, and don't include bootstrap or jquery:

but the problems with DepartmentEditor.php and loginform.php (class FannieAuthLoginPage) remain. Both extend FannieRESTfulPage so I
protected $debug_routing = true; in both
and in class DepartmentEditor->post_handler(), the only place it applies,
used echo $this->debugJSON($json); -- but the problem is it never executes post_handler().

I now know that FannieAuthLoginPage->post_name_password_handler() is never executed, just as DeparmentEditor->post_handler() isn't. The technique for tracking execution I'm using is to, at the beginning of each method:

public function foo_bar() {
$dbc = FannieDB::get(FannieConfig::config('OP_DB'));
$dbc->logger("Entered: " . __METHOD__);

This shows execution of:

but never, and not when the credentials are submitted, FannieAuthLoginPage->post_name_password_handler()

These routes appear to be intact:

class FannieRESTfulPage extends FanniePage {
...
    protected $__routes = array(
        'get',
        'get<id>',
        'post',
        'post<id>',
        'put',
        'put<id>',
        'delete',
        'delete<id>'
    );

There are no PHP or JS errors logged.

So I'm wondering why those post..._handler()s never execute.

gohanman commented 3 years ago

What's in $_SERVER? If through some goofy hosting configuration the REQUEST_METHOD isn't set (or isn't set correctly), it's not going to be able to detect when there's a POST and call the appropriate methods.

flathat commented 3 years ago

The arrangement at the host is described as "A PHP-FPM+Apache application is a directory which hosts PHP scripts and static content. When the application is added to a website, the frontend Nginx web server is automatically configured to serve your PHP scripts from your application directory via PHP-FPM from a backend Apache web server. This application type is most commonly used to serve PHP applications."

Install >Theming > Request Headers:

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sun, 06 Jun 2021 22:11:44 GMT
Content-Type: text/html
Content-Length: 162
Connection: close
Location: https://lvc.terraviva.opalstacked.com/IS4C/fannie/install/util.php
Strict-Transport-Security: max-age=31536000; includeSubDomains;
X-Content-Type-Options: nosniff
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 06 Jun 2021 22:11:44 GMT
Content-Type: text/html; charset=UTF-8
Connection: close

$_SERVER upon submitting Name and Password from loginform.php:

Entered: FannieAuthLoginPage::preprocess
CONTENT_LENGTH = '134'
CONTENT_TYPE = 'application/x-www-form-urlencoded'
CONTEXT_DOCUMENT_ROOT = '/opt/remi/php74/root/usr/bin'
CONTEXT_PREFIX = '/php74-bin'
DOCUMENT_ROOT = '/home/ericlee/apps/leverett'
GATEWAY_INTERFACE = 'CGI/1.1'
HTTPS = 'on'
HTTP_ACCEPT = 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
HTTP_ACCEPT_ENCODING = 'gzip, deflate, br'
HTTP_ACCEPT_LANGUAGE = 'en-US,en;q=0.5'
HTTP_CONNECTION = 'upgrade'
HTTP_COOKIE = 'PHPSESSID=ghq3ti7qk6qi48msh9mvff8pka; __perma=60bab0285abb12.65728644'
HTTP_DNT = '1'
HTTP_FORWARDED_REQUEST_URI = '/IS4C/fannie/auth/ui/loginform.php'
HTTP_HOST = 'lvc.terraviva.opalstacked.com'
HTTP_HTTPS = 'on'
HTTP_ORIGIN = 'https://lvc.terraviva.opalstacked.com'
HTTP_REFERER = 'https://lvc.terraviva.opalstacked.com/IS4C/fannie/auth/ui/loginform.php?redirect=/IS4C/fannie/auth/ui/loginform.php'
HTTP_UPGRADE_INSECURE_REQUESTS = '1'
HTTP_USER_AGENT = 'Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0'
HTTP_X_FORWARDED_HOST = 'lvc.terraviva.opalstacked.com'
HTTP_X_FORWARDED_PROTO = 'https'
HTTP_X_FORWARDED_SERVER = 'lvc.terraviva.opalstacked.com'
HTTP_X_FORWARDED_SSL = 'on'
ORIG_PATH_INFO = '/IS4C/fannie/auth/ui/loginform.php'
ORIG_PATH_TRANSLATED = '/home/ericlee/apps/leverett/IS4C/fannie/auth/ui/loginform.php'
ORIG_SCRIPT_FILENAME = '/opt/remi/php74/root/usr/bin/php-cgi'
ORIG_SCRIPT_NAME = '/php74-bin/php-cgi'
PATH = '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin'
PHP_SELF = '/IS4C/fannie/auth/ui/loginform.php'
QUERY_STRING = ''
REDIRECT_HANDLER = 'application/x-httpd-php7'
REDIRECT_HTTPS = 'on'
REDIRECT_STATUS = '200'
REDIRECT_UNIQUE_ID = 'YL1fYDifO5EqjFKw41@d9AAAAAU'
REDIRECT_URL = '/IS4C/fannie/auth/ui/loginform.php'
REMOTE_ADDR = '###.###.###.###'
REMOTE_PORT = '##274'
REQUEST_METHOD = 'POST'
REQUEST_SCHEME = 'http'
REQUEST_TIME = '1623023456'
REQUEST_TIME_FLOAT = '1623023456.1226'
REQUEST_URI = '/IS4C/fannie/auth/ui/loginform.php'
SCRIPT_FILENAME = '/home/ericlee/apps/leverett/IS4C/fannie/auth/ui/loginform.php'
SCRIPT_NAME = '/IS4C/fannie/auth/ui/loginform.php'
SERVER_ADDR = '127.0.0.1'
SERVER_ADMIN = '[no address given]'
SERVER_NAME = 'lvc.terraviva.opalstacked.com'
SERVER_PORT = '80'
SERVER_PROTOCOL = 'HTTP/1.1'
SERVER_SIGNATURE = '<address>Apache Server at lvc.terraviva.opalstacked.com Port 80</address>'
SERVER_SOFTWARE = 'Apache'
UNIQUE_ID = 'YL1fYDifO5EqjFKw41@d9AAAAAU'
flathat commented 3 years ago

And for $_POST there:

name = 'fred'
password = '#####'
redirect = '/IS4C/fannie/auth/ui/loginform.php'
_token_ = 'foobar'
flathat commented 3 years ago

Compared to another shared host where login and DeptEdit are not problematic:

Entered: FannieAuthLoginPage::preprocess
AUTH_TYPE = 'Basic'
CONTENT_LENGTH = '111'
CONTENT_TYPE = 'application/x-www-form-urlencoded'
CONTEXT_DOCUMENT_ROOT = '/home/muyujiev/public_html/brfc'
CONTEXT_PREFIX = ''
DOCUMENT_ROOT = '/home/muyujiev/public_html/brfc'
HTTPS = 'on'
HTTP_ACCEPT = 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
HTTP_ACCEPT_ENCODING = 'gzip, deflate, br'
HTTP_ACCEPT_LANGUAGE = 'en-US,en;q=0.5'
HTTP_AUTHORIZATION = 'Basic ###################=='
HTTP_CONNECTION = 'keep-alive'
HTTP_COOKIE = 'PHPSESSID=6266e8a8a07974cfc9c4655c2f6db492'
HTTP_DNT = '1'
HTTP_HOST = 'brfc.ttsc-dev.com'
HTTP_ORIGIN = 'https://brfc.ttsc-dev.com'
HTTP_REFERER = 'https://brfc.ttsc-dev.com/IS4C/fannie/auth/ui/loginform.php?logout=yes'
HTTP_UPGRADE_INSECURE_REQUESTS = '1'
HTTP_USER_AGENT = 'Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0'
PATH = '/usr/local/bin:/usr/bin:/bin'
PHP_AUTH_PW = '###########'
PHP_AUTH_USER = 'brfc_1'
PHP_SELF = '/IS4C/fannie/auth/ui/loginform.php'
PWD = '/'
QUERY_STRING = ''
REMOTE_ADDR = '###.###.###.###'
REMOTE_PORT = '##444'
REMOTE_USER = 'brfc_1'
REQUEST_METHOD = 'POST'
REQUEST_SCHEME = 'https'
REQUEST_TIME = '1623025555'
REQUEST_TIME_FLOAT = '1623025555.1451'
REQUEST_URI = '/IS4C/fannie/auth/ui/loginform.php'
SCRIPT_FILENAME = '/home/muyujiev/public_html/brfc/IS4C/fannie/auth/ui/loginform.php'
SCRIPT_NAME = '/IS4C/fannie/auth/ui/loginform.php'
SERVER_ADDR = '167.114.11.193'
SERVER_ADMIN = 'webmaster@brfc.ttsc-dev.com'
SERVER_NAME = 'brfc.ttsc-dev.com'
SERVER_PORT = '443'
SERVER_PROTOCOL = 'HTTP/1.1'
SERVER_SIGNATURE = ''
SERVER_SOFTWARE = 'Apache'
SSL_TLS_SNI = 'brfc.ttsc-dev.com'
TEMP = '/tmp'
TMP = '/tmp'
TMPDIR = '/tmp'
UNIQUE_ID = 'YL1nk4BinTRUmOuBw4otogAAAsY'
argc = '0'
argv = 'Array
POST
name = 'fred'
password = '########'
redirect = 'menu.php'
_token_ = 'foobar'
gohanman commented 3 years ago

Are you maybe running into this? https://www.php.net/manual/es/function.filter-input.php#77307

If so, it's going to cause a whole raft of problems and the best fix is probably getting different hosting.

lgedgar commented 3 years ago

@flathat you are hitting a HTTPS (secure) site, which is proxying to a HTTP (insecure) site. Maybe that is part of the problem..?

But in general I agree with @gohanman that using a different hosting provider is likely the (easiest) "fix" here.. Now that I use Linode I can't imagine going back to shared hosting with all its restrictions.

lgedgar commented 1 year ago

I believe Composer v2 is required now, per: