Schnellnavigation:

Kategorien

« Oktober 2017»
S M T W T F S
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Kopieren Sie diesen Link in Ihren RSS-Reader

RSS 0.91Nachrichten
RSS 2.0Nachrichten

In eigener Sache

Peter Linzenkirchner, Lisardo EDV Beratung in Augsburg. Freelance und Partner für Design- und Webagenturen in Augsburg und München. Pixelgenaue Templates, valides HTML, barrierearm. TYPO3-Projekte, Extension-Programmierung und mehr ... 

Zur Zeit wird gefiltert nach: Developer
Filter zurücksetzen

Es handelt sich nur um ein kleines Update, da ich nur eine Anpassung an Version 6.0 von TYPO3 gemacht habe. Glücklicherweise musste ich dazu nur eine Funktion austauschen, alles andere passt noch, zumindest bis Version 6.1 bzw. 6.2, wenn der Compatability-Layer entfernt werden wird. 

Ich habe die Extension in diesen Introduction Packages getestet: TYPO3 4.5.22, 4.7.7 und 6.0. Sie sollte spätestens morgen im TER verfügbar sein. 

Kategorien: Extensions  Kommentare 3

Seit Version 4.3 ist in TYPO3 OpenID integriert, die passende Extension muss nur installiert werden. (Infos zur Installation in TYPO3 in einem Artikel bei TYPO3-Blogger, Infos genereller zum Prinzip zum Beispiel bei Wikipedia). Prinzipiell läuft es so ab:

  • Extension installieren
  • eine OpenID beschaffen, zum Beispiel bei Google, Yahoo oder einem Anbieter wie www.myopenid.com. Diese sieht dann in etwa so aus: https://myname.myopenid.com/. Eine eindeutige, weltweit gültige URL als ID. 
  • Diese ID wird im Backend von TYPO3 in ein neues Feld bei den Userdaten eingetragen. 
  • im Login-Dialog von TYPO3 gibt es jetzt ein kleinen Link: »Zum OpenID-Login«. Es erscheint ein neues Eingabefeld in das man diese URL https://myname.myopenid.com/ eingeben muss. Also nicht seinen Usernamen!

je nach Status gehts jetzt unterschiedlich weiter:

  • Wenn man bei seinem OpenID-Provider momentan eingeloggt ist und dort die TYPO3-Installation bereits einmal freigegeben hat, wird man sofort in TYPO3 eingeloggt, ohne weitere Passworteingabe. Perfekt. 
  • Beim ersten Mal gibt es aber Hürden: TYPO3 leitet weiter zum OpenID-Provider, dort muss man sich einloggen – (mit einem hoffentlich sehr sicheren Passwort) – und bestätigen, dass die TYPO3-Seite auf den OpenID-Account zugreifen darf.
  • Solange man bei seinem OpenID-Provider eingeloggt ist, muss man danach kein Passwort mehr eingeben.

Im Prinzip eine gute Idee, aber da gibt es ein paar Hürden, die für viele unüberwindlich sein dürften:

  • Wirklich bequem ist die Sache nur, wenn ich beim OpenID-Provider dauerhaft angemeldet bin, wenn man also Google oder Facebook dafür benutzt. Das ist aber ein Datenkraken-Problem ...
  • Das Einrichten eines OpenID-Accounts ist umständlich, wenn man nicht seinen Google- oder Facebook-Account dazu benutzt – siehe oben.
  • Man muss für das Login die gesamte URL eingeben, also sehr viel tippen. 
  • die Sicherheit steht und fällt mit dem Passwort beim OpenID-Provider. Wenn das erratbar ist, dann sind ALLE Accounts offen, bei denen man OpenID einsetzt. Der Angreifer braucht nicht mal mehr einen Usernamen zu wissen. Das Passwort sollte also wirklich sicher sein und das Vertrauen in seinen OpenID-Provider seh hoch.

Insgesamt also doch nur für Poweruser geeignet. Das Loginproblem bzw. Passwort-Merken-Problem für Normalanwender bleibt ungelöst. 

Gerade eine neue Version meiner Extension »socialshareprivacy« ins TER eingestellt. Es gibt keine großartigen Änderungen, nur kleine Anpassungen: 

  • die mitgelieferte Version von jQuery ist jetzt 1.7.2
  • die automatische Installation von jQuery wird nicht mehr in der Extension-Konfiguration vorgenommen, sondern über Typoscript (Dank an Esben, der mich darauf hingewiesen hat, dass man die Extension sonst nicht in einer Multi-Site-Umgebung einsetzen kann). 
  • das Socialshare-Privacy-Skript ist jetzt in Version 1.4, somit kann die Facebook-App-Id entfallen. 

Das wars im wesentlichen; die neue Fassung sollte morgen oder so verfügbar sein. Auf der Seite hier läuft sie schon. 

Achtung beim Updaten: wenn jQuery nicht aus der Extension kommen soll, muss jetzt diese Zeile ins Typoscript-Setup: 

  1. plugin.tx_socialshareprivacy_pi1.dontuse_jquery_from_extension = 1

Update für TYPO3 6.0

Ging heute ins TER (23.12.2012) und sollte ab morgen verfügbar sein. Getestet in TYPO3 4.5.22, 4.7.7 und 6.0

