Monatsarchive: September 2015

Beulen im MacBook Pro 15″ Mid 2015

Meine Freundin Nadine ist leidenschaftliche Fotografin und hat bis vor kurzem mit einem MacBook Pro 13″ aus dem Jahr 2010 gearbeitet. Mit Photoshop und Lightroom geht das Teil mittlerweile aber ganz schön in die Knie und es musste endlich was neues her. Um etwas mehr Leistung zu bekommen, ist die Wahl schnell auf das aktuelle 15″ Modell (2,2 GHz Quad-Core i7, 16GB RAM und 256GB SSD). Dank Retina-Display wirklich eine Höllenmaschine.

21.08.2015 – Kauf

Also ab in den MediaMarkt. Hier gibt es Gerät für 1.945€ (statt 2.245€ bei Apple / einem Apple-Reseller). Ein ordentlicher Rabatt auf jeden Fall. Am Abend dann noch ausgepackt und festgestellt, dass unter dem Gerät zwei Beulen sind. Sehr ärgerlich, da diese auch relativ stark waren und man sie sofort gesehen hat. Da das bei einem Gerät in der Preisklasse absolut nicht passieren darf, wieder ab zum MediaMarkt. Mittlerweile war es schon 19:50 Uhr und der Markt schließt um 20:00 Uhr. Gut, wir wollten ja nur fix ein anderes Gerät und dann wieder los. Also an der Info schnell tausend Zettel ausgefüllt und zurück in die Abteilung. Weiterlesen…

Mini-Touch-Display am Raspberry Pi 2

Vor ein paar Tagen habe ich ein Foto gesehen, auf dem ein Raspberry Pi mit einem Touch-Display im Gehäuse zu sehen war. Wer dieses Blog verfolgt, weiß dass ich schon vor einiger Zeit ein Hausautomatisierungsprojekt mit dem Raspberry Pi der ersten Generation gestartet habe. Die Beiträge laufen nach wie vor sehr gut auf dem Blog und werden viel gelesen.

Da ich für den Touchscreen ein Raspberry Pi 2 brauchte, musste ich mir fix eine Einkaufsliste zusammenstellen. Alles zusammen kostet ungefähr 100 Euro.

Dinge wie HDMI-Kabel, USB-Maus, USB-Tastatur und Netzwerkkabel hatte ich noch im Haus. Keine zwei Tage später lag das gute Stück dann auch schon in der Packstation. Das ging fix!

Ich hab die Version mit Gehäuse bestellt, da dort alles perfekt zusammen passt und ich nicht erst noch groß rumbasteln muss. Leider ist das Gehäuse in mehrere Plexiglasteile zerlegt und will erst zusammengebaut werden. Dabei ist jedes Stück von beiden Seiten mit einer Art Papier überzogen, was erst müßig abgeknibbelt werden will. Nerv!

Das alles ist mit dem kleinen Anleitungszettel aber kein Problem. In den Rezensionen bei Amazon sind ein paar Meinungen von unfähigen Menschen zu finden, die das Gehäuse nicht zusammengebaut bekommen – davon nicht beirren lassen. Jeder der etwas logisch denken kann, sollte das Teil zusammen bekommen. Immerhin ist ja sogar noch eine Zeichnung dabei! Statt dem Deckel kommt natürlich das Touch-Display drauf. Dieses ist auf einer Seite nur eingeklemmt, sodass man es hochklappen kann, um an die übrigen Pins des Raspberry zu kommen. Gut die Hälfte ist allerdings schon mit dem Display belegt.

Die Installation geht recht einfach von der Hand. Ich habe ein frisches Image per BitTorrent geladen (der normale HTTP-Mirror ist sowas von lahm) und das Ganze mit dd auf die neue SD-Karte gepumpt. Wie genau das geht, findet man auf etlichen Seiten im Netz. Das Display läuft übrigens nur mit Raspbian Wheezy und nicht mit RaspBMC oder sowas.

Danach muss man einfach der Anleitung auf dem beigelegten Zettel folgen. Jeder, der schon einmal eine Shell und Nano oder Vi bedient hat, wird das locker schaffen. Ich bin auch kein UNIX-Crack und habe es ohne jedes Problem beim ersten Versuch hinbekommen. Hierfür ist natürlich eine Internetverbindung erforderlich. Ansonsten kann man die neuen Pakete nicht herunterladen.

Und das wars auch schon – nach gut einer Stunde inkl. auspacken stand ein Raspberry Pi mit Touchdisplay auf dem Tisch. Schon ein lustiges Gefühl. Selbst in der Welt von Smartphones und Tablets, ist ein UNIX auf einem so kleinen Teil doch noch etwas besonderes. Im ersten Moment habe ich sogar vergessen, dass es ein Touch-Display ist und Wheezy weiterhin mit Maus und Tastatur bedient.

