Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Próbuję napisać jakieś regułki i wklepać je do .htaccess ale mam jeden problem, z którym nie mogę sobie dać rady. Generalnie rzecz biorąc, to na necie znalazłem coś takiego:
RewriteCond %{HTTPS} !=on RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [R,L]
No i po wpisaniu adresu strony (bez https), ta zmienia się z automatu na https i przeglądanie kolejny podstron już się odbywa po https. Rzecz w tym, że jeśli wpiszę jakiś adres typu: http://morfikownia.lh/test/ , to już nie przepisuje w nim http na https, a chodzi właśnie o to by nawet tego typu odnośniki były przepisywane na https.
Jak zmusić apache by zawsze korzystał z https?
Ostatnio edytowany przez morfik (2015-05-24 21:16:30)
Offline
Spróbuj zmienić:
SERVER_NAME
na
HTTP_HOST
Możesz też zamiast Rewrite użyć tego:
https://wiki.apache.org/httpd/RedirectSSL#Using_virtual_hosts_.28using_redirect.29
Ostatnio edytowany przez Jacekalex (2015-05-24 19:47:09)
Offline
To z HTTP_HOST nic nie daje -- jest tak samo jak przy SERVER_NAME .
Za to ta druga metoda podziałała, tj. dopisałem do tego vhosta co był już zdefiniowany (na porcie 80):
Redirect permanent / https://morfikownia.lh/
i już wszystko leci na https, a skoro "While the <VirtualHost> solution is recommended because it is simpler and safer," to nie ma co się męczyć z .htaccess. xD Choć w sumie jak ktoś wie jak to przepisać przy pomocy tego mod_rewrite, to zawsze może dopisać.
Ostatnio edytowany przez morfik (2015-05-24 20:34:40)
Offline
Jeżeli przez HTTP_HOST nie działa, to znaczy że masz spartoloną konfigurację Apacha.
Offline
Może nie tyle apacha co samego vhosta? No bo tutaj ma siedzieć testowy wordpress i tam on już trochę ma regułek w pliku .htaccess i może coś tutaj jest tak? Ja wiem, może mu nie pasują permalinki czy coś? xD
EDIT:
Przerzuciłem te dwie linijki (zarówno z SERVER_NAME oraz HTTP_HOST) na początek pliku .htaccess:
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{HTTPS} !=on RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [R,L] ...
I teraz już działa i to na obu. Ciekawe co innego się schrzani w ten sposób. xD
Ostatnio edytowany przez morfik (2015-05-24 21:06:13)
Offline
Raczej Apacha.
Żeby chodził na każdej domenie, trzeba mu (o ile pamiętam) wyłączyć globalnie opcję UseCanonicalName.
http://httpd.apache.org/docs/2.4/mod/core.html#usecanonicalname
A jeśli u Ciebie nie działało przekierowanie na adres SERVER_NAME ani HTTP_HOST, to normalne zachowanie Apacha nie jest (to już sprawa Vhosta).
Ostatnio edytowany przez Jacekalex (2015-05-24 21:19:45)
Offline
Miałem rację ze złą konfiguracją w .htaccess -- widać permalinki mają być ostatnie:
Na takiej konfiguracji działa bez problemu:
# Force SSL, see also apache virtual hosts <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{HTTPS} !=on RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R,L] </IfModule> # Wordpress permalinks <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule>
Jeśli bym zamienił te dwa bloki miejscami, to przestaje po tym przepisywać.
Tak czy inaczej, ten pierwszy blok sobie wykomentuję i będę jechał na konfiguracji via vhost.
Ostatnio edytowany przez morfik (2015-05-24 21:16:03)
Offline
W ogóle htacces jest może ułatwieniem dla firm hostingowych, ale jak można tego nie używać (dostęp do konfiga Vhosta) to najlepiej w ogóle olać htacces.
Offline
@morfik - nic dziwnego że przestaje
sprawdź sobie następnym razem co oznaczają flagi w rewriterule ze szczegolnym uwzględnieniem [L] zanim się zabierzesz za bezmyślne kopiowanie przykładów z neta.
Offline
Nie, w pierwszym też L kończy:
RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R,L]
Magia nie?
A spróbuj pomyśleć co się dalej stanie...
Offline
Z tego co znalazłem w dokumentacji apache, to serwer szuka linijek mających RewriteRule, po czym sprawdza wszystkie linijki wyżej, które mają RewriteCond i jeśli wszystkie te warunki (standardowo) są spełnione, reguła jest aplikowana, po czym serwer analizuje następną regułę i tak do końca pliku. Jeśli regułka ma [L], to po dopasowaniu jej, nie będą już sprawdzane żadne reguły po niej.
Czyli w sumie to nie wiem jak to działa w przypadku wordpressa. xD Niby pierwsze dopasowanie jest na ^(.*) , czyli każdy adres i po tym powinno zakończyć się przetwarzanie reguł. A przecie przepisywany jest ten index.php przy pomocy następnej reguły.
Jeśli wywalę L z:
RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R,L]
To wtedy dostaję komunikat:
Found
The document has moved here.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.[/quote]
Ale i tak nie mogę przejść do faktycznej strony po kliknięciu w "here".
Może mógłbyś napisać mi jak te dwie regułki powinny wyglądać?
Offline
Jeśli działa to znaczy że jest prawidłowo :) Zmieniłbym tylko redirect na R=301.
Można też (jeśli nie bawimy się w naprawianie uniwersalnego świata) zrobić coś w stylu: zamiast
RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R,L]
można wprowadzić explicite nazwę serwera:
RewriteRule ^(.*) https://www.my-super-server.tld/$1 [R=301,L]
O tyle lepsze, że oba url-e - http://www.my-super-server.tld i http://my-super-server.tld - przekierują na ten sam url. Co prawda wordpress potrafi sam zrobić przekierowanie na hosta www.cośtam.tld z cośtam.tld (albo odwrotnie) - jednak jest to dość kosztowne (wordpress do najlżejszych skryptów nie należy, a jeśli ma trochę wtyczek to potrafi nieźle zeżreć zasobów na samo załadowanie) i lepiej to załatwić htaccessem lub konfiguracją vhosta.
Zasady ogólne (chociaż nie przymus - można inaczej):
a) wszelkie redirecty umieszczamy jak najwcześniej
Dlaczego? Najwcześniej - bo najprawdopodobniej żadna z następnych reguł nie będzie pasować, a jeśli nawet to umieszczona wcześniej tylko niepotrzebnie coś zrobi (np. zmieni po swojemu ścieżkę, której zmiana nie jest nam do szczęścia potrzebna a jedynie coś może namieszać, czy nawet - jak w Twoim przypadku przy pierwszych próbach - w ogóle zablokuje redirect).
Praktycznie nie spotyka się sytuacji, gdy przed [R] stoi jakaś reguła z [L] - oprócz oczywistych przypadków redirect i proxy lub wymuszenia innego kodu odpowiedzi (np. 404).
b) wszelkie redirecty opatrujemy flagą L
Dlaczego? - bo najprawdopodobniej po redirect Apacz nie powinien już nic robić tylko zakończyć przetwarzanie requestu z odpowiedzią 30x (zależy od parametru). W przypadku prostych zbiorów reguł (a o takich tu mówimy) możemy założyć że tak ma być w każdym przypadku.
c) dobry zwyczaj nakazuje umieszczenie kodu odpowiedzi przy fladze R (czyli [R=301] lub [R=302]).
Pamiętać należy, że domyślnym dla R jest 302 i przeglądarka (czy też indekser Googla) będzie kolejne żądania wysyłać pod stary adres zamiast przyporządkować sobie na trwale nowy (w Twoim przypadku https:// a nie http://)
A teraz skąd ta magia i skąd działanie reguł znajdujących się za [L].
Otóż żadnej magii tu nie ma i żadne reguły nie działają. Rzecz w tym, że drugi zestaw reguł odnosi się do innego requestu, wysłanego automatycznie przez przeglądarkę w odpowiedzi na 301/302. Czyli:
a) przeglądarka wysyła kod http://cośtam
b) Apacz stwierdza, że trzeba to przekierować na https://cośtam i kończy pracę
c) przeglądarka dostaje odpowiedź z Location zawierającym nowy URL, i samoczynnie wysyła [b]drugi[/b] request zgodny z owym Location (czyli w naszym przypadku https://cośtam)
d) Apacz stwierdza, że to już jest https i nie trzeba przekierowywać, więc pomija tę regułę
e) w tym momencie następuje dopasowanie do następnych reguł.
Można to bardzo ładnie zobaczyć stosując RewriteLog i RewriteLogLevel (tylko uwaga, bo log rewrite puchnie w tempie zastraszającym).
Offline
[b]@morfik[/b]
Weź lepiej schowaj Apacha z a Nginxem, albo w ogóle wyętol Apacha i posadź wp na tym serwerze, potem na porcie 80 robisz np:
server { server_name blog.domena.tld; root /var/www/Wordpress4; listen 0.0.0.0:80; listen [::]:80; return 301 https://$http_host$request_uri; log_not_found off; access_log off; }
Potem na porcie 443 stawiasz Vhosta, na którym konfigurujesz wszystkie potrzebna dla WP opcje, albo do serwowania bezpośredniego, albo rev-proxy dla Apacha.
Offline
ja tam jeszcze między nginxem a apaczem postawił varnisha - przynajmniej porządny cache by był.
zresztą pewnie niedługo coś takiego będę stawiać, jeśli mi wyjdzie to opiszę co i jak.
Offline
Zmieniłbym tylko redirect na R=301.[/quote]
Poprawiłem to, bo z tego co czytam to zwraca domyślnie 302 (tymczasowy).wordpress do najlżejszych skryptów nie należy, a jeśli ma trochę wtyczek to potrafi nieźle zeżreć zasobów na samo załadowanie[/quote]
A tak przy okazji, [b] 55 queries in 0.528 seconds, using 5.09MB memory [/b] to dużo? xDa) wszelkie redirecty umieszczamy jak najwcześniej[/quote]
Przeniosłem to na początek.b) wszelkie redirecty opatrujemy flagą L
Dlaczego? - bo najprawdopodobniej po redirect Apacz nie powinien już nic robić tylko zakończyć przetwarzanie requestu z odpowiedzią 30x (zależy od parametru).[/quote]
No i teraz wszystko stało się jasne, tzn jak działa ten mechanizm. Apache analizuje regułę z redirectem, przepisuje adres, kończy analizę reguł i wysyła nowe żądanie, a że to już ma https, to pomija redirect (bo nie pasuje) i aplikuje permalinki i tam znowu kończy i ten adres zwraca — to mi właśnie umykało. xDOtóż żadnej magii tu nie ma i żadne reguły nie działają. Rzecz w tym, że drugi zestaw reguł odnosi się do innego requestu, wysłanego automatycznie przez przeglądarkę w odpowiedzi na 301/302. Czyli:[/quote]
No właśnie. xDWeź lepiej schowaj Apacha z a Nginxem, albo w ogóle wyętol Apacha i posadź wp na tym serwerze, potem na porcie 80 robisz np:[/quote]
@Jacekalex — przecie apache tam miał milusią dyrektywę: [b]Redirect permanent / https://morfikownia.lh/[/b] , a pozostałe kroki takie sam jak opisałeś. xDOffline
#17 2015-05-27 17:18:27
ethanak - Użytkownik
Re: [Solved]Wymuszenie https w apache
[quote=morfik][...] Apache analizuje regułę z redirectem, przepisuje adres, kończy analizę reguł i wysyła nowe żądanie, a że to już ma https, to pomija redirect (bo nie pasuje) i aplikuje permalinki i tam znowu kończy i ten adres zwraca — to mi właśnie umykało. xD[/quote]
Nie, nie zwraca - po prostu przepisuje sobie adres na nowy wewnętrznie. Zarówno następne reguły, jak i właściwy skrypt po zaaplikowaniu permalinków zachowa się tak, jakby dostał request po przepisaniu - czyli np.Kod:
https://cośtam.tld/index.php?p=12345Przeglądarka nie wie nic o tym przepisanym adresie.
Nim mechaniczne larum zagrasz mi, kanalio,
głosząc nadejście Javy - śmiertelnego wroga!
[i]Zespół Adwokacki Dyskrecja[/i]Offline
Informacje debugowania
Time (s) Query 0.00012 SET CHARSET latin2 0.00004 SET NAMES latin2 0.00102 SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.144.42.174' WHERE u.id=1 0.00100 REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.144.42.174', 1732786730) 0.00035 SELECT * FROM punbb_online WHERE logged<1732786430 0.00083 DELETE FROM punbb_online WHERE ident='3.145.7.253' 0.00067 SELECT topic_id FROM punbb_posts WHERE id=287524 0.00004 SELECT id FROM punbb_posts WHERE topic_id=27429 ORDER BY posted 0.00076 SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=27429 AND t.moved_to IS NULL 0.00005 SELECT search_for, replace_with FROM punbb_censoring 0.00195 SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=27429 ORDER BY p.id LIMIT 0,25 0.00085 UPDATE punbb_topics SET num_views=num_views+1 WHERE id=27429 Total query time: 0.00768 s