OS X 10.9 Mavericks: SourceTree funktioniert nicht mehr, kein Git-Svn mehr?

Auch nach einer manuellen Neuinstallation der MacPorts funktioniert Git-Svn und damit auch Tools wie SourceTree nicht mehr, weil Libraries (hier zu Perl) nicht mehr gefunden werden.

Temporäre Abhilfe verschaffen hier  zwei Symlinks.

sudo ln -s /Applications/Xcode.app/Contents/Developer/Library/Perl/5.16/darwin-thread-multi-2level/SVN /System/Library/Perl/Extras/5.16/SVN
sudo ln -s /Applications/Xcode.app/Contents/Developer/Library/Perl/5.16/darwin-thread-multi-2level/auto/SVN/ /System/Library/Perl/Extras/5.16/auto/SVN

OS X 10.9 Mavericks: Kein M2_HOME mehr in IntelliJ IDEA

Nach dem Update auf Mavericks hat sich auch unter der Haube einiges an Libraries getan. So ist nicht nur das System-Ruby auf Version 2 angehoben worden, sondern auch Maven wurde nebst Java jetzt wirklich komplett entfernt.

Damit man in IntelliJ IDEA nicht in jedem Projekt separat die Maven-Konfiguration nachpflegen muss, muss man nun Maven auch selber installieen (musste man vorher auch, wenn man eine andere Version als den Default haben wollte). Leider erhalten GUI-Anwendungen unter OS X nicht einfach alle Umgebungsvariablen (aus dem Enviroment, ~/.bash_profile usw.). Seit 10.8 und 10.9 muss man wohl tatsächlich, will man globale Variablen anlegen, diese im Launch Daemon registrieren. Dies wiederum kann man aber bspw. in seiner ~/.bash_profile machen.

Das sieht bei mir nun wie folgt aus:

export M2_HOME=~/bin/apache-maven-3.0.5
export M2=$M2_HOME/bin
launchctl setenv M2_HOME $M2_HOME
launchctl setenv M2 $M2

Darüber hinaus schadet es auch nicht, eine funktionierende JAVA_HOME Variable anzulegen, weil manche stumpfsinnigen OSX-Anwendungen einfach nicht in der Lage sind ohne auszukommen:

export JAVA_HOME=$(/usr/libexec/java_home)
launchctl setenv JAVA_HOME $JAVA_HOME

Und wenn wir einmal dabei sind, aktualisieren wir noch den Pfad.

launchctl setenv PATH $PATH

Wahlweise kann man hier natürlich auch das $M2 hinzufügen ($PATH:$M2), wenn man den Befehl „mvn“ auch im Pfad haben will.

[Howto] Maven: Wie man eine ausführbare Jar in eine Java-Webanwendung (War) via Webstart integriert.

Die Situation

Es bestehen zwei lauffähige, fertige Projekte in Maven, welche beide auch vollwertige Artefakte bilden können.

Zum einen die Webanwendung — nennen wir sie hier mal webportal — mit einem WAR-Artefakt, etwa für einen Tomcat. Ob das Artefakt als Snapshot oder Release gemacht wird, ob es nur generiert oder auch in ein Repository deployt wird, ist hierbei nicht von weiterer Bedeutung.

Zum anderen die normale Clientanwendung — nennen wir sie doch einfach userclient — mit einem JAR-Artefakt. Wichtig ist natürlich, dass hier eine startfähige Main-Klasse vorhanden ist. Dies sollte jedoch der Regelfall sein, daher nur der formale Hinweis.

Zusammengefasst, und der Auftrag an dieses Howto ist also: Wie konfiguriert und erweitert man den Buildzyklus in welchem Projekt an welcher Stelle am geschicktesten, um auf einfachem Wege die JAR-Datei userclient in die Webanwendung webportal als Java Webstart zu integrieren. Dabei ist es hilfreich, wenn man via pom.xml (und natürlich der Macht der Properties) die Versionen spezifizieren kann. Der gesamte Prozess von auswählen, signieren und ausliefern soll dabei automatisch und ohne weiteres Eingreifen des Entwicklers geschehen können. Idealerweise sollte das ganze auch optional sein — dazu gibt es dann mehr unter „Optimierungen und Verbesserungen“.

„[Howto] Maven: Wie man eine ausführbare Jar in eine Java-Webanwendung (War) via Webstart integriert.“ weiterlesen

MacOS X Security

Boah, was für ein Artikel. Geht zusammengefasst um das Sicherheitskonzept von MacOS X, teilweise im direkten Vergleich zu Windows. Unter anderem auch mit der These: Der geringe Marktanteil von Mac OS X ist nicht Schuld an kaum Malware.

Nicht überaus technisch überladen, also sehr verständlich (auf deutsch) erklärt.