Für kleine Elemente ist das Display aber wirklich anstrengend per Touch zu bedienen. Ich muss das Display auch noch etwas Kalibrieren, da die Klicks momentan ein Stück zu weit links landen. Aber das ist sicherlich auch kein Akt.

RaspberryTouch1

RaspberryTouch2

RaspberryTouch3

RaspberryTouch4

RaspberryTouch5

RaspberryTouch6

RaspberryTouch7

Ich bin gespannt, was ich dem kleinen Teil so alles anstellen werde.

Stackexchange: User-Flair Banner auf die eigene Website

Zugegeben, ich bin nicht das aktivste Mitglied auf Stackexchange. Ich vote zwar fleißig für jede Antwort die mir hilft, aber viel Antworten oder Kommentieren tue ich leider nicht. Das versuche ich seit diesem Jahr etwas zu ändern, aber so super erfolgreich war es noch nicht. Aktuell habe ich gerade einmal 538 Reputation-Points.

Egal! Unter Stackexchange User Flair kann man sich ein jedenfalls Bildchen generieren, welches man dann auf die eigene Webseite packen kann. Sieht nicht nur gut aus, sondern macht ab einer bestimmten Reputation natürlich auch etwas her (nicht so wie bei mir). Immerhin sollte mittlerweile jeder Entwickler die Plattform kennen und schätzen gelernt haben. Wer da noch keinen Account hat, ist am Ende selber schuld.

StackexchangeFlair

Habe ich jedenfalls erst heute entdeckt, und freue mich über die verschiedenen Themes, die einem für das Banner zur Verfügung stehen. Hier die „immer aktuelle Version“:


profile for Matthias Kleine on Stack Exchange, a network of free, community-driven Q&A sites

Hmac SHA256: Die Alternative zu HTTP Basic-Auth

Das klingt jetzt erstmal kompliziert, aber es ist notwendig. Das Problem ist, dass die HTTP-Basic-Auth immer nur über HTTPS Sinn macht, da ansonsten die HTTP-Header im Klartext zu lesen wären. Mit „Hmac SHA256“ könnte man sogar per HTTP relativ sicher Daten austauschen. Natürlich könnten die Daten selbst dann mitgelesen werden, aber niemand könnte die Daten abändern um sich z.B. selbst einen User anzulegen.

Wie funktioniert das?

Relativ simpel. Hier setzt die PHP-Funktion hash_hmac an. Diesen Methode nutzen zum Beispiel Facebook, Instagram oder Amazon S3 in den REST-Services. Hierzu wird einfach ein Secret-Key erstellt, der von beiden Parteien bekannt ist. Dieser wird dann genutzt, um Nachrichten zu Hashen. Dieser Hash wird dann gemeinsam mit der Nachricht übermittelt.

Die Gegenseite prüft dann mit dem Secret wieder, ob die Hashes übereinstimmen und führt die gewünschte Aktion aus. Der schlaue Leser stellt nun fest, dass man doch einfach eine Nachricht abfangen könnte, und später erneut senden. Das ist soweit auch richtig – vor Replay-Attacken schützt diese Methode nicht! Außerdem sollten die übermittelten Daten nicht sensibel sein – andernfalls muss man doch wieder auf HTTPS zurückgreifen!

Um sich vor Replay-Attacken zu schützen, muss man der Nachricht einfach nur einen Zeitstempel oder eine Message-Id mitgeben. Diese speichert man dann auf der Gegenseite ab, und erlaubt das erneute Ausführen von ein und der selben Message-Id oder älteren Nachrichten nicht mehr.

Kann man aus technischen Gründen nicht auf HTTPS zurückgreifen, könnte man den Body selbst natürlich auch noch verschlüsseln. Hier bietet es sich an, das Ganze über entsprechende RSA-Zertifikate zu lösen. Außerdem hätte man dann sogar die Chance, die Daten zu signieren. So wäre es möglich, alles mögliche zu Übermitteln, ohne dass jemand mit den Daten etwas anfangen kann. Geht man aber so weit, kann man die HMAC-Lösung auch direkt weglassen.

Technik

In PHP ist das Ganze schnell implementiert. Spricht man hier mit bestehenden REST-APIs, muss man sich vorher schlau machen, wie der Hash an die Nachricht gehängt werden soll. Hier gibt es ganz verschiedene Lösungen: Als Zusätzlicher Parameter im JSON, als GET-Parameter, als zusätzlicher HTTP-Header, oder sonst wie.

Ich würde empfehlen, den Hash im Header zu übergeben. So trennt man etwas intelligenter die Daten, und muss sich auf der Gegenseite nicht so viele Gedanken machen, wie man die Nachricht denn nun auseinander nehmen muss, bevor man den Hash kontrolliert.

Recht einfach, oder?

Google-Richtlinie zur Zustimmung der Nutzer (EU-Cookierichtlinie)

