Debacher-Blog

Uwes Weblog für Texte die (noch) nicht ins Wiki passen
Jan 19

Es ist nicht ganz einfach Informationen zu finden, wie man bei Typo3 zu korrekten Fehlerseiten kommt, die auch einen 404er Fehlercode zurückliefern, vor allem wenn man mit simulatestatic arbeitet. Untersuchen kann man den gelieferten Fehlercode übrigens recht einfach mit der Firefox-Extension Firebug. In der Rubrik Netzwerk wird dort bei einem Seitenaufruf auch der Statuscode mit angezeigt.

Es gibt bei Typo3-Seiten eigentlich zwei unterschiedliche Situationen:

  1. Typo3 wird direkt (/index.php?id=000) oder indirekt (/000.html) mit einer illegalen id aufgerufen
  2. Die Domain wird mit einer URL aufgerufen, die nicht zur Typo3-Installation passt, z.B. mit einem Unterverzeichnis (/mediawiki/..)

Der erste Fall ist relativ einfach zu regeln, man erstellt in Typo3 eine Fehlerseite (hier fehler404.html) und erweitert die Konfigurationsdatei typo3conf/localconf.php folgendermaßen:

[FE][pageNotFound_handling] = /fehler404.html
[FE][pageNotFound_handling_statheader] = HTTP/1.0 404 Not Found

Damit wird für den Fall einer illegalen id die Fehlerseite aufgerufen und ein 404er Fehlercode zurückgeliefert.

Bleibt noch der zweite Fall. Typo3 würde in der Regel die Startseite liefern, egal was aufgerufen wurde. War in der aufgerufenen URL ein Unterverzeichnis angegeben, so wird das in dem Sinne berücksichtigt, dass Typo3 das Stylesheet nicht mehr findet. Die ausgelieferte Seite sieht also ganz komisch aus.

Um das zu ändern muss man an die Datei .htaccess ran, die man für simulatestatic ja aktivieren musste. Hier die .htacess, so wie sie von Typo3 geliefert wurde, ich habe alle Kommentarzeilen entfernt. Verändert habe ich lediglich die vorletzte Zeile:

<FilesMatch "\.(js|css)$">
  <IfModule mod_expires.c>
    ExpiresActive on
    ExpiresDefault "access plus 7 days"
  </IfModule>
  FileETag MTime Size
</FilesMatch>

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)\.(\d+)\.(php|js|css|png|jpg|gif|gzip)$ $1.$3 [L]

RewriteRule ^(typo3/|t3lib/|fileadmin/|typo3conf/|typo3temp/|uploads/|favicon\.ico) - [L]

