pwnt.be

U weet het of u weet het niet, maar onlangs keilde ik mijn HTC Desire buiten om een Nokia Lumia 800 aan te schaffen. Initieel was ik van plan om een vrij lovende recensie neer te pennen, maar dat is al meer dan een maand geleden. Sindsdien liep het net even anders.

Nokia Lumia 800 door neonbubble
Sommige rechten voorbehouden

Ik had dus al zo’n twee jaar de Desire, destijds het vlaggenschip onder HTC’s Android-smartphones. Na veel gehannes met custom ROMs en frustratie over de aparte vormgeving van Android en zijn apps, besloot ik dat het welletjes was geweest. Weg met Googles vrije OS en uit met het geklooi.

Intussen was ik meer dan gecharmeerd geraakt door Windows Phone. Bij de lancering was Microsofts nieuwe mobiele besturingssysteem duidelijk nog niet helemaal klaar, en hoewel versie 7.5 nog steeds niet bulkt van de features, valt niet te ontkennen dat Windows Phone gewoon wérkt. Terwijl Android en iOS elkaar voortdurend naar de kroon steken met herkauwing na herkauwing, doet Microsoft zijn eigen ding en levert het de volgende generatie mobiele besturingssystemen af. Of de derde hond ooit effectief met het been gaat lopen, zal de tijd moeten uitwijzen.

Edoch, een mobiel besturingssysteem heeft hardware nodig. Qua form factor beviel mijn Desire me best, dus ik was er niet rouwig om dat Windows Phone voluit ging voor 480×800 pixels op 3,7″. De keuze ging dus tussen de HTC Radar, de Samsung Omnia 7 en de Nokia Lumia 800. De HTC viel meteen af, enerzijds omdat ik niet weggeblazen werd door de knoppen van de Desire (en de Legend die ik er destijds voor inruilde) en anderzijds omdat het gewoon eens tijd werd voor een andere fabrikant. En de Samsung? Als ik mijn Google-resultaten mocht geloven, barstte die eenvoudigweg uit elkaar. Het gebruikelijke “Samsungplastic”, een prettig vooruitzicht!

De Nokia Lumia 800 daarentegen gooide hoge ogen. Met de eerste Windowstelefoon sinds Microsoft een belang nam in de Finse telecommastodont, werd en wordt het alles of niets. De Lumia kostte me dan wel 100 euro meer dan de Samsung, maar oogt stukken mooier en kan teren op Nokia’s jarenlange reputatie van oerdegelijkheid. Of niet?

Welaan. Na de zwarte versie van de telefoon vijf dagen in gebruik te hebben gehad, merkte ik op dat de Power-knop aan de zijkant loszat en rammelde. Ik ging op Twitter te rade bij zowel Coolblue, waar ik het toestel had aangeschaft, als bij Nokia zelf. Beide bevestigden snel dat dit niet normaal was en raadden aan het toestel terug te sturen:

Dat deed ik dan ook, in de veronderstelling dat het euvel enkele dagen later verholpen zou zijn.

Wie al eens iets kocht bij Coolblue, weet dat ze er prat op gaan bestellingen de volgende dag te leveren. Na verschillende vlekkeloze aankopen bij de van oorsprong Nederlandse webwinkel, verwachtte ik me aan een vlotte afhandeling van mijn probleem. Dat draaide helaas behoorlijk anders uit.

Ik stuurde het toestel dus kosteloos terug met bpost. Aan de hand van mijn trackingcode kon ik vaststellen dat het pakket binnen de 24 uur op zijn bestemming was. Op de website van Coolblue bleef de status van mijn retour echter ongewijzigd. Toen ik nog een dag later op Twitter peilde naar de toestand, wist men te melden dat het pakket nog niet was aangekomen. Van een handelaar die me zelf een bpost-trackingcode doorspeelt, verwacht ik zo’n flater niet meteen. Soit. Enkele uren later bleek het pakket dan toch terecht.

Dat was echter maar het voorprogramma. Gedurende de daarop volgende weken moest ik telkens opnieuw zelf het initiatief nemen om naar de status van mijn retour te peilen, waarna me telkens weer werd gevraagd om mijn retournummer en beloofd werd dat het zou worden nagekeken. Voor zover ik me kan herinneren, heeft Coolblue geen enkele keer contact met me opgenomen zonder dat ik er zelf om vroeg, ondanks systematisch afsluiten met “We houden je op de hoogte!’ Qua klantenbinding kan dat tellen.

Hoe dan ook, gelukkig werd er wel degelijk iets gedaan met mijn defecte Lumia. Coolblue nam contact op met Nokia, alwaar men beweerde dat wat speling op de knoppen aanvaardbaar was. Noem me een pietlut, maar wanneer ik 469 euro neertel voor een smartphone, dan verwacht ik niet dat de knoppen rammelen wanneer ik het toestel beweeg. De verklaring is echter niet ver te zoeken: even googelen verraadt dat opvallend veel recensenten geconfronteerd werden met een soortgelijk probleem.

In bovenstaande tweet liet Nokia België echter weten dat een loszittende knop níét normaal was. Ik speelde die dan ook door aan Coolblue, waar men Nokia nogmaals interpelleerde. In tweede instantie besloot men dan toch om het toestel te vervangen. Intussen waren we zo’n maand verder, maar goed, ik mocht een nieuw toestel in ontvangst nemen …

… met een al even loszittende Power-knop. Ja, u leest het goed. Nochtans beweerde men bij Coolblue het nieuwe toestel te hebben onderzocht. Bovendien had ik de accessoires samen met het toestel teruggestuurd – ik rekende op een ruil binnen de wettelijk vastgelegde bedenktijd van twee weken – en waren die onderweg verdwenen. Dat kan natuurlijk allemaal gebeuren, maar geef toe: het stapelt zich op.

Gelukkig was er Twitter. Mike, de immer behulpzame man achter @NokiaBE, regelde na een uitgebreide klachtenmail een nieuwe retour voor me. Wonder boven wonder werd daags na ontvangst al een nieuwe Lumia 800 opgestuurd, zowaar met degelijke knoppen. Die was vergezeld van een persoonlijke brief, waaruit ik drie zaken kan afleiden. Ten eerste: bij Nokia zijn ze terecht als de dood voor negatieve geluiden op sociale media. Ten tweede: zelfs bij een prijzige smartphone mogen knoppen wat Nokia betreft loszitten, tenzij de klant dat ervaart als storend. En ten derde: Peter van Nokia Care kan misschien beter iets doen aan zijn Nederlands.

En mijn accessoires? Die waren achtergebleven bij Coolblue. Als kers op de taart beweerde men daar dat ze werden teruggestuurd naar Nokia, terwijl die laatste dit tegensprak. Uiteindelijk ontving ik ze enkele dagen later dan toch. Intussen had ik al een extra hoesje aangeschaft om die fragiele knoppen te beschermen, ook al zit er eentje bij de accessoires; ik wachtte stilaan immers wel al lang genoeg, nee?

Na zes weken kan ik dus eindelijk mijn Lumia 800 voor de derde keer in gebruik nemen. Voorlopig valt er weinig aan te merken op de knoppen. Gaan ze toch weer meteen stuk, dan weten we dat ook weer. Het zal u niet verbazen dat ik in de toekomst wel twee keer zal nadenken alvorens iets aan te schaffen bij Coolblue of Nokia. En dat vind ik zelf ook erg jammer.

Wie nu een rekening opent bij Keytrade Bank en daarbij de promotiecode MM2517847323 vermeldt, krijgt zomaar eventjes 30 euro startkapitaal op zijn gratis rekening gestort. Addertjes onder het gras? Geen.

Keytrade Bank

Voor wie het nog niet wist: Keytrade-klanten genieten gratis van:

• een zichtrekening met 1,00% interest,
• een betaalkaart met Proton en Maestro,
• een premie van 5 cent per transactie,
• een spaarrekening met 1,65% basisrente en
• een beursrekening met competitieve tarieven.

Dit alles wordt nog steeds aangeboden via een prima uitgewerkte en beveiligde webinterface. Ikzelf ben al jaren tevreden Keytrade-klant en ben ervan overtuigd dat uw ervaring minstens even positief zal zijn. Aarzel dus niet en word gratis klant! Graag gedaan!

Noot: Deze actie liep van 21/02/2012 tot en met 06/04/2012.

On Apache Tomcat 7, deploying and undeploying Java EE webapps on the fly is straightforward thanks to its Manager app. You just head on over to /manager, log in with a manager-gui user, and click around. Alternatively, you use the Client Deployer with a manager-script user to connect to the Manager’s REST-like API. That’s all well and good, but there’s a huge catch …

For, you see, as access to the Manager is defined on a per-host basis, any user who can deploy to application context /foo on your host can also deploy to context /bar. Consequently, if you want to share a host between users, there is no waterproof way to keep them from messing with each other’s apps.

How to Fix It

One solution to this is to define a virtual host for each user or group of trusted users. However, in some cases, this is just not practical. For instance, personally, I’m dealing with teams of students, who will each be asked to deploy an app to a context path which has been allocated for them. Without fine-grained access control, there is no way to keep the team12 user from manipulating the app at /team07, for instance. This principle might still be extended to provide contexts for both an unstable and a stable version of the app, but the fact remains that access control is desirable. Moreover, the solution I am about to provide is easily extended.

So, yes, I am going to explain how to add access control to Tomcat’s Manager app. This tutorial requires a tiny bit of coding, but it’s not as bad as it sounds.

What we’re going to be doing is writing a filter, which is essentially a component that gets called before the actual app. Thus, we’re going to be intercepting certain calls to the Manager app to see if their actions are allowed, and if not, we won’t pass them to the Manager and throw an error instead.

Prerequisites

First off, if you don’t have a Java EE IDE installed yet, get one. I’m going to be describing the required steps for NetBeans IDE 7.1, but Eclipse and friends should work fine. Just make sure your environment supports Java EE.

Set Up the Project

Fire up NetBeans and create a new project. You might be tempted to create a Java EE project. That would probably work, but personally, with version 7.1 of NetBeans, I am unable to select my Tomcat instance as a server.

Luckily, you can just as easily start off with a Java Application, so let’s do that instead. Under File, select New Project, or just use the toolbar button. Give the project a meaningful name—say, TomcatManagerAuthenticator. Don’t create a main class; it’s no problem if you do, but it’s simply not necessary.

The only downside to a Java Application project is that it does not include the Java EE libraries. Rectify this by right-clicking on Libraries under your new project, and selecting Add Library. Choose Java EE 6 API Library and add it. You are now ready to start writing the filter code.

Write the Filter

A filter is actually just another Java class, which implements Java EE’s servlet Filter interface. Let’s create such a class. Right-click your project and, under New, select Java Class. Name the class MyManagerFilter or whatever you like. Using a package other than the default—i.e., empty—is not necessary.

You’ll then see the code for the empty MyManagerFilter class. Make it implement the Filter interface, as shown below this paragraph. At the end of this section, you’ll find a complete implementation of the class.

public class MyManagerFilter implements Filter {
  public void init(FilterConfig filterConfig)
      throws ServletException {
  }

  public void doFilter(ServletRequest request,
      ServletResponse response,
      FilterChain chain)
      throws IOException, ServletException {
  }

  public void destroy() {
  }
}

Now, let’s see how we can actually intercept those HTTP requests to the Manager app. Upon each of them, the doFilter method of our filter will get called. Consequently, we can examine the request parameters to find out who is the user who is currently logged in, and which app he is trying to manipulate. The user name is part of HTTP’s Authorization header and is easily obtained. The path to the application which is being managed is consistently passed via a GET parameter called path. Thus, placing the following code in doFilter tells us everything we need to know:

HttpServletRequest hreq = (HttpServletRequest) request;
String user = hreq.getRemoteUser();
String path = request.getParameter("path");

Note that all of this applies to both the Manager’s HTML-based GUI and its text-based REST interface, for use with the Client Deployer.

How the variables user and path are further used depends on your exact goal. Regardless, either the call is allowed or it isn’t, so let’s represent this using a boolean variable and work from that:

boolean allowed = isAllowed(user, path);
if (allowed) {
  // Forward the request.
  chain.doFilter(request, response);
} else {
  // Throw a HTTP 403 (Forbidden) error.
  HttpServletResponse hresp = (HttpServletResponse) response;
  hresp.sendError(HttpServletResponse.SC_FORBIDDEN);
}

That’s all there is to doFilter, but we have yet to implement our own function isAllowed. I’ve cooked up a sample implementation of MyManagerFilter, which should get you started. You could, for instance, retrieve the access control list—i.e., userToApps in the code—from an XML file. Remember that any user names you would like to use will also need to be defined in Tomcat’s tomcat-users.xml file, each with the appropriate role.

Compile the Project

Save MyManagerFilter.java. You are now ready to compile this source file to the equivalent MyManagerFilter.class. To do so, select Build Main Project from NetBeans’s Run menu, or just hit F11.

If you navigate to the project folder in Windows Explorer (or something equivalent), you’ll find a folder called build, containing a classes folder with the class file you’re looking for. If you’re having trouble finding the project folder, right-click on your NetBeans project and select Properties.

Keep your Explorer window open, since you’ll need that class file in a second.

Add the Filter to the Manager

There are two steps to installing the newly created filter class on your Tomcat instance. First, you need to copy the physical file MyManagerFilter.class to the Manager app’s directory structure. Second, the app’s configuration needs to be updated to include the filter in the invocation chain.

So, let’s first place the filter class on the server. Your Tomcat installation directory contains a webapps folder by default. Inside it, there is a folder called manager, which contains (part of) the Manager app. Inside that, there should be a folder called WEB-INF. In there, copy your NetBeans project’s classes folder, which only contains MyManagerFilter.class. If, for some reason, WEB-INF already contains a classes folder, just add your class file to it.

Also in WEB-INF is a file called web.xml. Open it in a text or XML editor. This file tells Tomcat how to run the Manager app. There should already be some <filter> and <filter-mapping> elements in there. In a very similar way, we’ll add our own filter to the chain. Below them, just add this code snippet:

<filter>
  <filter-name>MyManagerFilter</filter-name>
  <filter-class>MyManagerFilter</filter-class>
</filter>

