Umstellung auf SSL/https

[xandi]

wo muss ich denn überall meine domain einfügen?

Code: [Select]

AddDefaultCharset UTF-8
RewriteEngine on

### Pfad zur selbst angelegten 404 Seite angeben und # am Anfang entfernen, ansonsten ist die Zeile unwirksam
#ErrorDocument 404 /pages/error404.php

### HTTPS / SSL / www ###
# First rewrite to HTTPS: Don't put www. here. If it is already there it will be included, if not the subsequent rule will catch it.
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Now, rewrite any request to the wrong domain to use www.
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Könntest du das mal für mich machen. Die domain ist alexanderschwarz.de

Aktuell sieht die httaccess so aus:

Code: [Select]

AddDefaultCharset UTF-8
RewriteEngine on

### Pfad zur selbst angelegten 404 Seite angeben und # am Anfang entfernen, ansonsten ist die Zeile unwirksam
ErrorDocument 404 /pages/error404.php

RewriteCond %{SERVER_NAME} =www.alexanderschwarz.de [OR]
RewriteCond %{SERVER_NAME} =alexanderschwarz.de
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
</IfModule>
Ist das "%" Zeichen der Platzhalter??? Ich bin Bildhauer und kein Programmierer.

[dbs]

Nix ersetzen, einfach alles von mir statt deinem Code. 

[xandi]

Dann passiert genau das gleiche!

Wenn ich meine Seite direkt aufrufe, also www.alexanderschwar z.de, eine unsichere Verbindung angezeigt bekomme.

Wenn ich nun einen Menüpunkt aufrufe z.B. Kontakt oder Arbeite etc, und anschließend die "Startseite" über das Menü, ist plötzlich alles "verschlüsselt" bzw. das grüne Schloß zu sehen.

[dbs]

Du findest mit Google viele Ergebnisse wie man in der htaccess zu www und https umleitet.
Wenn meins nicht funktioniert, dann vielleicht was anderes.

[DarkViper]

Zuerst mal schauen, ob es in Deinem Hosting eine Möglichkeit gibt, alles serverseitig auf https zu zwingen...
Erst wenn das nicht geht, dann:

Code: [Select]

AddDefaultCharset UTF-8
RewriteEngine on

ErrorDocument 404 /pages/error404.php
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

mehr ist nicht nötig.

[evaki]

Bei zweien unserer Domains habe ich es wg. htaccess-Beschränkungen im Template so gelöst:

Code: [Select]

<?php
if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] == "off"){
    $redirect = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
    header('HTTP/1.1 301 Moved Permanently');
    header('Location: ' . $redirect);
    exit();
} header("X-Robots-Tag: noindex, nofollow", true);?>
Den Robots-Tag gabs nur oben drauf, weil auf diesen Seiten nur eine Zusammenfassung von Impressum und DSE existiert. (und irgendwas mit Links -oder so, is schon wieder sooooo weit wech)