Kategorien: Extensions  Kommentare 4

Bis zum 25. Mai sollte eigentlich die europäische Cookie-Richtlinie in nationale Gesetze umgesetzt werden (lies zum Beispiel hier). Diese sieht vor, dass Cookies nur noch automatisch und ohne Einwilligung gesetzt werden dürfen, wenn sie für den aufgerufenen Dienst unbedingt erforderlich sind, also zum Beispiel die Cookies eines Warenkorbs. Alle anderen – insbesondere Cookies von Drittanbietern und Cookies zum Tracken von Besucherinformationen – dürfen erst nach Einwilligung der Seitenbesucher gesetzt werden. 

Das ganze liest sich wie ein verspäteter Aprilscherz, scheint aber ernst gemeint zu sein: Tatsächlich existiert die EU-Richtlinie, und es wird wohl früher oder später auch ein deutsches Gesetz draus werden müssen. Ich kann mir allerdings nicht vorstellen, wie es praktisch umgesetzt werden soll. Klar, Cookies für einen Warenkorb sind kein Problem. Aber wie sieht es z. B. mit den üblichen Session-Cookies aus, die gesetzt werden, um Formularspam zu verhindern, oder mit dem Standard-Session-Cookie von TYPO3 (fe_typo_user), das für alle möglichen internen Zwecke eingesetzt wird? TYPO3 funktioniert ohne das Cookie nicht: Ist es also unbedingt erforderlich und darf gesetzt werden, oder muss ich die Besucher zuerst fragen? 

Wie wird wohl das Surferlebnis, wenn auf jeder Seite zuerst alle Cookies von Facebook, Analytics, Ad & Co. abgenickt werden müssen – wenn möglich sogar einzeln – bevor ich was zu sehen bekomme? 

In einem Artikel des PHP-Magazins (Mit Cookie Control fit für vergessene Gesetze) wird das jQuery-Plugin Cookie Control vorgeschlagen, mit dem es möglich sein soll, die Besucher vor dem Setzen der Cookies zu informieren und unaufdringlich ihre Zustimmung zu holen. Es in eine Seite zu implementieren dürfte nicht schwierig sein (hier ist die Anleitung), es sieht tatsächlich gut aus und verhält sich recht unaufdringlich. Ich überlege mir, ob ich es mal prophylaktisch einbaue, auch wenn ich hier ausser dem obligatorischen TYPO3-Session-Cookie keine weiteren Cookies setze. So als Trockenübung für den Fall, dass die Richtlinie mal Gesetz wird. 

PS: wer prüfen will, ob ich hier tatsächlich nur das erwähnte Session-Cookie setzen lasse, geht auf diese Seite und gibt dort »typo3-lisardo.de« ein. Oder vielleicht »bild.de«, das macht mehr her. 

Kategorien: Developer  Kommentare 0

Mit less kann die Entwicklung von umfangreichen CSS-Strukturen vereinfacht werden: Es ermöglicht den Variablen, Operationen und Funktionen innerhalb einer CSS-Datei. So können zum Beispiel zu Beginn der CSS-Datei Farben, Maße und andere einheitliche Elemente definiert und anschließend als Variablen (oder eigentlich eher als Konstanten) verwendet werden. Mit Hilfe von »nested rules« kann man (wie im Typoscript) auf die lästigen Selektoren verzichten und statt dessen die CSS-Regeln einfach ineinander verschachteln. Und vieles mehr – bitte einfach auf der Originalseite nachlesen, es gibt da eine gute Dokumentation aller Techniken. 

Obwohl mich less fasziniert, seit ich es zum ersten Mal gesehen habe (was für eine Zeitersparnis beim Entwickeln!) setze ich es bisher nicht ein, da die less-Dateien natürlich irgendwie aufbereitet werden müssen, bevor der Browser sie interpretieren kann. Das funktioniert entweder direkt im Bowser über JavaScript oder serverseitig über ein Ruby-Skript.

Genauer erklärt ist das Ganze hier: less: The dynamic stylesheet language. 

Nun ist Ruby nicht auf allen Servern installiert und der Einsatz im Browser über JavaScript schmeckt mir auch nicht. Also war das für mich bisher ein interessanter Ansatz, aber mehr auch nicht. Bis mir das hier untergekommen ist: less.app for Mac OS X. Die App funktioniert so: ich versehe meine CSS-Datei mit der Endung .less und arbeite darin mit den less-Befehlen, wie üblich in Textmate. Vorher übergebe ich den ganzen Prohekt-Ordner an die less-App, teile der App mit, in welchen Ordner die CSS-Dateien kompiliert werden sollen, und jedes Mal wenn ich jetzt die less-Datei speichere, wird die CSS-Datei kompiliert, auf Wunsch auf minifiziert. Da die Datei geparst wird, werden dabei auch gleich noch alle kleinen Syntaxfehler gefunden ... Schöner gehts nicht; das wird in Zukunft verwendet!

Auf der Seite gibts ein kurzes Video, das den Einsatz erklärt. 

Weiterführende Links

 

Kategorien: HTML & CSS  Kommentare 2
Tags: css, less, mac
Besuchen Sie mich auf Google+