Weiterleitung von HTTP auf HTTPS

caticonslite_bm_alt

Im Chromium Blog wurde angekündigt, dass mit Veröffentlichung von Chrome 68 im Juli 2018 alle via HTTP abgerufenen Seiten als „Nicht sicher“ in der Adressleiste gekennzeichnet werden. Dank Diensten wie Let’s Encrypt oder Cloudflare ist die Aktivierung eines SSL- bzw. TLS-Zertifikats heutzutage einfach und kostenlos möglich. Um die Weiterleitung von HTTP auf HTTPS für die Webseite zu aktivieren ist folgende Apache-Konfiguration (z.B in der .htaccess-Datei) erforderlich:

RewriteEngine On
RewriteCond %{HTTP_HOST} =blog.webentwickler.at
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule (.*) https://blog.webentwickler.at/$1 [R=301,L]

Jede RewriteCond muss für die nachfolgende RewriteRule zutreffen, damit diese angewandt wird. In diesem Fall muss der Hostname „blog.webentwickler.at“ lauten und die Environment-VariableHTTPS“ darf nicht „on“ sein und „HTTP:X-Forwarded-Proto“ darf nicht „https“ sein, damit die Weiterleitung auf die HTTPS-Adresse erfolgt. Die Überprüfung von „HTTPS“ ist für direkt auf Apache aufgeschaltete Domains erforderlich, „HTTP:X-Forwarded-Proto“ kommt im Falle eines Reverse-Proxy (z.B. NGINX oder Varnish) oder Cloudflare zum Tragen.

Verwendung von vimdiff als git mergetool

Beim ersten Merge-Konflikt schlägt git zwar i.d.R. ein Mergetool vor, mit dem folgenden Befehl kann vimdiff aber bereits vorab konfiguriert werden:

git config global merge.tool vimdiff

Der Aufruf des Mergetools nach einem Merge-Konflikt (z.B.: „CONFLICT (content): Merge conflict in test.txt“) erfolgt mit:

git mergetool

Daraufhin öffnet sich vimdiff mit mehreren Fenstern (eigentlich: „Buffer“ in der Split-Ansicht), die folgende Bezeichnungen tragen:

  • LOCAL“ (kurz: „LO“): Aktueller Branch/Zweig.
  • BASE“ (kurz: „BA“): Gemeinsamer Vorgänger (Zustand vor LOCAL- bzw. REMOTE-Änderungen).
  • REMOTE“ (kurz: „RE“): Branch/Zweig der mittels „git merge“ mit LOCAL hätte zusammengefügt werden sollen.
  • MERGED“ (bzw. keine Bezeichnung, kurz: „ME“): Gewünschtes Merge-Ergebnis.

