CoreMedia

Senior Java Entwickler (Schwerpunkt CoreMedia und Webentwicklung) ab Mai verfügbar

Kurzvorstellung:

Unser zertifizierter Entwickler hat mehr als 12 Jahre Erfahrung im Umfeld J2EE, CoreMedia und Webentwicklung allgemein – sowohl im Frontend-, als auch im Backend-Bereich.

Gesucht: CoreMedia Coach und Entwickler, Hamburg

Wir suchen für unseren Partner einen CoreMedia-Entwickler, der dessen Kunden als Coach und Entwickler unterstützt.

Ort: Hamburg
Start: 2012
Dauer: langfristig
Ref-Nr: VC11-1234

Aufgaben/Themen/Skills
• CAE-Coaching und -Entwicklung
• Must-have: Erfahrung mit dem GSB (Government Site Builder)
• Hibernate, Spring, Eclipse, Apache Webserver
• Themen u.a.: Suche in Abhängigkeit des Rechte- und Rollenkonzeptes, Konzeption und Backend-Anbindung, Portal-Integration der Produktdatenverwaltung

Wenn Sie verfügbar und interessiert sind, kontaktieren Sie uns gerne mit Ihrem aktuellen Profil per E-Mail über netzwerk@systemfeld.de oder telefonisch unter 030 25760986.

Weitere Projektangebote finden Sie unter http://blog.systemfeld.de/category/projekte/

VC11-1233: Teamleiter für CoreMedia-Plattform, Süddeutschland

Für eine Anfrage an unser Entwickler-Netzwerk suchen wir für unseren Partner einen erfahrenen Teamleiter zur Unterstützung seines 2-köpfigen Betriebsteams einer CoreMedia-Plattform.

Ort: Süddeutschland
Start: Q1 2012
Dauer: längerfristig
Ref-Nr: VC11-1233

Aufgaben/Themen/Skills
• Planung und Koordination der Aufgaben rund um den Betrieb einer CoreMedia-Plattform
• weitere Details liegen noch nicht vor, folgen aber in Kürze

Wenn Sie verfügbar und interessiert sind, kontaktieren Sie uns gerne mit Ihrem aktuellen Profil per E-Mail über netzwerk@systemfeld.de oder telefonisch unter 030 25760986.

Weitere Projektangebote finden Sie unter http://blog.systemfeld.de/category/projekte/

Entwickler Markus Schwarz – Java, ObjectiveC, CoreMedia

Wir möchten usneren Entwickler Markus Schwarz vorstellen. Seine Hauptskills liegen in den Bereiche Java Enterprise, ObjctiveC, CoreMedia

Sie haben einen Aufgabe für Herrn Schwarz? Fragen Sie unter netzwerk@systemfeld.de

Hacking CoreMedia PBE: Einfügen von Dokumenten in den Richtext per Auswahldialog.

Richtext-Editoren sind eine bei Redakteuren beliebte Komponente in (Web) Content Management Systemen zur einfachen Pflege von Textinhalten inklusive Auszeichnungen. Üblich und wünschenswert ist es natürlich, in diesen Richtext-Editoren auch Inhalte des CMS zur Verlinkung oder zur Einbettung von Bildern zu wählen.

CoreMedia bietet verschiedene Redaktionsmöglichkeiten: einen Java Editor, einen WebEditor sowie das Preview Based Editing, welches innerhalb der Vorschauseite durchgeführt wird. In vielen Fällen fühlen sich Redakteure durch das Preview Based Editing mehr angesprochen, da Änderungen am Inhalt dort sofort sichtbar werden und auch die Content-Struktur vor ihnen verborgen wird.

Dieser Artikel soll nun einige Grundzüge aufzeigen, wie trotz einiger Widrigkeiten eine Dokumentauswahl für den Richtext-Editor der CoreMedia Editing Services umgesetzt wurde.

HBBTV – Die Hochzeit zwischen Fernseher und Internet

Wenn es dunkel wurde, das Wetter draußen tobte und der Regen an die Schreibe prasselte, da haben wir es uns gemütlich gemacht. Der Fernseher wurde eingeschaltet und wir konnten neue Welten entdecken, auf der Ponderosa dem Sonnenuntergang entgegen reiten oder durch weit entfernte Galaxien fliegen. Der Fernseher war ein treuer Wegbegleiter, der uns einen Zugang zu jenen fremden Welten bot. Er blieb uns aber auch sich selbst treu und wandelte sich über lange Zeit kaum. Doch wir, die Zuschauer, wir wandelten uns immer mehr.