Es sind zu viele Informationen auf einmal gewesen, aber beim ersten Durchlesen sind mir keine Fehler aufgefallen. Einzig allein den Passus, dass „Mac OS X“ in großen Teilen offen läge, finde ich unglücklich formuliert. Der Autor meinte sicher, dass viele Komponenten (wie das in dem Kontext genannte Samba) offen sind und von Apple dort auch genutzt werden.

Context Affair

Bei Spring ist die globale Einheit in der Konfiguration der so genannte ApplicationContext. Dieser Context ist etwa ein Container im Applicationserver (beispielsweise web.xml). Soweit so gut.

Tatsächlich ist der WebApplicationContext eine Spezialisierung des oben genannten ApplicationContext — und zuständig für Webanwendungen. Da ein Servlet die Steuerung im Applicationserver übernimmt, benötigt der Spring-Context ein DispatcherServlet. Damit ist die „Verbindung“ User->Server->Spring geschaffen. Soweit so gut.

Konfiguriert man das DispatcherServlet etwa – sinnigerweise – mit dem Namen“dispatcher“, dann sucht Spring standardgemäß nach einer dispatcher-servlet.xml. Diese XML-Konfigurationsdatei kann ähnlich der applicationContext.xml (u.ä.) ganz normale Bean-Konfigurationen enthalten. Interessant ist dabei, dass dabei ein zusätzlicher ServletContext erstellt wird. Das hat zwei Auswirkungen:

  1. Beans aus dem ServletContext sind nicht im ApplicationContext verfügbar
  2. Annotations-gestützte Konfigurationen müssen jeweilse in beiden Contexten konfiguriert, also aktiviert, werden

Shortcut of the week

Das ursprüngliche Problem: Ich habe eine URL zu einem MP4-Video, welches der Safari sofort abspielen will. Allerdings will ich das Video erst später gucken, also speichern. Hm, dumme Sache. Dem Link folgen von der ursprünglichen Seite ging aus bestimmten technischen Gründen nicht — und ein Dokument/Seiten speichern scheint zu mindestens nicht zu funktionieren, so lange das Video noch lädt.

Überraschenderweise ist es einfacher, als man denkt: Das Safari-Downloads-Fenster nimmt die Tastenkombination +V für Einfügen an — dementsprechend auch jegliche Drag ’n‘ Drop Aktionen, welche eine URL als Objekt haben.

Kurzer Gegenscheck: Nope, Firefox kann das nicht. 😉

iPhone Webapps – Autokorrektur komplett deaktivieren

Für Webapps, also HTML-Seiten, gibt in speziellen Sitationen wie Loginformulare Problemen mit der Autovervollständigung bzw. -korrektur des iPhone OS.

Für input-Tags gibt es neben dem Attribut autocomplete=“off“ (unterstützt bspw. durch den Firefox) noch zwei weitere Attribute:

  • autocorrect=“off“ — die Autokorrektur abschalten
  • autocapitalize=“off“ — die Auto-Groß/Kleinschreibung-Korrektur abschalten

Alle drei Attribute zusammen schalten auf iPhone/iPad/iPad sämtliche Korrekturvorschläge ab.

Featurities meets Fallstrick: Die Spring Security 3.0 Konfigurationsodyssey

Mit dem Majorrelease 3.0 wurde dem Modul Spring Security eine Menge von neuen Features angeignet. Spring Security ist die Modulkomposition, welches für das Java Framework Spring quasi die gesamte Authentifizierung, Autorisierung, Legitimierung jedwegiger Art ermöglicht.

Leider wurden mit dem Release 2.x auf 3.0 eine Reihe von API-Changes vollzogen. Zugegeben, die waren auch sicher alle sinnvoll, weil Komponenten wie die Authentifizierung weiter geteilt wurden und man somit wesentlich flexibler ist, neue Anforderungen zu ermöglichen (Baukastenprinzip). Aber die Dokumentation ist – gesamtheitlich betrachtet – irgendwie immer noch mies und oft nicht aktualisiert. Oder man findet im Internet einfach nur (alte) Beispiele.

Die http-Direktive

Im Namespace von Spring Security existiert das Tagelement http, mit welchem man kurze, knappe und verständliche Konfigurationen anlegen kann. Der Vorteil liegt klar auf der Hand: Man muss nicht alle Beans, Listener und Provider anlegen, denn das geschieht automatisch. Tja, wären da nicht ein paar Einschränkungen in der Funktionsvielfalt.

Konkretes Beispiel: Remember Me

Just wurde das Minor-Release 3.0.1 veröffentlicht, und nur wenige Tage später zu erfahren, dass Remember Me kaputt sei. Egal, fahren wir erstmal weiter mit 3.0.0.

