Monatliche Archive: November 2013

Aktualisierung von Webseiten

Sobald ein Kunde Kenntnis davon erhält, dass beispielsweise für das bei ihm eingesetzte Content Management System (CMS) ein Update zur Verfügung steht, möchte dieser das installiert wissen. Meines Erachtens ist es nicht erforderlich jede Version zu installieren, da Updates neben Fehlerbehebungen auch neue Fehler beinhalten und somit mit einem gewissen Risiko verbunden sind. Ein Update/Upgrade empfehle ich nur aus folgenden Gründen:

  1. Für die eingesetzte Version gibt es keine Sicherheitsupdates mehr.
  2. Die eingesetzte Version weist eine Sicherheitslücke auf, die mit der aktuelleren Version behoben wird.
  3. Die eingesetzte Version enthält einen auftretenden Bug, der mit der aktuelleren Version behoben wird.
  4. Die neuere Version enthält Features, die in der eingesetzten Version nicht zur Verfügung stehen und benötigt werden.
  5. Sicherstellung einer einfachen Migration auf zukünftige Versionen.

NGINX als SSL-Wrapper

caticonslite_bm_alt

NGINX ist bekannt für seine gute Performance und ideal, um als Reverse Proxy bzw. Load Balancer vor speicherintensiven Anwendungsservern (z.B. Apache mit PHP) eingesetzt zu werden und in diesem Zuge auch die HTTPS-Verbindung zu terminieren, damit sich die Anwendungsserver nicht mehr darum kümmern müssen. Um NGINX als SSL-Wrapper einzusetzen ist folgende Konfiguration erforderlich:

server {
        listen 80;
        server_name domain.tld;
 
        return 301 https://domain.tld$request_uri;
}
 
server {
        listen 443;
        server_name domain.tld;
 
        ssl on;
        ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
        ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
        ssl_session_timeout 5m;
        ssl_protocols SSLv3 TLSv1;
        ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
        ssl_prefer_server_ciphers on;
 
        location / {
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_pass http://10.0.0.1/;
        }
}

Die erste server-Anweisung dient dazu alle HTTP-Anfragen auf HTTPS umzuleiten – „domain.tld“ ist selbstverständlich mit der eigenen Domain zu ersetzen. Sollte neben HTTPS auch HTTP möglich sein, ist diese Konfiguration nicht erforderlich und kann weggelassen werden.

Die zweite server-Anweisung behandelt alle HTTPS-Anfragen und leitet diese im sicheren internen Netz auf den Anwendungsserver „10.0.0.1“ via HTTP-Protokoll weiter. Die Zertifikats- und Schlüsseldatei ist, genauso wie die Adresse des Anwendungsservers, an die eigene Infrastruktur anzupassen. Das Ursprungsprotokoll und die Ursprungsadresse werden als X-Forwarded-Proto bzw. X-Forwarded-For HTTP-Header an den Anwendungsserver weitergeleitet und können somit in der Anwendung entsprechend behandelt werden, z.B. um absolute Links für das verwendete Protokoll zu generieren.

In diesem Fall wurde der Einfachheit halber das automatisch erstellte Snakeoil-Zertifikat von Debian verwendet. Die Installation erfolgt mit „apt-get install ssl-cert“, die Verwendung kann im ubuntuusers.de-Wiki nachgelesen werden.

Mehrsprachigkeit in TYPO3 konfigurieren

caticonslite_bm_alt

Um Mehrsprachigkeit in TYPO3 zu aktivieren sind mehrere Schritte erforderlich. Der hier dargestellte Weg zeigt eine mögliche Variante auf, besonders hinsichtlich RealURL sind viele unterschiedliche Konfigurationen möglich.

1. Sprache im Backend aktivieren:

Im Modul „Web > Liste“ (engl. „Web > List“) wählt man die Rootseite mit der ID „0“ (Seite mit vorangestelltem TYPO3-Symbol) aus. Nun fügt man einen neuen Datensatz vom Typ „Alternative Seitensprache“ (engl. „Website language“) ein und füllt die erforderlichen Felder aus. Die hier festgelegten Werte haben keinerlei Relevanz für die weitere Konfiguration, sondern dienen nur der Unterscheidung für Benutzer. Nach dem Speichern sucht man sich die Objekt-ID(s) im Modul „Web > Liste“ der angelegten Sprachen heraus, z.B. indem man mit der Maus auf die gewünschte Flagge zeigt. Die Standardsprache ist nicht anzulegen und hat implizit die ID 0 – in diesem Fall ist dies „Deutsch“. Als alternative Sprachen wurden „English“ mit der ID 1 und Italiano mit der ID 2 angelegt.

2. TypoScript-Setup:

config {
	linkVars = L(0-2)
	uniqueLinkVars = 1
	defaultGetVars.L = 0
	language = de
	locale_all = de_AT.UTF-8
	sys_language_uid = 0
	htmlTag_langKey = de
}
[globalVar = GP:L = 1]
	config {
		language = en
		locale_all = en_GB.UTF-8
		sys_language_uid = 1
		htmlTag_langKey = en
	}
[globalVar = GP:L = 2]
	config {
		language = it
		locale_all = it_IT.UTF-8
		sys_language_uid = 2
		htmlTag_langKey = it
	}
[global]

Die Einstellung „linkVars“ legt hier fest, dass der Parameter „L“ im Wertebereich 0-2 bei der Erzeugung von Links immer berücksichtigt wird. Hat man mehr oder weniger Sprachen, muss der Wertebereich entsprechend angepasst werden. Damit Parameter in der URL nur ein Mal vorkommen, wird „uniqueLinkVars“ aktiviert, andernfalls könnten URLs im Format „?L=0&L=2“ erzeugt werden.

Die Zahlen in den Bedingungen/Conditions (z.B.: „[globalVar = GP:L = 1]“) und für den Parameter „sys_language_uid“ (z.B.: „sys_language_uid = 1“) entsprechen den IDs der im ersten Schritt angelegten Sprachen.

Der Parameter „locale_all“ muss an die installierten Systemsprachen angepasst werden und ist erforderlich um beispielsweise das Datum in der korrekten Sprache auszugeben.

3. RealURL: (Die Konfiguration ist hier nur auszugsweise dargestellt):

// [...]
'preVars' => array(
	// [...]
	'GETvar' => 'L',
	'valueMap' => array(
		'de' => 0,
		'en' => 1,
		'it' => 2,
	),
	'noMatch' => 'bypass',
	// [...]
),
// [...]

Damit die 404-Fehlerbehandlung auch auf der ersten Ebene korrekt funktioniert, muss für alle „preVars“ die Option „’noMatch‘ => ‚bypass'“ aktiviert und es darf „postVarSet_failureMode“ nicht gesetzt sein.

4. Sprachkürzel in der URL:

Die gezeigte Konfiguration würde für die Default-Sprache Links im Format „domain.tld/seite/“ generieren, Links für zusätzliche Sprachen im Format „domain.tld/sprache/seite/“ (z.B.: „domain.tld/en/page/“). Möchte man auch bei der Standardsprache das Kürzel in der URL haben, muss man mit dem TypoScript-Setup „config.defaultGetVars.L = 0“ den Standardwert setzen. Würde man in der RealURL-Konfiguration anstelle für „’noMatch‘ => ‚bypass'“ die Option „‚valueDefault‘ => ‚de'“ setzen, würde man zwar das selbe URL-Format erreichen, allerdings würde die 404-Fehlerbehandlung auf der ersten Ebene nicht mehr funktionieren.

 nach oben