Das Internet kam und stellte vieles auf den Kopf. Information und Daten konnten in Echtzeit jederzeit abgefragt werden. Dann kamen die ersten Online-Shops wie Amazon auf, die die virtuelle Welt mit realen Gütern verband. Wir konnten über das Internet alles zu jeder Uhrzeit bestellen. Dieses Paradigma der Sofort-Verfügbarkeit schlich sich immer mehr in unser Leben. Mittlerweile schauen wir immer verständnisloser, wenn das Wunschsofa ganze vier Monate Lieferzeit hat. Das Internet hat uns daran gewöhnt, dass alles nur einen kurzen Klick entfernt ist.

Je mehr wir uns an dieses Nutzungsverhalten gewöhnten, umso altmodischer mehr kam uns unser Begleiter der Fernseher vor. Zu Beginn der New Economy um die Jahrtausendwende sahen einige Visionäre, dass wir Nutzer in Zukunft ein anderes Fernsehen sehen wollen. Im Jahr 1999 war ich an einem Projekte der damaligen Bertelsmann Broadband Group beteiligt. Mit Hilfe einer Setup-Box konnte ein Fernseher mit dem Internet verbunden werden und der Zuschauer das gewünschte Programm aus einer Medien-Datenbanken auswählen. Leider war der Ansatz damals seiner Zeit voraus. Der Hauptübertragungsweg war ISDN, DSL befand sich damals noch in den Kinderschuhen. Auch die Flat-Rates zur Kostendeckelung waren noch nicht in Sicht. Daher war die Übertragung der Filme über das Internet noch zu langsam und eine kostspielige Angelegenheit. Glasfaser-Internet-Anbindungen wie in Hamburg-Norderstedt waren die Ausnahme (in Bezug auf Glasfaser ist es das heute noch). Ein weiterer großer Hemmschuh waren die Unklarheiten bei den Nutzungsrechten. Was durfte auch über das Internet gesendet werden? Ist es dann auch als Fernseher zu sehen oder als eigenständiges Medium? Wenn ja, was soll diese zusätzliche Nutzung kosten? Die Beantwortung dieser Fragen kostete dem Medianvertrieb über das Internet viele Jahre.

Im Jahr 2008 kam es zu einer kleinen Revolution im Fernsehbereich. Die öffentlich rechtlichen Sender hatten über den neuen Rundfunkstaatsvertrag die rechtliche Grundlage, ihre Inhalte dem Publikum über das Internet zu Verfügung zu stellen. Damals setze die befreundete Firma aperto aus Berlin-Mitte die PC-Mediathek für das ZDF um. Zum Einsatz kam das Content Management System CoreMedia, mit dem auch die Mediatheken-Landschaft der ARD umgesetzt wurde. Nun war es dem Internet-Nutzer endlich möglich, das Fernsehprogramm im Netz zu sehen. Genau die Sendung, die er zu dem gewünschten Zeitpunkt sehen will.

Zwei Jahre danach kommt der letzte und konsequente Schritt dieser Entwicklung. Die Mediatheken erobern den Fernseher und gelangen zu unserem treuen Begleiter, dem Fernseher. Denn dieser hat sich in den letzten Jahren ordentlich gemausert. Von der flimmernden Röhre zum hübschen Flatscreen als Stilikone im Wohnzimmer. Das Bild ist nun hochauflösend und zur Anzeige von Internet-Inhalten bestens geeignet. Mit Hilfe des neuen Fernseh-Standards HBBTV (Hybrid Broadcast Broadband TV) werden Internet-Inhalte und -Dienste mit dem klassischen Fernsehangebot verbunden. Der große Vorteil gegenüber alten Lösungen besteht in den neuen Bedienkonventionen, die die einfache Navigierbarkeit über die gewohnte Fernbedienung gewährleisten. Entgegen alter Versuche, mit dem Anschließen von Funktastaturen den Fernseher zum Computer zu machen, passt sich der Internet-Inhalt jetzt in Form von CE-HTML an den Fernseher an. Somit wird der Zugang zum Internet über den Gebrauchsgegenstand Fernseher auch älteren und weniger Computer-affinen Mitbürgern möglich.

Im August 2010 durften wir zusammen mit der ARD die finale Hochzeit zwischen Fernsehen und Internet unterstützen. Für die IFA-Ausstellung im September wurde die ARD um eine HBBTV-Mediathek auf Basis der CoreMedia CAE erweitert.

Wir freuen uns auf weitere kuschelige Abende vor unserem treuen Begleiter – dem Fernseher im neuen Gewand.

