Adikm 0 Zgłoś post Napisano Maj 8, 2018 (edytowany) Witajcie, Zmagam się z następującym problemem. Korzystam z DirectAdmin'a na jednym z VPS, na innych jest czysty Debian, zdecydowanie bardziej preferuję nginx'a. Po włączeniu obsługi SSL dla jednej z domen, na którym stoi sklep internetowy mam błąd ERR_TOO_MANY_REDIRECTS. Umieściłem w pliku .htaccess zalecane przez help DA przekierowania: RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] Podejrzewam, że problem dotyczy właśnie tego pliku .htaccess. Siedzę już kilka godzin i nie mogę znaleźć co powoduje tą pętlę przekierowań. Plik .htaccess wygląda następująco: htaccess file: #AddHandler x-httpd-php53 .php RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] # use if needed: #RewriteBase / RewriteRule ^$ / [QSA] RewriteCond %{REQUEST_FILENAME} ([a-z_]+?)_picture/(.*?)\.(?:jpg|png)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ([a-z_]+?)_picture/(.*?)/(.*?)\.(jpg|png)$ thumbnailer/create/$1/$2/$3/$4 [QSA,L] # some hosts need redirect: # RewriteRule ([a-z_]+?)_picture/(.*?)/(.*?)\.(jpg|png)$ thumbnailer/create/$1/$2/$3/$4 [QSA,R,L] # redirects request to nonexisting CSS and JS to empty CSS/JS files [so you dont need to define module CSS/JS if you dont need it] RewriteCond %{REQUEST_FILENAME} ^(.*?)\.css$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ stylesheets/core/no_css.css [QSA,L] RewriteCond %{REQUEST_FILENAME} ^(.*?)\.js$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ javascript/core/no_js.js [QSA,L] # displays 404.html if IMAGE is not found RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_URI} images/.*?(png|jpg|gif) # ^^ may catch valid requests that contain "images/" and have image extension!!!! RewriteRule ^(.*)$ 404.html [QSA,L] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php/$1 [QSA,L] # also OK RewriteRule ^(.*)$ index.php/%{REQUEST_FILENAME} [QSA,L] # define error pages ErrorDocument 404 error_page.php ErrorDocument 406 error_page.php ErrorDocument 500 error_page.php Natomiast konfigurację vhost wrzuciłem na pastebin: https://pastebin.com/wGvCBgmJ Będę wdzięczny za podpowiedź. Edytowano Maj 8, 2018 przez Adikm (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
emt3c 0 Zgłoś post Napisano Maj 8, 2018 Problem masz przy konfiguracji SSL na vps gdzie masz DirectAdmin zainstalowany? W options.conf masz włączoną obsługę SSL? Udostępnij ten post Link to postu Udostępnij na innych stronach
Adikm 0 Zgłoś post Napisano Maj 8, 2018 (edytowany) Tak, w options.conf jest SSL włączone. Certyfikat SSL oczywiście jest typu wildcard. Subdomena, gdzie mam zainstalowaną aplikację (LiveZilla) działa na SSL bez problemu. Problem natomiast dotyczy sklepu internetowego, jest na domenie *.pl. Dodatkowo mam kilka domen (com, eu, net), które są przekierowane na domenę *.pl. Edytowano Maj 8, 2018 przez Adikm (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
emt3c 0 Zgłoś post Napisano Maj 8, 2018 W DirectAdmin dla domeny gdzie masz sklep wkleiłeś poprawnie certyfikat i klucze pośredniczące? Ustawiłeś w DirectAdmin przekierowanie folderu w ustawieniach domeny ( Użyj dowiązania symbolicznego private_html do public_html Pozwala na dostęp do tej samej strony zarówno przez http:// jak i https:// ) ? Udostępnij ten post Link to postu Udostępnij na innych stronach
Adikm 0 Zgłoś post Napisano Maj 8, 2018 (edytowany) Oczywiście, to jest pierwsza rzecz, od której zacząłem. Certyfikaty wklejone, DirectAdmin prawidłowo rozpoznał ich ważność. Tak jak wspomniałem subdomena.moj-sklep.pl, gdzie mam LiveZillę smiga bez problemu. Dodałem jedynie do .htaccess wpisy: RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] Edytowano Maj 8, 2018 przez Adikm (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
emt3c 0 Zgłoś post Napisano Maj 8, 2018 W /public_html w .htaccess dodałeś? RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{www.MojaNazwaDomeny.pl} [L,R=301] Udostępnij ten post Link to postu Udostępnij na innych stronach
Adikm 0 Zgłoś post Napisano Maj 8, 2018 (edytowany) Nie, dodałem w katalogu /public_html/application/public/ ponieważ tutaj jest zainstalowany cały sklep. Był już tam plik .htaccess, którego zawartość wkleiłem w pierwszym poście. Jak dodam do pliku .htaccess w /public_html to nic się nie dzieje. Tak się zastanawiam czy kolejność, gdzie robię przekierowanie na https w pliku .htaccess ma znaczenie? Edytowano Maj 8, 2018 przez Adikm (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
emt3c 0 Zgłoś post Napisano Maj 8, 2018 A spróbuj: RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{www.mojanazwadomeny.pl} [L,R=301] Udostępnij ten post Link to postu Udostępnij na innych stronach
Adikm 0 Zgłoś post Napisano Maj 8, 2018 Spróbowałem, ale niestety to samo Pętla przekierowań Firefox wykrył, że serwer przekierowuje żądanie tego zasobu w sposób uniemożliwiający jego ukończenie. Problem ten może się pojawić w wyniku zablokowania lub odrzucenia ciasteczek. Gdy to usunę po http działa poprawnie. Udostępnij ten post Link to postu Udostępnij na innych stronach
Piotr GRD 608 Zgłoś post Napisano Maj 8, 2018 (edytowany) Po pierwsze: Nie można poprzestać na "diagnozie" (cudzysłów konieczny), że "Firefox wykrył, że serwer przekierowuje żądanie tego zasobu w sposób uniemożliwiający jego ukończenie". Należy prześledzić wszystkie nagłówki, wszystkie kolejne (przynajmniej ze dwa trzy) przekierowania, to potrafi dużo powiedzieć o tym co się dokładnie dzieje, jaka to dokładnie pętla. Po drugie: Ja stawiałbym w pierwszej kolejności na to, że .htaccess przekierowuje na https, a skrypt sklepu na zwykłe http i tak w kółko. Sprawdzana była w ogóle konfiguracja sklepu w tym względzie? Jeśli jest w skrypcie sklepu taka opcja, to najpierw przestawić sklep na https i jeśli działać będzie, dopiero wtedy dołożyć wymuszone przekierowanie w .htaccess (choć może nie będzie trzeba, bo skrypt sklepu wszystkim się zajmie). Edytowano Maj 8, 2018 przez Piotr GRD (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Adikm 0 Zgłoś post Napisano Maj 8, 2018 (edytowany) 59 minut temu, Piotr GRD napisał: Po pierwsze: Nie można poprzestać na "diagnozie" (cudzysłów konieczny), że "Firefox wykrył, że serwer przekierowuje żądanie tego zasobu w sposób uniemożliwiający jego ukończenie". Należy prześledzić wszystkie nagłówki, wszystkie kolejne (przynajmniej ze dwa trzy) przekierowania, to potrafi dużo powiedzieć o tym co się dokładnie dzieje, jaka to dokładnie pętla. Piotrze mógłbyś podpowiedzieć jak to zdiagnozować, jakim narzędziem będzie najłatwiej? Cytat Po drugie: Ja stawiałbym w pierwszej kolejności na to, że .htaccess przekierowuje na https, a skrypt sklepu na zwykłe http i tak w kółko. Sprawdzana była w ogóle konfiguracja sklepu w tym względzie? Jeśli jest w skrypcie sklepu taka opcja, to najpierw przestawić sklep na https i jeśli działać będzie, dopiero wtedy dołożyć wymuszone przekierowanie w .htaccess (choć może nie będzie trzeba, bo skrypt sklepu wszystkim się zajmie). To może być jedna z możliwości. Sklep jest na silniku i-systems.pl, dosyć zagmatwana konfiguracja. Wsparcie odpada, bo żądają gigantycznych opłat najpierw za samą aktualizację. Gdyby to była prestashop czy coraz bardziej popularny thirtybees, na którym uruchomiłem najnowszy sklep byłoby prościej. Jeśli chodzi o konfigurację sklepu to w panelu admina nic takiego nie znalazłem. Jest za to w katalogu config plik ssl_template.php o poniższej zawartości, może coś tutaj Ci podpowie: <?php /** * 1. Enable SSL in 'enabled' * 2. Define which domains (not aliases) should use SSL in 'ssl_domains' * 3. Configure 'admin_sections_prefixes' if needed (this is to support '/admin/*' urls) * 4. Configure controllers to return public function getActionsForSSL() * 5. Refresh controller configuration cache in /admin/technical_panel * 5.1 Refresh this cache config after each change in controllers */ return array( 'enabled' => true, // 'enabled' => false, 'ssl_domains' => array( 'secure.site.pl' ), // check plugins.php // and copy all prefixes configured in: $pluginManager->registerPlugin( Framework_Plugins_PluginManager::AFTER_ROUTING, new Application_AdminSectionPlugin(array('admin'))); 'admin_sections_prefixes' => array( 'admin', ) ); PS. Znajomy administrator zasugerował, że problem może być spowodowany tym, że http i https w vhoscie wskazuje na public_html, podczas gdy https powinien wskazywać private_html (gdzie powinna być strona, a przekierowanie pliku htaccess powinno być w public_html). Edytowano Maj 8, 2018 przez Adikm (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Adikm 0 Zgłoś post Napisano Maj 9, 2018 (edytowany) Spróbowałem jeszcze jednej rzeczy. Przeniosłem wszystkie pliki wraz z katalogami z public_html do private_html. Zmieniłem w DA |*if !SUB| |?DOCROOT=/home/admin/domains/itx-sklep.pl/public_html/application/public| |*endif| na |*if !SUB| |?DOCROOT=/home/admin/domains/itx-sklep.pl/private_html/application/public| |*endif| W lokalizacji /public_html/application/public stworzyłem .htaccess z zawartością: RewriteEngine On RewriteCond %{HTTPS} !on RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] Po wczytaniu domeny sklepu pojawiła się zielona kłódka, niestety są błędy: Warning: require_once(/home/admin/domains/my-shop.net/public_html/application/public/../../framework/gp/event_dispatcher/EventDispatcherGP.php): failed to open stream: No such file or directory in /home/admin/domains/my-shop.net/private_html/framework/autoloader/Autoloader.php on line 66 Fatal error: require_once(): Failed opening required '/home/admin/domains/my-shop.net/public_html/application/public/../../framework/gp/event_dispatcher/EventDispatcherGP.php' (include_path='.:/usr/local/lib/php:/home/admin/domains/my-shop.net/private_html/application:/home/admin/domains/my-shop.net/private_html/framework:/home/admin/domains/my-shop.net/private_html/framework/libs/:/home/admin/domains/my-shop.net/private_html/application/libs/ThirdParty') in /home/admin/domains/my-shop.net/private_html/framework/autoloader/Autoloader.php on line 66 Zrobiłem też link symboliczny ln -s /private_html/application/public -> /public_html/application/public Zastanawia mnie dlaczego skrypt nadal próbuje wczytać pliki z katalogu public_html. Przejrzałem wszystkie pliki w katalogu config i nie ma tam żadnej konfiguracji w tym zakresie. Edytowano Maj 9, 2018 przez Adikm (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Adikm 0 Zgłoś post Napisano Maj 11, 2018 Problem rozwiązany, brakowało pliku ssl.php na podstawie powyższego szablonu z nazwami dozwolonych domen oraz ssl_actions_cache.php z nazwami klas, gdzie ma być włączony SSL. Udostępnij ten post Link to postu Udostępnij na innych stronach