[HTACCESS] alles naar https

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Michael -

Michael -

12/10/2020 12:36:09
Quote Anchor link
Hoi,

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)
PHP script in nieuw venster Selecteer het PHP script
1
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]


en in de www map heb ik dit staan en dat werkt prima
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
RewriteCond %{HTTP_HOST} !^domein\.com [OR]
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://domein.com/$1 [R=301,L]
 
PHP hulp

PHP hulp

21/11/2024 15:32:13
 
- Ariën  -
Beheerder

- Ariën -

12/10/2020 12:42:40
Quote Anchor link
Het ligt eraan hoe de subdomeinen zijn geconfigureerd. Maar als die in de webroot uitkomen, dan zou dit prima moeten werken.

Mocht je CloudFlare gebruiken, dan kan je het daar ook afdwingen.
 
Ivo P

Ivo P

12/10/2020 12:43:32
Quote Anchor link
ik plak net in mijn document root

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]


dit werkt generiek voor elke domeinnaam. Dus ook voor subdomeinen.
Als elk subdomein dezelfde documentroot gebruikt, ben je in 1x klaar.
 
Michael -

Michael -

12/10/2020 13:05:14
Quote Anchor link
Thanks.
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 -
 
- Ariën  -
Beheerder

- Ariën -

12/10/2020 13:08:08
Quote Anchor link
Kijk eens met 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:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
RewriteEngine On
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 -
 
Michael -

Michael -

12/10/2020 13:20:38
Quote Anchor link
Zo te zien niet *url verwijdert*
Gewijzigd op 13/10/2020 06:53:52 door Michael -
 
- Ariën  -
Beheerder

- Ariën -

12/10/2020 13:33:50
Quote Anchor link
En met die 301 header in de .htaccess?
 
Michael -

Michael -

12/10/2020 13:58:33
Quote Anchor link
Die staat erin. Werkt ook niet.
Altijd het zelfde gekloot :/
 
- Ariën  -
Beheerder

- Ariën -

12/10/2020 14:28:43
Quote Anchor link
Staat mod_rewrite uberhaupt wel aan?
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 -
 
Michael -

Michael -

12/10/2020 16:00:33
Quote Anchor link
Ja er staan wel htacccess bestanden in bijna elke sub met rewriterules, maar dat zou toch niet moeten uitmaken.
Als ik em in htaccess plaats, doet t niks, als ik em in www plaats krijg ik to many redirects.
 
- Ariën  -
Beheerder

- Ariën -

12/10/2020 16:19:15
Quote Anchor link
Als je .htaccess bestanden in een subdirectory hebt staan, dan maakt het voor de parent niet uit.
Kan je het niet testen op een lege domein? Desnoods lokaal aangemaakt met .test extentie en de nodige /etc/host aanpassing?
 
Thomas van den Heuvel

Thomas van den Heuvel

12/10/2020 17:07:22
Quote Anchor link
Accepteert het certificaat wel wildcards?
 
Ozzie PHP

Ozzie PHP

13/10/2020 00:52:45
Quote Anchor link
Probeer eens als volgt:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
 
Michael -

Michael -

13/10/2020 06:53:11
Quote Anchor link
Nee dat gaat niet @Arien

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 -
 
Thomas van den Heuvel

Thomas van den Heuvel

13/10/2020 09:24:43
Quote Anchor link
Het klinkt meer en meer alsof er mogelijk (server?)configuratie is op specifieke subdomeinen die roet in het eten gooien. Of wellicht logica in de websites zelf die zorgen voor redirects, wellicht hard-coded hyperlinks die geen rekening houden met een ander protocol (https)?

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
 
Ozzie PHP

Ozzie PHP

13/10/2020 14:12:14
Quote Anchor link
>> Een controle op een poort voor de bepaling van het gebruikte protocol is daarom misschien minder verstandig.

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:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]
 
Thomas van den Heuvel

Thomas van den Heuvel

13/10/2020 16:06:37
Quote Anchor link
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.
 
Ozzie PHP

Ozzie PHP

13/10/2020 22:57:14
Quote Anchor link
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.
 
Thomas van den Heuvel

Thomas van den Heuvel

13/10/2020 23:57:14
Quote Anchor link
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.
 
Ozzie PHP

Ozzie PHP

14/10/2020 00:14:50
Quote Anchor link
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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.