[HTACCESS] alles naar https
Kan ik gewoon een htaccess in mn root gooien, die alles naar https doorstuurt, ook de subdomeinen?
Ik kan zoiets nog niet vinden of werkend krijgen. Ik heb weinig zin om in elke map een htaccess te zetten (zijn er nogal veel).
mijn mislukte pogingen
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
RewriteEngine On
#RewriteCond %{HTTPS} !=on
#RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
#Header always set Content-Security-Policy "upgrade-insecure-requests;"
#RewriteCond %{HTTPS} off
#RewriteCond %{HTTP:X-Forwarded-Proto} !https
#RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
#RewriteCond %{HTTP_HOST} !^domein\.com [OR]
#RewriteCond %{HTTP:X-Forwarded-Proto} !https
#RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
#RewriteCond %{HTTPS} !=on
#RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
#Header always set Content-Security-Policy "upgrade-insecure-requests;"
#RewriteCond %{HTTPS} off
#RewriteCond %{HTTP:X-Forwarded-Proto} !https
#RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
#RewriteCond %{HTTP_HOST} !^domein\.com [OR]
#RewriteCond %{HTTP:X-Forwarded-Proto} !https
#RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
en in de www map heb ik dit staan en dat werkt prima
Mocht je CloudFlare gebruiken, dan kan je het daar ook afdwingen.
dit werkt generiek voor elke domeinnaam. Dus ook voor subdomeinen.
Als elk subdomein dezelfde documentroot gebruikt, ben je in 1x klaar.
Hij werkt een beetje half. Als ik em wil forceren met http lukt dat ook. Vernieuw ik em dan weer springt ie weer naar https.
Gewijzigd op 13/10/2020 06:53:31 door Michael -
https://websniffer.cc/ of het via http:// netjes redirect naar https://. Als het goed is moet je een redirect zien in de headers.
Probeer dit eens:
Die 301 zorgt ervoor dat er een 'Moved Permanently' header wordt meegegeven.
Kijk eens met Probeer dit eens:
Code (php)
1
2
3
2
3
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Die 301 zorgt ervoor dat er een 'Moved Permanently' header wordt meegegeven.
Gewijzigd op 12/10/2020 13:34:19 door - Ariën -
Gewijzigd op 13/10/2020 06:53:52 door Michael -
En met die 301 header in de .htaccess?
Altijd het zelfde gekloot :/
Of heb je hogerliggend in de directory tree nog een .htaccess staan met iets anders?
Gewijzigd op 12/10/2020 14:29:00 door - Ariën -
Als ik em in htaccess plaats, doet t niks, als ik em in www plaats krijg ik to many redirects.
Kan je het niet testen op een lege domein? Desnoods lokaal aangemaakt met .test extentie en de nodige /etc/host aanpassing?
Accepteert het certificaat wel wildcards?
Ja sinds kort wordt het ondersteund, naar lang zeuren en zonder mededeling :/ @Thomas
Werkt wel voor http://domein.com (Gaat gelijk naar https), maar niet voor de andere mappen (http://www.domein.com, http://sub.domein.com). @Ozzie
Edit: Volgens websniffer werkt ie trouwens helemaal niet. Terwijl t in de browser wel werkt.
Gewijzigd op 13/10/2020 06:55:43 door Michael -
Een of meer van de bovenstaande .htaccess varianten zouden gewoon moeten werken, al ontbreekt er misschien een [OR] achter de eerste RewriteCond in je twee eigen poging. Ik zou vervolgens per (sub)domein gaan kijken wat er aan de hand is. En misschien een hulptool zoals @Ariën voorstelt gebruiken om te kijken wat er precies gebeurt.
@Ozzie, dat werkt wellicht wel, maar misschien is dit niet echt de goede insteek; voor zover ik weet is het prima mogelijk om https via poort 80 te laten verlopen, al is het ongebruikelijk (en misschien andersom ook? geen idee). Een controle op een poort voor de bepaling van het gebruikte protocol (ook al wordt een protocol vaak geassocieerd met een standaard poort) is daarom misschien minder verstandig, het staat in zekere zin los van elkaar.
Gewijzigd op 13/10/2020 09:26:50 door Thomas van den Heuvel
Als het ene niet werkt zul je wat anders moeten proberen. Poort 80 is de standaardpoort voor HTTP en normaliter zal die niet wijzigen, tenzij je dit zelf bewust doet. Als dit werkt lijkt het me dus een prima oplossing.
@Michael
Probeer deze eens:
Ozzie PHP op 13/10/2020 14:12:14:
Poort 80 is de standaardpoort voor HTTP en normaliter zal die niet wijzigen, tenzij je dit zelf bewust doet.
Dat klopt, maar de RewriteRules zouden moeten controleren of HTTPS wel of niet actief is. Dit heeft in principe niets met poortkeuze te maken.
Je kunt niet constateren dat iets een appel is als het geen peer is... en daarom zou je die dus ook niet met elkaar moeten vergelijken :p.
Mijn oplossing (als die werkt) volstaat gewoon prima Thomas. Niet iedere server geeft alle gewenste variabelen mee en dan zul je soms flexibel naar andere oplossingen moeten kijken. Poortnummer volstaat in dit geval prima. Een appel en een peer zijn dan ook niet van toepassing.
Ozzie PHP op 13/10/2020 22:57:14:
Mijn oplossing (als die werkt) volstaat gewoon prima Thomas.
Simpelweg omdat iets werkt maakt het nog niet juist. Het bovenstaande is ook geen opzet die ik naar andere servers zou dupliceren. Als je wilt weten of HTTPS actief is... controleer dan gewoon op het actief zijn van HTTPS? Ik zou zeggen, als je dat niet makkelijk kunt doen dan is er waarschijnlijk meer aan de hand.
Ozzie PHP op 13/10/2020 22:57:14:
Niet iedere server geeft alle gewenste variabelen mee en dan zul je soms flexibel naar andere oplossingen moeten kijken.
Mja, soms zal dat inderdaad moeten, maar dan ben je al bezig met workarounds. In dit geval weet niemand nog precies wat er misgaat. Voordat je een remedie voorschrijft/toepast zul je toch echt eerst moeten weten wat de patiënt mankeert. Ik zou daarom eerst eens kijken wat er allemaal gebeurt tussen request en de uiteindelijke response. Op dit moment is daarvan nog niet echt een analyse?
Wanneer meerdere gangbare oplossingen in .htaccess niet direct werken dan lijkt het mij tijd om je horizon wat te verbreden om te zien wat daarbuiten nog allemaal gebeurt en ligt het waarschijnlijk niet (uitsluitend) aan .htaccess. Daar dan proberen een toverformule voor te vinden die voor alle cases werkt is wellicht niet zo verstandig, omdat je dan nog steeds niet weet wat er precies misgaat.
Dit moet gewoon (uitgezocht en) opgelost worden, het is niet aan .htaccess om dit recht te breien als er elders kinken in de kabel zitten / fouten zitten in de overige configuratie.
Ozzie PHP op 13/10/2020 22:57:14:
Poortnummer volstaat in dit geval prima. Een appel en een peer zijn dan ook niet van toepassing.
Okay, als je blijft volhouden dat een poortnummer en het protocol een en hetzelfde ding zijn en dus ook in het gebruik uitwisselbaar zijn dan zijn we min of meer klaar denk ik.
Wat ik zeg / probeer te zeggen, is dat op een normaal ingerichte server HTTP altijd op poort 80 draait en HTTPS op poort 443. Dat is iets wat altijd zo is, tenzij je dit zelf om een of andere reden hebt gewijzigd. Je kunt dus gewoon kijken of er een signaal binnenkomt op poort 80. Theoretisch zijn een poort en een protocol niet hetzelfde, maar in de praktijk kun je deze oplossing gerust toepassen. Ja, protocol afvangen heeft de voorkeur, maar als je bij een of andere exotische host zit waardoor die servergegevens niet voorhanden zijn, kun je uitwijken naar poortdetectie. Daar is niks mis mee. Ik zeg niet dat het de voorkeur verdient boven vaststellen van het protocol. Het is simpelweg een praktische oplossing, een alternatief.