Autor: Stephan Scharff-Rahn

Weiterführende Links:

http://www.hbbtv.org/
http://www.infosat.de/Meldungen/?msgID=59832
http://www.systemfeld.de

Interview mit Sören Stamer “Enterprise 2.0 – The Art Of Letting Go”

Sören hat mit seiner damaligen Firma CoreMedia das Neuland Enterprise 2.0 betreten und hat mit den daraus entstandenen Erfahrungen mit anderen Autoren das Buch “Enterprise 2.0 – The Art Of Letting Go” geschrieben. Hier wird der E20-Neuling in kurzen Artikeln aus unterschiedlichen Blickwinkeln an das Thema herangeführt.

Das Gute an dem Buch ist die Mischung der Autorenschaft. Dadurch entsteht ein Mosaik, welches die Gedanken zu E20 sehr gut vor Augen führt. Zum Einen werden theoretische Grundlagen auf kurzem Wege vermittelt, zum Anderen aber auch deren Umsetzungsansätze in der Praxis gezeigt.

Der folgende Podcast zeigt Sören nach seinem Vortrag auf der Web 2.0 Expo in San Francisco.

Autor: Stephan Scharff-Rahn

Zugriff auf den Spring-Context in Views

Bei Spring MVC wird zur Verarbeitung eines Request der entsprechende Controller für eine Weiterverarbeitung ausgeführt. Dieser erzeugt zum Schluss ein ModelAndView-Objekt, in dem zum einen Daten abgelegt werden, die in der View verfügbar sein sollen und einen Kennung für diese Folge. Diese Kennung wird an einen ViewResolver weitergeleitet, der sich für die jeweilige View-Klasse zuständig fühlt.

Es kann bei der Entwicklung wichtig sein, bestimmte Beans aus dem Spring-Context  JSPs zur Verfügung zu stellen. Standardmäßig wird  das gewünschte Objekt in den Controller injeziert, der dieses wiederum in das Model schreibt. Dies muss aber mit jedem Controller gemacht werden, was Code-Redundanzen erzeugt.

Ein eleganterer Weg besteht darin, die gewünschte Bean mit Hilfe des ViewResolvers im Scope der JSP verfügbar zu machen. Hierzu wird die List-Variable exposedContextBeanNames des Resolvers konfiguriert. Dort werden die Namen der Beans eingetragen, die innerhalb einer JSP aufrufbar  sein sollen.

Hier ein Beispiel, in der eine Konfigurations-Bean übergeben wird:

<bean id="jspViewResolver">
  <property name="viewClass"
     value="org.springframework.web.servlet.view.JstlView"/>
  <property name="prefix" value="/WEB-INF/jsp/"/>
  <property name="suffix" value=".jsp"/>
  <property name="exposedContextBeanNames">
    <list><value>configBean</value></list>
  </property>
</bean>

Das auf Spring basierende CMS CoreMedia benötigt für seinen ViewResolver eine abweichende Konfiguration:

<beans xmlns="http://www.springframework.org/schema/beans">
 <xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <xmlns:util="http://www.springframework.org/schema/util">
 <xmlns:customize="http://www.coremedia.com/2007/coremedia-spring-beans-customization">
 <xsi:schemaLocation="http://www.springframework.org/schema/beans>
 <http://www.springframework.org/schema/beans/spring-beans-2.0.xsd>
 <http://www.coremedia.com/2007/coremedia-spring-beans-customization>
 <http://www.coremedia.com/2007/coremedia-spring-beans-customization.xsd>
 <http://www.springframework.org/schema/util>
 <http://www.springframework.org/schema/util/spring-util-2.0.xsd">

Autor: Stephan Scharff-Rahn

HTTP Basic Authentifizierung & CoreMedia HttpCache

Authentifizierungsmöglichkeiten gehören zu den häufig vorkommenden Elementen in einer Webapplikation. Diese können auf z. B. über ein Loginformular Cookie-/Session-basiert oder per HTTP-Authentifizifierung mit den Ausprägungen Basic und Digest umgesetzt werden.

Im folgenden Fall soll eine HTTP-Basic Authentifizierung möglich sein. Dafür setzt man in Java folgende Response-Header erforderlich:

response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
response.setHeader("WWW-Authenticate", "Basic realm=\"Realm\"");

Für das hier beschriebene Beispiel liegt eine Webapplikation auf Basis der CoreMedia CAE zugrunde. Als Besonderheit sollen die Zugangsdaten im CMS gepflegt werden, wobei Dokumente oder ganze Verzeichnisstrukturen eine Abhängigkeit auf diese Zugangsdaten haben.