Bereits am 27. Juli habe ich (wie jeder Google-Nutzer) eine Mail von Google erhalten, in der dazu aufgerufen wird, die Besucher über den Einsatz der Google-Dienste zu informieren. Hier die Mail:

Lieber Publisher,

hiermit möchten wir Sie auf eine neue Richtlinie zur Einholung der Zustimmung der Endnutzer in der EU hinweisen, mit der den geltenden gesetzlichen Vorgaben und Best Practices Rechnung getragen wird. Diese Richtlinie sieht vor, dass Sie zur Einholung der Zustimmung des Endnutzers verpflichtet sind, wenn Sie Produkte wie Google AdSense, DoubleClick for Publishers und DoubleClick Ad Exchange einsetzen.

Bitte lesen Sie möglichst bald unsere Richtlinie zur Zustimmung der Nutzer in der EU. Gemäß diesen Richtlinien müssen Sie die Zustimmung der Endnutzer in der EU einholen, wenn Sie Google-Produkte einsetzen und dabei Cookies und andere Daten gespeichert und abgerufen sowie Daten erfasst, weitergegeben und genutzt werden. Die Richtlinie hat keine Auswirkungen auf die in Ihrem Vertrag enthaltenen Bestimmungen über das Eigentum an Daten.

Bitte setzen Sie diese Richtlinie so bald wie möglich um, spätestens jedoch bis zum 30. September 2015.

Falls Ihre Website oder App über keinen der Richtlinie entsprechenden Zustimmungsmechanismus verfügt, implementieren Sie bitte jetzt einen solchen. Um Ihnen die Implementierung zu erleichtern, haben wir einige hilfreiche Ressourcen unter cookiechoices.org für Sie zusammengestellt.

Diese Richtlinienänderung erfolgte in Reaktion auf die Best Practices und rechtlichen Vorgaben der europäischen Datenschutzbehörden. Entsprechend diesen Vorgaben wurden vor Kurzem auch Änderungen an Googles eigenen Websites vorgenommen.

Vielen Dank für Ihr Verständnis und Ihre Mithilfe

Mit freundlichen Grüßen
Ihr Google-Richtlinienteam

Hier sind zwar nur explizit die Programme AdSense und DoubleClick angesprochen worden, aber ich denke, dass es nicht falsch sein kann, den Hinweis auch bei der Nutzung von Google Analytics einzubauen. Weiterlesen…

Synology DS214+ als Printserver nutzen

Ursprünglich sollte dieser Beitrag „Raspberry Pi als Printserver nutzen“ heißen. Dann ist mir eingefallen, dass ich ja seit kurzem in Besitz einer Synology DS214+ bin. Da das Teil auch noch direkt neben dem Drucker steht, warum nicht darüber Drucken? Muss ja auch gehen!

Bisher habe ich mit dem Drucker immer über das WLAN gedruckt. Nur leider kann mein guter HP LaserJet Pro P1102w kein 5 GHz-Band. Das können aber eigentlich ALLE Geräte, außer der Drucker. Das heißt, dass ich mit reduzierter Geschwindigkeit Daten im Netz hin und her schiebe, nur weil ich 2-3 mal im Monat eine Seite drucken möchte. Das kann ja so nicht richtig sein. Wirklich hässlich! Also WLAN umgestellt, das Teil per USB an die DiscStation gehangen und voila, da ist er auch schon zu sehen.

DSM_HP1102w

Aber da hört es auch schon auf! Ich kann weder ein Testseite drucken, noch irgendetwas anderes. Zu früh gefreut. Nun gut, also WLAN wieder umgestellt, gewartet bis der Drucker sich verbindet und alle Konfigurationsseiten einmal durchgeklickt. Dabei ist mir aufgefallen, dass der Drucker eine echt alte Firmware-Version nutzt: 20120814 (was wohl ein Datum darstellt). 2012 ist mittlerweile schon ein paar Jahre her. Also ein Update aufspielen. Weiterlesen…

AngularJS macht Lust auf mehr

Das Problem kennt jeder: Man hört von einer neuen Technologie oder einem neuen Framework, und möchte sich damit mal beschäftigen, macht es aber am Ende eigentlich nicht. Oder man macht es nur so Oberflächlich, dass man den Mehrwert für sich nicht so richtig erkennt. So ging es mir mit AngularJS. Es steht schon so lange auf meiner ToDo-Liste, dass Thema einmal genauer anzuschauen, aber erst vor kurzem habe ich mir wirklich Zeit dafür genommen.

Und was ist das Ergebnis? Ich ärgere mich, dass ich das nicht schon viel eher gemacht habe! Dabei habe ich mich schon häufig gefragt, wie manche Web-Apps gebaut wurden. Oder viel mehr: Wie behalten die Entwickler den Überblick in so riesigen UIs? Und ich glaube, dass ich für mich genau diese Antwort in AngularJS gefunden habe! Weiterlesen…