<filter-mapping>
  <filter-name>MyManagerFilter</filter-name>
  <url-pattern>/text/*</url-pattern>
</filter-mapping>

The first part informs Tomcat of the filter’s existence. The second part tells it to apply the filter to any URL belonging to the Manager app that starts with /text/. This ties the filter to the REST API. If you’d like to use it on the HTML GUI instead, just change text to html.

Test Things Out

And that’s pretty much it! In the mean time, Tomcat will have detected the change in configuration and the Manager app will have been reloaded. However, if you’ve turned this feature off for whatever reason, or if you’re simply unsure, just restart Tomcat to be safe. If you entered text above, try to deploy some apps using the Client Deployer; if you entered html, point your browser to the Manager, try some different logins, and poke around.

If you’re stuck at any point, feel free to leave a comment below. I’ll probably be extending this tutorial with some nice screenshots in the future.

Final Notes

A lot of this stuff is part of Java EE rather than Apache Tomcat, so it could also be applicable to other application servers, such as GlassFish. If you have any pointers for users of those, be sure to drop a line.

Finally, credit goes to Tim Funk, who coined the basic idea for this approach on the Tomcat user mailing list way back in 2003. Since it took me a while to dig that up and I couldn’t find a complete example, I figured I’d write this tutorial. I hope it’ll be of use to anyone trying to secure their Tomcat instance.

Na vier lange maanden de lippen stijf op elkaar te hebben gehouden, kan ik dan eindelijk in de pen kruipen. Mijn aantreden bij de Canvascrack is op het scherm geweest en u zag dat het helaas snel in mineur eindigde.

Met dank aan Johan Jacobs voor de foto

Dames, heren, het cliché klopt: het is thuis op de sofa zovele malen eenvoudiger dan in de studio. Met een hart dat in de keel bonkt, liggen inschattingsfouten voortdurend op de loer. Maar kijk, ik wind er geen doekjes om: ik heb gewoon slecht gespeeld.

Net daarom is het natuurlijk knullig om op die manier ook nog eens crack te worden, nota bene ten koste van iemand die het in mijn ogen zeker en vast tot supercrack had kunnen schoppen. En al kregen we een (naar mijn mening) moeilijk setje vragen voorgeschoteld, niemand wil crack worden met zo’n score. Mijn verontschuldigingen aan de morele supercrack waren en zijn dan ook van oprechte aard.

Los daarvan weze het uit mijn toelichting bij de beoordelingen duidelijk dat ik mijn laatste twee tafels binnen had kunnen (en moeten) rijven. Plus était en moi, maar de twijfel heeft me genadeloos genekt. Weten dat je dat enkel en alleen aan jezelf te danken hebt, valt best zwaar. Ik geef grif toe dat het me zelfs enkele uren slaap heeft gekost – uren waarin ik een eerste versie van dit stukje neerpende.

Maar laten we ook niet dramatiseren, want het is tenslotte maar een spel. Flaters ten spijt, blijf ik mijn deelname aan de Vlaamse quiz bij uitstek als een erg positieve ervaring bekijken. De preselecties en opnames zinderden onvermijdelijk na en ik behoor voortaan hoe dan ook tot het selecte clubje van mensen die effectief Canvascrack zijn geweest. Had ik het liever anders gezien? Vanzelfsprekend. Heb ik er al spijt van gehad? Geen moment.

En tot slot nog voor de pietlutten onder u:

• Ja, “Panta rhei” was de enige Griekse uitdrukking. Ik wou benadrukken dat ik niet meer wist wat ze betekende, ook al had ik door eliminatie wel afgeleid dat het het correcte antwoord was. Het is geen praatprogramma en ik ben allerminst een begenadigd redenaar.

• Aangezien het tennis één van de weinige sporten is die me kan boeien, kende ik de nationaliteiten van de drie spelers wel degelijk. Wat ik me niet met zekerheid kon herinneren, was of enkel de fotograaf in kwestie een Duitser was of ook de tennisspeler. Soms ontsnapt de vraag je, zeker aan het eind van de aflevering, wanneer de stress in je kleren zit. Meer kan ik daar niet over zeggen.

Update: Mocht u het allemaal gemist hebben, dan kunt u het ook integraal online bekijken. Dit alles dankzij Lennart, mijn favoriete student van de dag.

It’s here then: the final installment in the 30 Day Song Challenge. And it only took me four months to complete the thing. Anyway, let’s go out on a bang.

Day 30: Your Favorite Song at This Time Last Year

Around this time last year, I went looking for music along the stylings of Swedish bitpop sensation Slagsmålsklubben, whose work I totally adore, as mentioned. Most notably, I came across their fellow countrymen Pluxus.

If Pluxus’s song Transient sounds familiar, that’s probably because it was used in a Ford Fiesta commercial. I’m also rather partial to Pluxemburg, which is also the name of the band’s label, but Transient seemed more accessible.

So there you have it: thirty songs in thirty days—sort of. While you’re here, why not revisit them all? Better yet: take the challenge yourself. Do it.