Schlagwort-Archive: firefox

PDF in Webseiten anzeigen

Veröffentlicht am von

In der letzten Zeit ist es nicht einfacher geworden PDF-Dokumente in einer Webseite darzustellen. Zwar beherrscht Firefox das problemlos, aber z.B. nicht die Android-Version. Auch auf verschiedenen Apfel-Geräten funktioniert das nicht von Haus aus.

Zum Glück gibt es das Projekt https://github.com/mozilla/pdf.js mit dessen Javascript die Einbindung auf sehr vielen Geräten identisch funktioniert. Ich habe mir die Software von https://mozilla.github.io/pdf.js/getting_started/ geladen und die ZIP-Datei in ein Verzeichnis /pdfjs entpackt.

Leider ist die Nutzung des Scripts etwas aufwendig. Eine einfache Lösung besteht darin die mitgelieferte Viewer-Seite aus dem Unterverzeichnis /pdfjs/web zu nutzen und über einen Iframe einzubinden:

<iframe id="pdf-js-viewer" 
        src="/pdfjs/web/viewer.html?file=/fileadmin/user_upload/netthelp.pdf" 
        title="webviewer" 
        frameborder="0" 
        width="500" 
        height="600">
</iframe>

Leider ist diese Lösung so nicht responsiv. Mit Hilfe von https://www.w3schools.com/ habe ich mir folgende Lösung erarbeitet (hier für eine Typo3 Installation):

<div style="position: relative;
            width: 100%;
            overflow: hidden;
            padding-top: 141%;
           ">
  <iframe id="pdf-js-viewer"
          src="/pdfjs/web/viewer.html?file=/fileadmin/user_upload/netthelp.pdf#zoom=auto"
          title="webviewer"
          frameborder="0"
          style="position: absolute;
                 top: 0;
                 left: 0;
                 bottom: 0;
                 right: 0;
                 width: 100%;
                 height: 100%;
                 border: none;
          ">
  </iframe>
</div>

Der Trick besteht darin ein DIV Element zu nutzen, das die ganze verfügbare Breite einnimmt und über padding-top eine darauf basierende Höhe bekommt. Bei den DIN Ax Dokumenten ist das Höhen-Breiten-Verhältnis 1,41:1 bei Portrait und 1:1,41=0,71:1 bei Landscape.

In dieses Element hinein wird dann der IFrame geladen und bekommt den vollständigen Platz zur Verfügung gestellt.

Mittels #zoom=auto wird erreicht, dass sich auch der PDF-Viewer an den zur Verfügung stehenden Platz anpasst. Hinter zoom=… könnten folgende Angaben stehen:

  •  200 (oder eine beliebige Prozentzahl)
  • page-width
  • page-height
  • page-fit
  • auto

Außer zoom gibt es noch den Parameter page=, damit kann angegeben werden, mit welcher Seite des PDFs die Darstellung startet. Weitere Möglichkeiten finden sich auf der Seite https://github.com/mozilla/pdf.js/wiki/Viewer-options.

Weitere Informationen:

404 Fehlermeldung bei Typo3

Veröffentlicht am von

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.

 

Shell in a box

Veröffentlicht am von

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.

Browser-Konfiguration mittels wpad.dat

Veröffentlicht am von

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: