Umstellung auf SSL/https

[xandi]

@ dbs - ich habe eine private Nachricht geschickt  -  danke

@evaki

Ja. Du hast recht.

Ganz unwissend bin ich nicht - ich habe sogar mal einen Kurs bei Rübenwurzel in echt (analog) gemacht.

Vorher und auch danach habe ich meine Seiten mit Dreamweaver erstellt. Einige html - Dinge sind mir geläufig, ebenso css. Nur halt kein php.

Und bisher konnte ich auch viele Probleme oder spezielle Anpassungen dank der Hilfe aus dem Forum erledigen. Ja, doch.

Selbst meine Hauptseite läuft jetzt verschlüsselt.

Aber die Umstellung auf SSL dieser Seite und Cookie Hinweise überfordern mich eben doch. Leider ist es nicht mit ein paar Zeilen config.php getan.

Ich höre auf hier rum zu jammern und hoffe das dbs mir helfen kann 

[dbs]

Wenn du mir FTP Zugang gibst kann ich mal schauen.
Als Dankeschön, falls du zufrieden bist, kannst du gern einen Betrag deiner Wahl an WB per PayPal spenden.
Bei Unzufriedenheit kommt eine gesalzene Rechnung. 

[evaki]

>>...das wäre für Unwissende
Das könnte man gelten lassen, wenn -und das gilt für jedes CMS-
1.) der Server entsprechend der Anforderungen des CMS konfiguriert ist
2.) das CMS installiert ist
3.) Das gewünschte Template fertiggestellt und installiert ist
4.) Dann müßten die erforderlichen Kenntnisse für's CMS (+Server-/Internetregeln) vorhanden sein, um Inhalte, also Texte und Medien internetgerecht aufzubereiten.

Dabei ist nicht berücksichtigt, welche Kenntnisse durch den Computergebrauch erworben wurden, aber absolut unwissend geht man sicherlich nicht daran. Nicht wenige, die sich daran wagen, was auch im Forum nachzulesen ist, stürzen sich ohne die o.a. Vorkenntnisse rein, und wundern sich z.B. darüber, daß das alles ein wenig anders als auf dem Windows-PC, siehe Punkte 1-4. Da liegt es nah, daß man sich schnell überfordert, besonders, wenn man  dann auch noch anderes als das zu tun hat. Das ist aber leider keine gute Voraussetzung. Dennoch haben viele die Tips von Forenteilnehmern umsetzen können, weil man mit ein wenig Logik und ohne Programmierkenntnisse diese Tips umsetzen kann. Das klappt aber keinesfalls im PANIK-Modus.
MfG. Evaki

[xandi]

Danke für die sehr ausführliche Hilfestellung-

Ich habe die config geändert in

define('WB_URL',          'https://www.portraitbildhauer.de'); // no trailing slash or backslash!!

wobei ich nicht ganz verstehe, in deinem ersten Abschnitt soll ich ohne www. schreiben, dann doch wieder. Deshalb habe ich auf den letzten Abschnitt beschränkt.

Die httacess habe ich so geändert:

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://www.portraitbildhauer.de/$1 [R=301,L]

Für deinen ersten Codeabschnitt bin ich davon ausgegangen dass er sich auf die index.php des Templates bezieht.

Da habe ich versuchshalber alle Codeschnipsel die

href="<?php echo TEMPLATE_DIR; ?>

in php echo WB_URL geändert.

Dann kam die Meldung dass in Zeile 54 ein Fehler vorliegt.

Was soll ich sagen. Ich kann kein php!  Als ich mit WB angefangen habe dachte ich das wäre für Unwissende. Wenn ich aber im Quellcode herumschreiben soll/muss, dann macht das keinen Sinn weil ich nicht weiß was ich tue.

Wer könnte mir eine Angebot (bezahlbar - ich kämpfe mich als Bildhauer so durch) machen und den Kram für mich sauber erledigen.
Bin für jeden Tipp dankbar.

[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 Expand


<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 Expand


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 Expand


// 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..

[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

[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.portaitbildhauer.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.

[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]

   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]

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

[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

[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!! 

[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 Expand


<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....

[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

[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 Expand

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

Code Select Expand

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?

[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ärung?
yep, gefunden... Suchen sollte man die NICHT müssen.
Im Footer "Impressum & Datenschutzerklärung" 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!!!

[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

[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]

In diesem Falle wird beides umgeleitet.

Code Select Expand

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

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

[dbs]

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

[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ärung?
yep, gefunden... Suchen sollte man die NICHT müssen.
Im Footer "Impressum & Datenschutzerklärung" eintragen!

[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 Spracheneinstellungen 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

[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.

[evaki]

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

Code Select Expand

<?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

[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 Expand


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.