Zwischen den Fenstern kann mit „Strg + w“ bzw. „Ctrl + w“ navigiert werden, das ist grundsätzlich nicht erforderlich, da sämtliche Arbeiten in „MERGED“ ausgeführt werden können/sollen.
Die häufigsten erforderlichen Befehle sind (jeweils ohne Anführungszeichen auszuführen):

  • „]c“: Nächster Unterschied.
  • „[c“: Vorheriger Unterschied.
  • „zo“: Text einblenden.
  • „zc“: Text ausblenden.
  • „:diffupdate“: Dateien erneut auf Unterschiede überprüfen.
  • :diffget RE“ (statt „RE“ kann z.B. auch „LO“ angegeben werden): Änderung von „REMOTE“ übernehmen.

Nachdem alle Unstimmigkeiten beseitigt worden sind, können wie gewohnt mit „:wqa“ alle Fenster gespeichert und geschlossen und mit „git commit“ fortgefahren werden.

TYPO3 mit Komprimierung auf Plesk-Host mit Reverse Proxy nginx

caticonslite_bm_alt

Wird in TYPO3 die Frontend-Komprimierung mit „$GLOBALS[‚TYPO3_CONF_VARS‘][‚FE‘][‚compressionLevel‚] = 9″ und in den TypoScript-Setup-Einstellungen „config.compressJs“ bzw. „config.compressCss“ aktiviert, werden statische „pre-rendered“ JavaScript- und CSS-Dateien im gzip-Format im Ordner „typo3temp/compressor“ abgelegt. Für die korrekte Auslieferung ist für Apache (z.B. in der Datei .htaccess) die folgende Konfiguration erforderlich:

<FilesMatch "\.js\.gzip$">
	AddType "text/javascript" .gzip
</FilesMatch>
<FilesMatch "\.css\.gzip$">
	AddType "text/css" .gzip
</FilesMatch>
AddEncoding gzip .gzip

Seit Plesk 12 wird nginx als Reverse Proxy eingesetzt und statische Dateien werden nicht mehr von Apache, sondern direkt von nginx ausgeliefert. Das führt dazu, dass nginx die Dateien zwar mit dem korrekten „Content-Type“, aber ohne erforderliches „Content-Encoding: gzip“ im HTTP-Header ausliefert und infolgedessen die Dateien vom Browser falsch (so als wären sie nicht komprimiert) interpretiert werden. Analog zur o.g. Konfiguration für Apache ist auch eine Konfiguration für nginx erforderlich: In Plesk kann unter „Einstellungen für Apache & nginx“ der Domain entweder die Option „Intelligente Bearbeitung statischer Dateien“ deaktiviert werden (nicht empfohlen), oder folgende Konfiguration unter „Zusätzliche nginx-Anweisungen“ hinterlegt werden:

location ~ "\.js\.gzip$" {
	add_header Content-Encoding gzip;
	gzip off;
	types { text/javascript gzip; }
}
location ~ "\.css\.gzip$" {
	add_header Content-Encoding gzip;
	gzip off;
	types { text/css gzip; }
}

Diese Konfiguration bringt nginx dazu die komprimierten JS- und CSS-Dateien analog zu Apache zu behandeln und das erforderliche „Content-Encoding: gzip“ im HTTP-Header zu setzen.

Active-Klasse für Navigations-Element in Lumen

caticonslite_bm_alt

Da Lumen im Gegensatz zu Laravel für das Routing auf FastRoute setzt, ist es nicht möglich den Active-Helper für Laravel zu verwenden. Allerdings ist das gewünschte Ziel auch mit der Blade-Template-Engine einfach zu erreichen, selbst für „named routes“:

<ul class="nav">
	<li class="{{ (\Request::url() == route('index')) ? 'active' : '' }}"><a href="route('index')">Home</a></li>
	<li class="{{ (\Request::url() == route('advantages')) ? 'active' : '' }}"><a href="route('advantages')">Advantages</a></li>
</ul>

TYPO3 Flow über HTTP- statt GIT-Protokoll mittels Composer laden

caticonslite_bm_alt

Aufgrund von erhöhter Verwendung des Git-Protokolls am Git-Server von TYPO3 wird die Anzahl der maximal erlaubten Verbindungen überschritten und daher Verbindungen vom Server verworfen. Bei der Installation von TYPO3 Flow mittels Composer (z.B. „composer create-project –dev –keep-vcs typo3/flow-base-distribution Quickstart“) äußert sich das mit der folgenden Fehlermeldung:

[RuntimeException]                                                                                                                                                                                                  
Failed to execute git clone --no-checkout 'git://git.typo3.org/Flow/Distributions/Base.git' 'Quickstart/' && cd 'Quickstart/' && git remote add composer 'git://git.typo3.org/Flow/Distributions/Base.git' && git fetch composer  
fatal: read error: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt

Dieses Problem lässt sich umgehen, indem man in Git alternative URLs zur Verwendung konfiguriert. Für typo3/flow-base-distribution ist das:

git config --global url."http://git.typo3.org/Flow/Distributions/Base.git".insteadOf "git://git.typo3.org/Flow/Distributions/Base.git"
git config --global url."http://git.typo3.org/Packages/TYPO3.Flow.git".insteadOf "git://git.typo3.org/Packages/TYPO3.Flow.git"
git config --global url."http://git.typo3.org/Packages/TYPO3.Fluid.git".insteadOf "git://git.typo3.org/Packages/TYPO3.Fluid.git"
git config --global url."http://git.typo3.org/Packages/TYPO3.Eel.git".insteadOf "git://git.typo3.org/Packages/TYPO3.Eel.git"
git config --global url."http://git.typo3.org/Packages/TYPO3.Welcome.git".insteadOf "git://git.typo3.org/Packages/TYPO3.Welcome.git"
git config --global url."http://git.typo3.org/Packages/TYPO3.Party.git".insteadOf "git://git.typo3.org/Packages/TYPO3.Party.git"
git config --global url."http://git.typo3.org/Packages/TYPO3.Kickstart.git".insteadOf "git://git.typo3.org/Packages/TYPO3.Kickstart.git"
git config --global url."http://git.typo3.org/Flow/BuildEssentials.git".insteadOf "git://git.typo3.org/Flow/BuildEssentials.git"
1 2 3 8  nach oben