Die Besonderheit erfordert nun, dass zum Ermitteln der Zugangsdaten das (über den Request) aufgerufene Objekt (“self”) bereits verfügbar ist. Somit liegt nahe, die Authentifizierung im Controller stattfinden zu lassen:

//...
String username = self.getUsername();
String password = self.getPassword();

if (.../** username and passwort not empty **/) {
 Enumeration headerNames = request.getHeaderNames();
 String[] credentials = null;
 while (headerNames.hasMoreElements())
 {
   String next = (String) headerNames.nextElement();
   if (AUTH_HEADER_NAME.equalsIgnoreCase(next))
   {
     authHeader = request.getHeader(next);
     if (authHeader.startsWith("Basic "))
     {
       authHeader = authHeader.substring(authHeader.indexOf("Basic ")
                    + "Basic ".length());
       String decryptedKey = "";
       try
       {
         decryptedKey = new String(org.apache.commons.codec.binary
               .Base64.decodeBase64(authHeader.getBytes("UTF-8")),
               "UTF-8");
       } catch (UnsupportedEncodingException e){}

       credentials = decryptedKey.split(":");
     }
   }
 }
 if (credentials == null || credentials.length != 2
    || !username.equals(credentials[0])
    || !password.equals(credentials[1])) {
   response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
   response.setHeader("WWW-Authenticate", "Basic realm=\"Realm\"");
   return null; //return null ModelAndView
 }
}
//...

Dies funktioniert solange gut, wie keine Caching-Schicht vorgelagert ist. Wie man sich denken kann, sind Seiten, welche geschützt sein sollen, nicht die besten Kandidaten zum Cachen, da bei der Auslieferung gecachter Seiten keine weiteren Überprüfungen stattfinden.

Der CoreMedia HttpCache

Eine Variante und Komponente der CoreMedia CAE, welche das Cachen ganzer Seiten wie auch von Seitenfragment unterstützt, ist der HttpCache. Dieser legt im Dateisystem ausgewählte Response-Daten ab, wobei die Zugehörigkeit zu einem Request sowie sämtliche beim Erzeugen des Response anfallenden Content-Abhängigkeiten getrackt werden. Dem HttpCache liegt dabei der PersistentCache zugrunde, welcher auch bei der PAE Anwendung findet.

Welche Requests und Responses berücksichtigt werden sollen, lässt sich flexibel Konfigurieren. In der Standardkonfiguration werden Responses anhand von Response-Codes und Cache-Headern gefiltert.

Ist nun der HttpCache vor die CAE geschaltet, so gibt es mit der Http-Authentifizierung Probleme:

• Der Standard-Implementierung entfernt vor Weitergabe des Requests an die CAE sämtliche Request-Header. Dadurch kann in der CAE niemals ein Login erfolgreich ausgewertet werden, weil eben auch der Authentifizierungsheader wegfällt.
• Ließe man nun durch eine angepasste Implementierung diesen Header durch, so ergibt sich bei weiterer Betrachtung das Problem, dass die Seiten zumindest nach erfolgreicher Authentifizierung gecached werden. Für jeden nachfolgende Request (egal von welchem Client) würde der HttpCache nun die gecachte Seite ausliefern, der Controller wird gar nicht erst angesprochen.
  Auch hier wäre wiederum denkbar, entsprechende eigene Anpassungen am HttpCache vorzunehmen. Sofern möglich, werde ich ein Beispiel dazu später posten.

Im aktuellen Beispiel gibt es allerdings eine weitere Hürde: Vor die CAE (mit dem HttpCache) ist ein Apache Server geschaltet. Dieser nimmt die Requests entgegen und liefert entweder die Dateien aus dem HttpCache-Verzeichnis direkt aus oder leitet, wenn die Zieldatei nicht vorhanden ist, an die CAE per RewriteRule weiter. Möglich wird dies, da der HttpCache erlaubt, Responses als vollständige Http-Seiten in einer gültigen URL-Pfadstruktur abzulegen.

In diesem Fall liegt die Passwort-Kontrolle also völlig außerhalb der CAE, wenn denn das Caching notwendig ist. In diesem Fall sei gesagt: Ohne tiefen Eingriff in die HttpCache-Mechanismen ist das Caching von geschützten Seiten definitiv nicht möglich. Z. B. müsste der HttpCache dazu in der Lage sein, Content-Abhängig im Cache-Verzeichnis .htaccess und entsprechende Zugangsdaten abzulegen und bei Seiteninvalidierung zu löschen.Im Fall von Sessionbasierter Authentizierung wäre es noch problematischer.

