gerdriesselmann / gyro-php Goto Github PK

GB leaves EU on January 31st, 2020. Update countries DB accordingly

Recently I had a very rare redirect error with a new setup:

• APP_ENABLE_HTTPS was set to true,
• APP_DEFAULT_SCHEME was undefined.

When opening the domain in browser, i.e. https://example.com the page was redirected to http://example.com and the again to https://example.com ... and so on. I could fix this with setting APP_DEFAULT_SCHEME to https. This was the first time I saw this kind of error, webserver is nginx/php-fpm (7.3)

In gyro/core/constants.inc.php line #49 is:

Config::set_value_from_constant(Config::DEFAULT_SCHEME, 'APP_DEFAULT_SCHEME', 'http');

Maybe the fallback of "http" should be set to https if ENABLE_HTTPS/APP_ENABLE_HTTPS is true?

Not sure if this a bug or feature ;)

Given a URL with the same parameter assigned twice like

www.example.com?q=a&q=b

The URL class will only keep the second (q=b), dropping the first. This is similar to PHP'S $_GET array, but not helpfull when reading and building URLs.

Change this so get_query_parameter() resembles PHP behavior, but build() outputs the original URL.

HttpRequest currently can not be extended easily, e.g. by custom HTTP Headers or by other type of POST body data. Rewrite to use a config that can does configuration of CURL request and can be overloaded by user.

I had thought about writing a completely separate module for this, but then a lot of code has to be copied/pasted from the usermanagement module if one leave usermanagement unchanged. As an additional module with a few adjustments in the usermanagement module this would be more elegant.

Would be nice to wrap something like this with gyro-php:

        $data = ConverterFactory::encode($data, CONVERTER_JSON);

        try {
            $ch = curl_init($url);
            curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");

            curl_setopt($ch, CURLOPT_POSTFIELDS, $data);

            curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
            curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5);
            curl_setopt($ch, CURLOPT_FRESH_CONNECT, 1);
            curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);

            if (!ini_get('safe_mode')) {
                curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
            }

            curl_setopt($ch, CURLOPT_HTTPHEADER, array(
                'Content-Type: application/json',
                'Content-Length: ' . strlen($data))
            );
            $result = curl_exec($ch);

Using continue inside a switch statement causes a warning on PHP 7.3. Remove whereever it occurs.

Hi Gerd,

I've an issue with dbfield.float ... but only on external server, not locally in docker development. Maybe you've an idea:

• app/constants.php has a define('APP_LANG', 'de');
• my MySQL table contains a field with decimal(12,2)

Whenever I type something in remote server forms for that field, i.e. "1", after form has been saved the form updates to the DB value "1.00" (which is what I expect). But next time I save the form, "1.00" will be delocalized (from dbfield.float read_from_array() to 100, so the the number updates to "100", which is wrong.

I would expect that GyroString::localize_number has to be called somewhere, so that the form values contains "1,00" instead of "1.00", so delocalize_number makes sense ... but core never called it.

I assume date.timezone = Europe/Berlin (which is used on external server) cause the issue?

update 0008 gives:
Data too long for column 'poly' at row 1

Line 137 in that file contains 144139 characters, to much for a MySQL TEXT column.

The comment says:

All actions will get access checked, and removed if access is denied

but only actions which are not instance of IAction will be tested by AccessContol.

Bug or feature?

Initially the database column creationdate is setup with

creationdate TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,

in install.sql, but revised to

MODIFY COLUMN creationdate DATETIME NOT NULL,

in 0003-Update. I assume there was a reason to do so.

Without a valid creationdate the internal clicktracking / url-rewriting fails, becasue the sha-checksum is based on creationdate too - and a 0 in creationdate seems to be replaced "somewhere" with a current timestamp before the clicktracking is applied - but not on single get's later when the clicktracking token is compared.

So a possible fix is to change mass-insert in notifyall.cmd.php to set a propper "creationdate" on insert.