RewriteRule ^typo3$ typo3/index_re.php [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule .* index.php?id=000 [L]

</IfModule>

In vielen Versionen der Datei werden nur Dateien mit der Endung .html ersetzt (RewriteRule ^[^/]*\.html$ index.php), hier wird jetzt immer die index.php aufgerufen, wenn die ursprüngliche Datei nicht gefunden wurde. Die index.php wird aber mit einer illegalen id aufgerufen, so dass ein Fehler nach Punkt 1 erzeugt wird. Typo3 wertet die übergebene id als String aus und nicht numerisch, eine id 000 wird es als sicherlich nicht geben, da beim Erzeugen einer Seite die id numerisch festgelegt wird. Die Idee dazu stammt von http://typo3.toaster-schwerin.de/typo3_dev/2008_04/msg00492.html.

Sofern die ursprünglich aufgerufenen id gültig war, spielt diese fehlerhafte id keine Rolle. Eine Erklärung dafür habe ich nicht, eventuell hat das etwas mit der Auswertungsreihenfolge von GET/POST Daten zu tun. Von daher ist nicht sichergestellt, dass dieser Trick auch in zukünftigen Typo3-Versionen funktioniert.

Ein Problem gibt es aber, wenn ein Slash (/) im Dateinamen auftaucht, dann gibt es zwar einen korrekten 404er Returncode, aber eine nackte Fehlerseite, da wieder das CSS nicht gefunden wird.

Mit

RewriteRule ^[^/]*\.html$ index.php [L]

stattdessen werden nur Adresse ohne Slash (/) ersetzt, bei anderen Adressen wird die Fehlerseite des Apache gezeigt, mit korrektem Fehlercode. Nun gibt es zwei unterschiedliche Fehlerseiten, einerseits die in Typo3, andererseits die vom Webserver. In beiden Fällen wird aber ein korrekter Fehlercode geliefert.

 

Dez 16
Shell in a box
icon1 debacher | icon2 linux, Tipps und Tricks | icon4 12 16th, 2010| icon3No Comments »

In manchen Netzwerke sind alle Ports gesperrt. Aber die Ports 80 und meist auch 443 sind zumindest über einen Proxy erreichbar. Diese Situation kann man ausnutzen, um trotzdem eine SSH-Verbindung auf den eigenen Rechner zu  ermöglichen. Das Programm shellinabox leistet alles was man braucht.

Auf der Seite http://code.google.com/p/shellinabox/downloads/list sind aktuelle Programmpakete verfügbar, auch ein Debian-Paket für Ubuntu. Dieses Paket kann man durch Anklicken des Links auf der Website mittels GDebi installieren.

Normalerweise lauscht shellinabox auf dem etwas ungewöhnlichen Port 4200, der nicht unbedingt über alles Proxy-Server erreichbar ist. Sofern der lokale Webserver den Port 443 nicht nutzt kann man shellinabox auch auf diesem Port lauschen lassen. Eine Anleitung dazu findet sich unter https://help.ubuntu.com/community/shellinabox.

Letztendlich muss man nur in der Konfigurationsdatei

/etc/default/shellinabox

die Portangabe ändern und das Programm dann mittels

invoke-rc.d shellinabox restart

neu starten.

Von außen ist shellinabox dann mittels:

https://mein-rechner.meine-domain

erreichbar.

Mrz 14

Da in meinen Webserver-Log-Dateien häufiger Anfragen nach Dateien namens wpad.dat auftauchten habe ich mich mal mit dem Thema Web Proxy Autodiscovery Protocol (WPAD) beschäftigt. Positiv daran ist, dass es als Webstandard gilt und von allen aktuellen Browsern unterstützt wird. WPAD benutzt Proxy Auto-Configuration (PAC) Dateien um die Einstellungen zu übermitteln.

Diese Dateien dienen dazu Browser automatisch zu konfigurieren, so dass sie sich die Proxy-Einstellungen selbständig erfragen können. Grundlage dafür ist eine Konfigurationsdatei namens wpad.dat, die im einfachsten Fall folgenden Inhalt besitzt:

function FindProxyForURL(url, host)
{
  if(isPlainHostName(host) || localHostOrDomainIs(host, "localhost") ||  localHostOrDomainIs(host, "127.0.0.1") || isInNet(host, "192.168.1.1", "255.255.0.0")) {
     return "DIRECT";
  }else {
     return "PROXY 192.168.1.1:3128";
  }
}

Im Prinzip wird hier in der letzten Zeile die Adresse und der Port des Proxy-Server übergeben. Der Teil davor umgeht den Proxy-Server, wenn ein Rechnername ohne Domain aufgerufen wird, der Name oder die IP für localhost oder ein Rechner aus dem lokalen Netz.

Detaillierte Informationen findet man unter http://findproxyforurl.com und natürlich http://de.wikipedia.org/wiki/WPAD.

Diese Datei muss nun nur noch zum Browser kommen. Dazu muss der Browser passend eingestellt sein: Bearbeiten -> Einstellungen -> Erweitert -> Netzwerk -> Verbindung -> Einstellungen -> Die Proxy-Einstellungen für dieses Netzwerk automatisch erkennen

Nun muss auf dem Server noch der Webserver-Apache entsprechend konfiguriert werden. Er sollte im Idealfall auf folgende URL hin die Datei ausliefern: http://wpad.<rechnername.lokale-domain>/wpad.dat In den meisten Installationen langte es sicherlich im Nameserver einen cname für wpad einzurichten:

wpad       CNAME   boss

Zusätzlich wird noch empfohlen die zugehörigen Mime-Types zu registrieren. Dazu kommen folgende Zeilen in die bisher leere Datei /etc/apache2/httpd.conf:

AddType application/x-ns-proxy-autoconfig .dat
AddType application/x-ns-proxy-autoconfig .pac
Redirect permanent  /proxy.pac /wpad.dat

Hier sind zwei Dateien eingetragen, die wpad.dat und die proxy.pac, die beide identisch sind. Eine Version ist für WPAD-fähige Systeme zuständig, die andere für ältere Versionen. Durch den Redirect muss nur eine der beiden Dateien wirklich vorhanden sein. Anfragen an die andere Datei werden passend weitergeleitet.

Im Prinzip suchen die Browser nun nach einem festen System nach der Konfigurationsdatei. Man kann ihnen das Leben erleichtern und auch den cname wpad für den Webserver vermeiden, wenn man die DHCP-Server Konfiguration etwas anpasst.

# /etc/dhcpd.conf
#
# Configuration file for ISC dhcpd
#
# -- global options --
default-lease-time                 160000;
max-lease-time                     200000;
use-host-decl-names                on;
option dhcp-max-message-size       1024;
option wpad code 252 = text;
ddns-update-style                  none;
authorative;

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.40 192.168.1.160;
    server-identifier 192.168.1.1;
    option broadcast-address 192.168.1.255;
    option routers 192.168.1.254;
    option domain-name-servers 192.168.1.1, 192.168.1.254;
    option domain-name "debacher.net";
    option wpad "http://www.debacher.net/wpad.dat ";
}

Die beiden hinzuzufügenden Zeilen sind fett unterlegt. Damit wird dem Client-Rechner schon beim Starten die Adresse der wpad.dat (Code 252) mit übermittelt. Hier ist eine beliebige URL möglich, die auch nicht unbedingt im eigenen Netz liegen muss. Die Adressübermittlung per DHCP hat übrigens Vorrang gegenüber der Übermittlung per DNS. Man muss also nicht unbedingt an den Nameserver heran.

Weitere Informationen:

Jul 3
Typo3 und Firefox
icon1 debacher | icon2 typo3 | icon4 07 3rd, 2009| icon3No Comments »

Seit einiger Zeit wundere ich mich, dass in Typo3-Seiten oft fehlerhafte Links auftauchen. Die Links haben dann die Form:

http://typo3/http://www.debacher.de/wiki/

Eine Erklärung für diese Verhalten habe ich unter http://typo3-blog.net/tutorials/news/rte-bug-fix.html gefunden.

Jan 9

Sehr bequem arbeiten kann man mit der Firefox-Erweiterung FireFTP, die einen kompletten FTP-Client liefert. Zu beziehen ist diese Extension unter  http://fireftp.mozdev.org/

Jan 9
Aardvark
icon1 admin | icon2 Software-Empfehlung | icon4 01 9th, 2009| icon3No Comments »

Aardvark ist eine Firefox-Extension für Web-Entwickler, die unter http://karmatics.com/aardvark/ zu finden ist. Mit diesem Tool lässt sich die Struktur von CSS-Elementen leichter erkennen.

Jan 9

Unter http://chrispederick.com/work/webdeveloper/ findet sich eine  Firefox-Erweiterung, die allen Web-Entwicklern sehr hilft.  Mit dieser Erweiterung lassen sich HTML und CSS recht gut analysieren.