Laut Dokumentation ist es am einfachsten, wenn man die Direktive remember-me (Security Namespace) innerhalb der http-Direktive (Security Namespace) verwendet. Ohne irgendeine Angabe wird ein stinknormales, Cookie basiertes Tokenverfahren ohne (echten) privaten Schlüssel verwendet. Reicht für den ersten Einsatz erstmal auf, soll ja erstmal funktionieren.

Fehlermöglichkeit 1a: Man loggt sich ein, und es passiert nichts (kein „RememberMe“-Cookie).
Lösung: Wenn man einen eigenen Auth-Filter einsetzt, muss man diesem auch den RememberMe-Service „setten“. Außerdem muss der SecurityChainFilter (web.xml!) auch auf die login-Seite verweisen. Es dürfen auch keine Filter bei der Konfigurierung von intercepted Urls (speziell hier: login, logout) gemacht werden.

Fehlermöglichkeit 1b: Es passiert noch immer nichts?
Lösung: Vielleicht wurde vergessen, einen Parameternamen für den Request zu setzen. Der Standardname ist ein typischer Springname, der natürlich unschön ist. Und den kann man nicht über die RememberMe-Direktive setzen, also muss man eh einen eigenen Service definieren. Bäm. Referenzierung geht dann zwar noch, aber für mehr ist die RememberMe-Direktive dann nicht mehr zu gebrauchen.

Fehlermöglichkeit 2a: Man besucht die Seite ohne Login, aber mit Cookie – und die Loginseite kommt (Log sagt kein gültiger Auth).
Lösung: Man kann der Log trauen, wenn sie zwar beim Einloggen nun einen Token ablegt (kann man zum Beispiel sehr einfach mit diesem Firefox-Addon inkl. Editor(!) verifizieren), dieses aber beim erneuten Besuchen der Seite (bzw. ohne JSPSESSION-Cookie) nicht verwendet bzw. wird nicht erkannt. Schlussendlich half u.a. das Umbenennen der Userservices-Bean in „userService“. Außerdem sollte die Loginseite keinen Filter/Access haben (s.o.) Lieber 2x prüfen!

Fehlermöglichkeit 2b: Es erscheint eine Ausnahme, dass der Key falsch sei.
Lösung: Dazu muss man wissen: Sobald man eine individualisierte RememberMe-Konfiguration nutzt, wird auch der Key nicht mehr vernünftig auf alle Komponenten (Provider, Filter, Manager) gesetzt. Beim Anlegen wird also der eigene Key verwendet, beim Auslesen der Standardkey. Yes! (s.o.)

Fehlermöglichkeit 3: Man besucht die Seite ohne Login, aber mit Cookie – aber wie in 2 nur die Loginseite.
Lösung: Im Logger/Debugger kann man nun feststellen, dass zwar das Cookie gefunden wurde, das Token gefunden und validiert wurde aber dann keine Rechte existieren – aha? Wahrscheinlich fehlt im Provider noch ein zusätzliches Setting der Komponenten. Am besten von RememberMe Service/Filter/Provider jeweils alle möglichen Properties durchgehen. Jaja, wie gesagt.. 😉

Fehlermöglichkeit 4: Das Ausloggen (beispielsweise logout.html) hat nach Aktivierung von Rememberme plötzlich keine Auswirkungen mehr.
Lösung: Zwar wird die Seite gefunden, aber es wird kein „Logout“ gemacht. Auch hier sollte man prüfen, ob ein SecurityChainFilter (web.xml) auch für die logout-Seite greift.

Fehlermöglichkeit 5: Das Besuchen der Seite wirft einen Fehler (ggf. „mit weißer Seite“), dass keine neue Session erstellt werden kann.
Lösung: Richtig, nach einem Request ist ja dann auch zu spät. Das Attribut create-session in der Direktive http sollte daher auf „ifRequeried“ gestellt sein.

Fazit:

  • SecurityChainFilter immer prüfen
  • Intercepted Urls prüfen
  • RememberMe-Direktive innerhalb der http-Direktive ist quasi abgesehen von der services-ref unbrauchbar.

Anmerkung:

Natürlich kann man sich das Problem mit den SecurityChains vom Hals schaffen, indem man stupide ein /* filtert. Das hat jedoch zur Auswirkung, das Spring Security auch jeden verdammten Request anguckt; bei zusätzlichen (statischen) Inhalten wie Javascript, Stylesheets, Bildern, Flash u.ä. ist das ein Overhead, der unnötig ist.

HTML5 & Forms

Als Ergänzung zu meinem XForms-Vortrag in der FH, hier ein paar nette Details zu den Neuerungen von HTML5/Forms. Jaja, was für eine Überaschung. Okay, nach dem Tod von XHTML2 (und demnach die Integration von XForms in XHTML) auch wieder nicht…

Ganz allgemein scheint Dive Into HTML5 aber auch empfehlenswert zu sein, wenn auch noch in Arbeit. Nett gemacht.