1

Клиент попросил меня установить tls-сертификат на своем веб-сервере и сделать перенаправление http-> https. После установки сертификата и настройки правил перезаписи все выглядит нормально:

    RewriteEngine on

    RewriteCond %{HTTP_HOST} !^www\. [NC] [OR]
    RewriteCond %{HTTPS} off 
    RewriteRule (.*) https://www.example.com%{REQUEST_URI} [R=301,L]


############################################
## rewrite API2 calls to api.php (by now it is REST only)

    RewriteRule ^api/rest api.php?type=rest [QSA,L]

############################################
## workaround for HTTP authorization
## in CGI environment

    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

############################################
## TRACE and TRACK HTTP methods disabled to prevent XSS attacks

    RewriteCond %{REQUEST_METHOD} ^TRAC[EK]
    RewriteRule .* - [L,R=405]
<IfModule mod_setenvif.c>
    <IfModule mod_headers.c>

        ############################################
        # X-Content-Type-Options: nosniff disable content-type sniffing on some browsers.
        Header set X-Content-Type-Options: nosniff

        ############################################
        # This header forces to enables the Cross-site scripting (XSS) filter in browsers (if disabled)
        BrowserMatch \bMSIE\s8 ie8
        Header set X-XSS-Protection: "1; mode=block" env=!ie8

    </IfModule>
</IfModule>

############################################
## always send 404 on missing files in these folders

    RewriteCond %{REQUEST_URI} !^/(media|skin|js)/

############################################
## never rewrite for existing files, directories and links

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-l

############################################
## rewrite everything else to index.php

    RewriteRule .* index.php [L]

НО: перед установкой перенаправления http-> https было установлено задание cron через панель webmin, которое выглядело так:

wget -O /dev/null http://example.com/some_api

К сожалению, клиент мало что знает об API, и я не могу читать документацию, так как не знаю языка, на котором он написан.

Я обнаружил, что приведенный выше вызов запускает процесс синхронизации (данные о продукте) между магазином (magento) и базой данных mongo, установленной в системе.

Я попытался адаптировать вышеуказанный вызов к перенаправлению http-> https, используя следующую новую командную строку:

wget -O /dev/null --ca-directory /home/user https://www.example.com/some_api

но теперь синхронизация больше не работает (мне пришлось добавить "www" к первоначально используемому имени хоста, так как в противном случае запрос зависал целую вечность).

При запуске вручную из webmin я получаю следующий вывод:

--2018-09-28 18:00:32--  https://www.example.com/some_api
Resolving www.example.com (www.example.com)... 46.xxx.yyy.zzz
Connecting to www.example.com (www.example.com)|46.xxx.yyy.zzz|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://example.com/ [following]
--2018-09-28 18:00:32--  https://example.com/
Resolving example.com (example.com)... 46.xxx.yyy.zzz
Connecting to example.com (example.com)|46.xxx.yyy.zzz|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/dev/null'

     0K .......... .......... .......... .......... .......... 57.4M
    50K .......... .......... .......... ........              4.50M=0.009s

2018-09-28 18:00:33 (9.40 MB/s) - `/dev/null' saved [90479]

Очевидно, что запрос перенаправляется в каталог DocumentRoot (содержащий файл index.php), но синхронизация не выполняется.

С этого момента я не знаю, как действовать дальше, поскольку мои ноу-хау об API и их поведении в указанных условиях недостаточны. Возможно, правильной переписки URL уже будет достаточно.

Итак, мой вопрос: как мне снова заставить работать вызов API?

|источник

0