Also nur für die Weiterleitung ohne header("....
MfG. Evaki

[dbs]

Mein Google-Hinweis sollte nicht ausdrücken, dass ich dir nicht helfen wöllte. 
Dein Problem hat aber nichts mit WB zu tun, sondern ist eine allgemeine Webgeschichte, deshalb der Hinweis.

[xandi]

@ darkviper:

Zuerst mal schauen, ob es in Deinem Hosting eine Möglichkeit gibt, alles serverseitig auf https zu zwingen...
Erst wenn das nicht geht, dann:

Mein Provider hat mir folgenden Code für diesen Zweck durch gegeben.

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

Auch bei dieser httaccess ist der erste Aufruf der Startseite unverschlüsselt, und wird als sicher nach Aufruf der Startseite über das Menü als verschlüsselt angezeigt??

@dbs:

Kein Problem - ich bin ja froh dass hier versucht wird mir zu helfen!!! 

Ich habe auch eine als universal Lösung angebotene httaccess getestet - aber auch die mit dem gleichen Ergebnis.

Ist vielleicht dämlich, aber kann es mit den Spracheneinstellung en zusammenhängen. Ich habe Probleme mit den Datenbanken bzw. den Spracheinträgen, und finde niemanden der mir hierbei helfen würde. Das gleiche Problem hatte ich mit einer anderen Seite, wobei mir Jakkobi die Datenbank "repariert" hat.

Ich habe dies hier gefunden - vielleicht ist da was dabei.

https://www.selbstaendig-im-netz.de/google/10-schritte-zur-vollstaendigen-https-umstellung-ohne-rankingverlust/

Besonders der Absatz könnte eine Hinweis auf das Problem mit der Datenbank sein:

Alle internen Links ersetzen mit HTTPS in der Datenbank

Alle internen Links müssen ersetzt werden mittels HTTPS. Dies sind Links der eigenen Webseite auf andere Seiten der eigenen Webseite. Dies wird umgestellt, durch ein Suchen und Ersetzen von http://musterseite.de/ durch https://musterseite.de/ in allen Datenbanktabellen der Webseite.
Wichtig ist nur die internen Links zu ersetzen. Würde man komplett alle Links ersetzen (http webseitenweit durch https ersetzen), würden auch externe Links umgestellt, doch externe Seiten verwenden gegebenenfalls kein HTTPS-Protokoll. Dies führt dazu, dass diese Links teilweise nicht mehr funktionieren werden.

Bezieht sich zwar auf WP und nicht WB, ist aber vielleicht ein Ansatz

In der config.php steht auf jeden Fall bereits https://meine_domain

[evaki]

@xandi,
was ist nun mit der von mir vorgeschlagenen Lösung, zumal die bisher bei noch so beschränkten Hosts funktionierte?
MfG. Evaki
p.s. Wo befindet sich auf der Site eigentlich die Datenschutzerklärun g?
yep, gefunden... Suchen sollte man die NICHT müssen.
Im Footer "Impressum & Datenschutzerklärun g" eintragen!

[dbs]

Ist das www mit drin in $_SERVER['HTTP_HOST'] ?
Wenn also jemand ohne www. kommt.

[evaki]

In diesem Falle wird beides umgeleitet.

Code: [Select]

http://www.domain.de
erggibt
https://www.domain.de

http://domain.de
ergibt
https://domain.deMfG. Evaki

[dbs]

Aber wir sind uns doch einig, dass es besser so ist, dass egal wie jemand kommt (mit/ohne www oder https) er bei https://www... landen soll.
Deshalb hab ich 2 Regeln drin, du und manu nur eine.

[evaki]

>>Deshalb hab ich 2 Regeln drin, du und manu nur eine.

Es ging um ein Problem mit der htaccess. Um dem aus dem Weg zu gehen, mußte es je nach Vorgabe (Einzeldatei, CMS-config) universeller sein, und eben an anderer Stelle gelöst werden.

Im gezeigten Beispiel sind beide Versionen erstmal abgesichert, unabhängig von den cms-Einstellungen. -und das ist gut so...

Will man weiteres, kann man das natürlich erweitern, z.B. wg Duplicate Content reduzieren auf www oder ohne.
MfG. Evaki

[xandi]

@xandi,
was ist nun mit der von mir vorgeschlagenen Lösung, zumal die bisher bei noch so beschränkten Hosts funktionierte?
MfG. Evaki
p.s. Wo befindet sich auf der Site eigentlich die Datenschutzerklärun g?
yep, gefunden... Suchen sollte man die NICHT müssen.
Im Footer "Impressum & Datenschutzerklärun g" eintragen!

Zum ersten:
Ich wusste nicht wo ich da eintragen muss? In die config.php ? und soll ich die httacess dann ganz löschen?

Zum footer.

Da muss ich mich erst wieder schlau machen wie das geht! Der Tipp an sich aber sicher wertvoll!!!

[msfrog]

Hallo xandi,
die ganze Geschichte ist eine serverseitige, wenns mit Opera funktioniert, dann sollte es auch mit allen anderen gehen. Bitte doch mal den Support deines Hosters da drüber zu gucken. Alles was du beim Website Baker machen musst, ist das https mit in die Zeile

Code: [Select]

define('WB_URL', 'http://www.alexanderschwarz.de/');zu schreiben. Die muss dann also so aussehen:

Code: [Select]

define('WB_URL', 'https://www.alexanderschwarz.de/');
Alles andere wird über die .htaccess bzw. die vhost-Einstellungen des Servers gemacht.

Apropos... Die .htaccess hast du in der Wurzel deiner Website-Baker-Installation liegen? Also da, wo auch die config.php liegt?

[evaki]

@xandi

xandi: Ich wusste nicht wo ich da eintragen muss? In die config.php ? und soll ich die httacess dann ganz löschen?

Das stand da oben im Text:

Evaki: ...habe ich es wg. htaccess-Beschränkungen im Template so gelöst:

Den Code zu oberst. Die dafür vorgesehehenen Inhalte aus der htaccess nehmen.
Für www oder ohne www im Domainnamen kannste ja weiterhin mit der htaccess "spielen".

xandi: Zum footer.

Unter "Optionen"

MfG. Evaki

[DarkViper]

Aber wir sind uns doch einig, dass es besser so ist, dass egal wie jemand kommt (mit/ohne www oder https) er bei https://www... landen soll.
Deshalb hab ich 2 Regeln drin, du und manu nur eine.

Ob da jetzt ein, zwei, fünf oder gar keine Regel reingehört, ist ohne Kenntnis von Serverkonfiguration etc. eigentlich gar nicht zu sagen..

Was ich jedoch sagen kann, ist dass dbs z.B. bei sich mindestens 2 Regeln zuviel drin hat. (ganz 'zufällig' kenne ich die Systemkonfiguration recht gut)
Sein Server ist so ausgelegt, dass dieser weder .htaccess noch sonstige 'Hilfsmittel' braucht um alles richtig zu machen.
Jeglicher Aufruf (mit/ohne 'www', mit/ohne SSL) landet durch das Zusammenspiel von DNS und Servereinstellungen automatisch bei  https://example.com.
Eventuell nötige Umleitungen erfolgen immer per 301-moved permanently (meist nur beim ersten Seitenaufruf erforderlich).
Die sinnvollste Einstellung in der config.php von WB wäre in diesem Fall ebenfalls https://example.com. Selbstverständlich kann auch  https://www.example.com eingetragen werden, ist nur nicht optimal.

Weshalb jetzt das Ziel immer bei https://example.com und nicht bei https://www.example.com ?

Die Ursache liegt in der Art und Weise, wie die meisten Webserver die Domainkonfiguration handhaben.
In einer SharedHosting-Umgebung (normales Webhosting) wird beim Anlegen einer neuen Domain wird immer ein Webspace angelegt, der i.d.R. auf die eigentliche Domain, meist also example.com definiert wird.
Der zugehörige Abschnitt der http.conf bzw. vhost.conf könnte dann im Grundzug grob etwa so aussehen:

Code: [Select]

<VirtualHost *>
    ServerName    example.com
    ServerAlias   www.example.com

    DocumentRoot  /var/www/vhosts/example.com/httpdocs
</VirtualHost>
Das 'www' ist also meist kein eigenständiger vHost, sondern einfach nur ein Alias für die Hauptdomain.
Die Behandlung eines Aliases benötigt etwas mehr Zeit, als die der Hauptdomain.

Umleitungen in einer .htaccess sind grundsätzlich deutlich langsamer als die Nutzung der *.conf Dateien.
Folglich sollte man im Hinblick auf die Performance des Servers .htaccess-Umleitungen die nicht 'lebensnotwendig' sind möglichst vermeiden. Jeder Eintrag in die .htaccess kostet Zeit!

Aber wie bereits gesagt: Man sollte den Einsatz von .htaccess auf das notwendigste beschränken (auch wenn noch so 'geile', 200 Zeilen lange  Monsterscripte im Netz empfohlen werden..). Letztlich sollten die Konfiguration des Server sowie nur wirklich notwendige Anpassungen bestimmten, ob und was man in die .httaccess aufnimmt.

Nebenbei freut sich Tante Google über jede 301-Umleitung, die nicht eingebaut wurde....

[xandi]

Hallo zusammen.

Ich habe mich mit dem Problem an meinen Provider gewandt.

Er hat mir eine httaccess geschrieben und nun funktioniert es wunderbar.

Danke an alle Helfer!! 

[evaki]

Dafür hättest Du die Helfer nicht gebraucht.
Und -mit Verlaub- völlig sinnfrei ist die Mitteilung auch, weil eine hosterspezifische Lösung, wenn es denn eine ist, zu "Gut zu wissen" gehört. Das hilft den zukünftigen Fragestellern
MfG. Evaki

[dbs]

Wie ist die Lösung? Warum muss man extra danach fragen?

[xandi]

   sorry.

Bin noch im Jetlag, war ein sehr langer Flug und ich wollte mich schnell bedanken!

AddDefaultCharset UTF-8
RewriteEngine On

RewriteCond %{HTTP_HOST} !^domainname\.de$ [NC,OR]
RewriteCond %{HTTPS} =off
RewriteRule ^(.*)$ https://domainname.de/$1 [R=301,L]

domainname = habe ich beispielhaft für die Websiteadresse ersetzt 

Euere Hilfe war nicht  unnötig - zuerst hatte ich ja beim Provider angefragt und auch eine httaccess erhalten. Nur hat die nicht funktioniert!!!!!

Die erneute Anfrage an den Support hatte ich dann zuletzt aus Verzweiflung gestartet (eigentlich ohne viel Hoffnung). Umso schöner dass ich jetzt ein Problem weniger habe.
Ich hoffe damit werde ich wieder in den Kreis der unterstützten Unwissenden aufgenommen 


Nun muss ich noch eine "gesetzestreue" Lösung für meine Newletterabonnenten finden. 

[dbs]

Danke, für mich wäre der Fall hier noch nicht erledigt.
Und für Google hast du genau 2 Webseiten, einmal mit und einmal ohne www davor.
Aber damit kannst du wohl leben.

[xandi]

Du hattest recht dass ich damit leben kann. Aber ich habe noch weitere Webseiten.

Die Geschichte geht leider weiter.
Ich habe für meine Domain www.portaitbildhaue r.de zusätzlich noch die Adresse mit Umlaut gekauft/gemietet. Die heißt dann www.porträtbildhauer.de

Angesprochen werden diese über die Domainveraltung von Hetzner. Das heißt man setzt für die entsprechende domain ein Häkchen auf welche WB - Installation (oder andere) verweisen soll.  Soweit so gut.

In meiner Installation steht in der config.php 

define('WB_URL',          'https://www.portraitbildhauer.de');

Wenn ich nun die Seite mit entsprechender httaccess aufrufe, passiert keine Verschlüsselung.

AddDefaultCharset UTF-8
RewriteEngine On

RewriteCond %{HTTP_HOST} !^portraitbildhauer\.de$ [NC,OR]
RewriteCond %{HTTPS} =off
RewriteRule ^(.*)$ https://portraitbildhauer.de/$1 [R=301,L]

Bei einer "untersuchung" mit FF kommt in den allgemeinen Informationen der Hinweis

https://www.portraitbildhauer.de/templates/oiphyx/preview.jpg

.
Für mich sieht es aus als würde das richtige Template angesprochen werden und zwar mit https !
Unter Medien allerdings ist alles in http ??
Hier ein paar Bespiele:

http://www.portraitbildhauer.de/templates/oiphyx/img/wrapperbg.png
http://www.portraitbildhauer.de/templates/oiphyx/img/print.png
http://www.portraitbildhauer.de/templates/oiphyx/img/search.png
http://www.portraitbildhauer.de/templates/oiphyx/img/oiphyxheader.jpg

Woran kann denn das liegen.

Mein Provider schreibt:

Sehr geehrter Herr Schwarz,

Sie müssen Ihre beiden Webseiten so konfigurieren, dass die vom CM-System erzeugten Links immer auf eine bestimmte Domain verweisen - die, für die Sie SSL bestellt haben. Alternativ bestellen Sie für die anderen auch SSL, allerdings wäre Ersteres der technisch korrekte Weg.

[evaki]

Es gibt anscheinend noch andere Probleme, z.B.
Cross site scripting Fehler in Seite
https://porträtbildhauer.de/pages/materialien.php
Falls dies die einzige Seite mit der Minigallery ist, würd ich darauf tippen.

Ach ja, Word-Dokumente gehören auch nicht per C&P eingefügt, das ist Schrott.

Ich leg mich wieder hin. Andere Meldungen sehen auch nicht rosig aus.
Bei https die Google-Font per http zu ziehen ist auch nicht wirklich schön.
Selbst gehostet gäbs auch weniger in die DSE(DSGVO) zu schreiben.

Dann mal viel Spaß, Evaki

[DarkViper]

.. und ich dachte immer, dass wir Frauen nicht logisch denken würden....   

In Deiner .htaccess sorgst Du ganz klar dafür, dass alle Seiten Deiner Installation definitiv mit https://portraitbildhauer.de/###### aufgerufen werden. Das ist soweit ja völlig in Ordnung.
Nur sollte in einem solchen Fall auch exakt die selbe URL z.B. in der config.php stehen (define('WB_URL', 'https://portraitbildhauer.de');). Und zwar exakt wie in der .htaccess auch ohne das www !
Das selbe gilt selbstverständlich natürlich auch für sämtliche Stellen in den Templates etc., an denen die volle URL hardgecodet eingesetzt ist.
Wenn dann noch der RelUrl-Outputfilter aktiviert ist, dürfte es da keine Probleme mehr geben.

Code: [Select]

<link href='https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz:700' rel='stylesheet' type='text/css' />
//--------------
<meta property="og:image" content="<?php echo WB_URL; ?>/templates/oiphyx/preview.jpg" />
//--------------
<div class="infobox">
    <div class="wstitle"><a class="logo" href="<?php echo WB_URL; ?>">Die Porträtbildhauer - Kopfsachen</a></div>
//--------------
<div class="borderbox"><div class="breadcrumbs"><a href="<?php echo WB_URL; ?>">Start</a>
//--------------
<div id="menu"><ul><li><a href="<?php echo WB_URL; ?>" class="menu-sibling menu-first pid1">

(vielleicht hab ich noch ein paar Stellen übersehen..... )

Wenn die Umschaltung auf https jetzt auch noch mit http://www.portrai.... funktionieren soll, muss noch eine weitere Zeile in die .htaccess rein

Code: [Select]

AddDefaultCharset UTF-8
RewriteEngine On

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

Und damit's nicht langweilig wird:
wenn Du immer und überall die Domain mit https://www.portraitbildhauer.de aufgerufen haben willst, dann ist das mit 2 kleinen Änderungen erledigt:

Code: [Select]

// in .htaccess die RewiteRule anpassen
RewriteRule ^(.*)$ https://www.portraitbildhauer.de/$1 [R=301,L]

//in  config.php die WB_URL anpassen
define('WB_URL', 'https://www.portraitbildhauer.de');
that's all..