Aus diesem Grund sollte, sofern der Anwendungsfall es zulässt, für die geschützten Bereich auf das Caching verzichtet werden.

Variante: Servlet-Filter zum Lesen der Authentifizierungsheader

Der hier skizzierte Weg stellt nur eine von mehreren Möglichkeiten dar!

Ein Servlet-Filter kann die Header-Daten zunächst lesen. Dieser Filter muss in Reihenfolge vor dem HttpCache-Filter liegen, da letzterer wie oben beschrieben die Header entfernt.

public class AuthenticationFilter implements javax.servlet.Filter
{
  //...
  public void doFilter(...) throws IOException, ServletException
  {
    if (request instanceof HttpServletRequest) {
      //get header and decode - extraced from code above to utility
      String[] processRequestHeader = AuthentificationUtil.
             processRequestHeader((HttpServletRequest)request);
      CredentialsThreadLocal.set(processRequestHeader);
    }
    chain.doFilter(request, response);
    CredentialsThreadLocal.set(null);
  }
  //...
}

<!-- Auszug web.xml -->
<filter>
 <filter-name>authFilter</filter-name>
 <filter-class>my.package.AuthenticationFilter</filter-class>
</filter>

<!-- ... -->

<filter-mapping>
 <filter-name>authFilter</filter-name>
 <url-pattern>/mydispatcher/*</url-pattern>
</filter-mapping>
<filter-mapping>
 <filter-name>httpCacheFilter</filter-name>
 <url-pattern>/mydispatcher/*</url-pattern>
 <dispatcher>REQUEST</dispatcher>
 <dispatcher>ERROR</dispatcher>
</filter-mapping>

Die Informationen schreibt der Filter dazu in eine ThreadLocal-Variable, damit der Controller die Daten später auswerten und mit den contentabhängigen Werten vergleichen kann.

//threadlocal impl
public class CredentialsThreadLocal
{
 private static ThreadLocal<String[]> tLocal =
                                      new ThreadLocal<String[]>();

 public static void set(String[] credentials) {
 tLocal.set(credentials);
 }

 public static String[] get() {
 return (String[]) tLocal.get();
 }
}

//Auszug gekürzter Controller
if (.../** username and password not empty **/) {
 String[] credentials = CredentialsThreadLocal.get();
 if (credentials == null || credentials.length != 2
    ||!username.equals(credentials[0])
    || !password.equals(credentials[1])) {
  response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
  response.setHeader("WWW-Authenticate", "Basic realm=\"Realm\"");
  return null; //return null ModelAndView
 }
}
//..

Ist die Authentifizierung erfolgreich, so wird der Content normal geliefert. Ist die Authentifizierung nicht erfolgreich (was beim ersten Request des Clients der Fall ist), so werden die notwendigen Response-Header gesetzt.

Caching-Vermeidung

Zur Unterdrückung des Cachings müssen im Erfolgs- wie auch im Abfragefall folgende Header hinzugefügt werden:

//Auszug gekürzter Controller
if (.../**username and passwort not empty **/) {

 response.setHeader("Pragma", "no-cache");
  response.setHeader("Cache-Control", "no-cache");

 String[] credentials = CredentialsThreadLocal.get();
 //... and previous code
}
//..

Dadurch ist der HttpCache informiert, dass die Antworten nicht gecached werden sollen. Für die Apache – CAE – Konstellation ergibt sich somit: Der Apache kann niemals die geschützten Dateien aus dem HttpCache-Verzeichnis ausliefern, da sie dort nicht existieren. Jede Anfrage läuft zur CAE durch.

Fazit

Wie bereits erwähnt ist dies ein möglicher Fall für die besondere Konstellation mit CAE, HttpCache und vorgelagertem Apache.

Insbesondere durch das direkte Lesen des Apaches aus dem HttpCache-Verzeichnis ist die Gefahr, geschützten Content ungeschützt auszuliefern, gegeben.

Über andere Serverkonfigurationen ist somit empfehlenswerter Weise nachzudenken, wenn das Caching definitiv gewährleistet sein soll. Dazu stellt die Implementierung von eigenen HttpCache-Bestandteilen (Request & Response-Predicates) eine gute Alternative zum Verzicht auf den HttpCache dar, sofern wirklich jeder Request zur CAE durchgegeben wird (wo er zuerst im HttpCache-Filter landet).

Anmerkung: Abgebildete Codes sind zur einfacheren Darstellung nicht refactored.