De Browser-Back Button

De Browser-Back knop op internetschermen is een zege voor de eindgebruiker en een nachtmerrie voor de webapplicatie-bouwer. De eindgebruiker is er blij mee, omdat hij altijd naar een vorige situatie terug kan. De bouwer is er niet blij mee, want met deze knop verliest hij de controle op de volgorde van te bezoeken webpagina’s.

Bovendien heeft de Browser-Back button een zusje: de Browser-Forward button. En richten verschillende browsers het gedrag van de Browser-Back knop verschillend in.

Hieronder beschrijven we welke concepten we hebben gebruikt om de Browser-Back button op te vangen in een webapplicatie met een flexibele workflow. Onze oplossing is gebouwd in Java, maar de concepten zullen ook in andere programmeeromgevingen bruikbaar zijn. Wij hebben onze oplossing toegepast in een adresboek ontwikkeld voor een Onderzoeksbureau van de Rijksoverheid. Voor het toevoegen van een nieuwe medewerker moeten de volgende stappen doorlopen worden.

1. Voer naw gegevens van de medewerker in
2. Voeg de medewerker toe aan 1 of meer categorien
3. Controleer de gegevens van de nieuwe medewerker
4. Voeg de gegevens toe aan de database
5. Meld dat de actie is uitgevoerd

De invoer van de gegevens gebeurt met jsp’s. Een jsp wordt voorafgegaan door een Access-servlet, waarin autorisaties worden geverifieerd en helpers worden gevuld. Deze helpers worden gebruikt om de informatie in de jsps te tonen, en te zorgen dat de jsps niet te complex worden. De oplossing om de Browser-Back button op te vangen maakt gebruik van:

1. Cookies om de ingang van de jsp via de Access files te garanderen
2. een server-worker pattern voor hergebruik van de code
3. Een stack met variabelen voor het bewaren van scherminvoer

Cookies
Wanneer de eindgebruiker op de Browser-Back toets klikt, dan gaat de browser terug naar de vorige pagina. Deze vorige pagina kan de jsp zijn, of de Access voorafgaand aan de jsp. Dit is afhankelijk van de instellingen van de browser, i.e. dit wordt buiten de applicatie-code geregeld. Om te garanderen dat jsps altijd via de bijbehorende Access file benaderd worden, zetten we de cookie “entrypage” in de Access file. De eerste actie bij binnenkomst van de jsp is het verwijderen van de cookie. Als de jsp vervolgens benaderd wordt zonder de Access uit te voeren, dan wordt eerste de Access-page uitgevoerd, en daarna de jsp.

Deze techniek is ontwikkeld op basis van diverse engels-talige bijdragen en voorbeelden die over dit onderwerp op internet te vinden zijn.

Cookies moeten op de goede plek in de hierarchie ingezet worden. Met de Webdeveloper plugin van de firefox browser kun je eenvoudig controleren of de cookies juist in de hierarchie worden geplaatst.

Service-to-Worker pattern
Het Service-to-Worker pattern is een elegante manier om workflows te bouwen en tegelijk het aantal servlets en access-classes te beperken. Bij het Service-to-Worker pattern worden de functionaliteit en de volgorde van de stappen van elkaar gescheiden. Je krijgt dus een bestand met stap-volgordes, in ons geval een xml bestand. Een regel in het xml-bestand bestaat uit een start-status, een doel-status en een actie. Wanneer de applicatie in start-status is, dan gaat hij naar doel-status na het succesvol uitvoeren van de actie. Wij hebben deze techniek gehaald uit:

J2EE Design Patterns, William Crawford and Jonathan Kaplan, O’Reilly, 2003

Doordat de functionele classes en jsps geen workflow informatie bevatten kun je ze op verschillende plekken in verschillende workflows hergebruiken. Hergebruik komt de kwaliteit en de onderhoudbaarheid van de software ten goede.

Maar omdat de functionaliteit en de workflow van elkaar gescheiden zijn, staat in de jsps niet meer aangegeven wat de volgende stap is. Dat is geen probleem wanneer de jsps in volgorde achter elkaar worden uitgevoerd, dan is immers het xml-bestand met de stap-volgordes leidend. Maar dat is wel een probleem wanneer een eindgebruiker op de Browser-Back of de Browser-Forward klikt. Dan wijzigt de eindgebruiker de volgorde van stappen buiten het xml-bestand om.

Onze oplossing is een link te bouwen tussen de jsps en het xml-bestand met stapvolgordes. Deze link is de naam van de jsp, die een jsp altijd zelf kan bepalen., en die overeenkomt met een start-status in het xml-bestand. Zo kan de web-applicatie altijd dynamisch bepalen wat de volgende stap is en welke stap dan uitgevoerd moet worden.

De search-stack
Door ervoor te zorgen dat een jsp altijd voorafgegaan wordt door een Access pagina, kan informatie die de eindgebruiker handmatig op een scherm invoert verloren gaan. Om de eindgebruiker beter van dienst te zijn bewaren we in een stack de laatste keuzes van de eindgebruiker.

Essentieel in de stack is het veld entrypage. In dit veld staat de naam van de Accessfile waarmee de jsp benaderd wordt. Bij binnenkomst zoekt de Accessfile het stackitem met de juiste naam en haalt de meest recente gegevens uit dit stackitem.

In de stack wordt en teruggezocht en vooruitgezocht. In die zin is het niet een echte stack. Bij het uitvoeren van een actie vanaf een pagina midden in de stack worden de items boven deze plek uit de stack gehaald.

Samenvatting
Omdat de Browser-Back knop zoveel waarde heeft voor de eindgebruiker moet deze button in een webapplicatie beschikbaar blijven. Wij gebruiken in onze applicaties een combinatie van:

1. Cookies, om af te dingen dat jsps altijd benaderd worden vanuit de Access file
2. Een Service-to-Worker pattern met als status de jsps om hergebruik van code te bevorderen
3. Een stack om de laatste invoer van de eindgebruiker te bewaren

Let op: wellicht zijn cookies niet nodig, en kun je de binnenkomst van een jsp via de Access file afdwingen met zgn filters. Als jij daar ervaring mee hebt, of als je andere verbeteringen in deze aanpak ziet, dan stel ik een reactie op prijs.

Sophie Fischer
Sponiza !T
www.sponiza.nl
www.etikettenprinten.nl

Praktijk: installatie iDEAL advanced Java

Wanneer u producten of diensten verkoopt op het internet dan kunt u uw klanten verschillende betaalmethoden aanbieden:

- Betalen dmv een overschrijving
- Betalen met een creditcard
- Betalen via Paypal
- Betalen via het internet

Voor de toepassing etikettenprinten.nl bieden wij de eerste vorm, overschrijving, en de laatste vorm, betalen via internet, aan. Het voordeel voor de klant van internet-betalen is dat zijn betaling zeer snel verwerkt wordt. Zodra de betaling binnen is, kan de klant de adressen op etiketten printen. Het voordeel voor ons is dat we online-betalingen automatisch in onze boeken kunnen verwerken. Facturen worden automatisch naar de klant en de boekhouding gestuurd en de BTW aangifte wordt automatisch bijgewerkt.

Maar daar hebben we wel wat voor moeten doen. We hebben voor de internet-betalingen een contract afgesloten met de Postbank. Daarnaast hebben we onze webwinkel aangepast op basis van iDEAL.

In deze bijdrage laten wij zien hoe wij iDEAL Advanced voor java hebben geintegreerd, welke problemen we zijn tegengekomen, en hoe wij die hebben opgelost. Misschien helpen onze ervaringen anderen die voor eenzelfde keuze staan. Wilt u deze informatie op uw eigen computer opslaan? Dat kan, want we hebben deze bijdrage als pdf-document bijgevoegd.

Wat is iDEAL: iDEAL is een betaalstandaard voor veilige en directe betalingen over het internet. Verschillende banken werken met iDEAL waaronder de Postbank, ING, de Rabobank, ABN en Fortis. iDEAL is gebaseerd op dezelfde technieken als internetbankieren, en is daardoor net zo veilig. Bovendien gaan betalingen op dezelfde wijze als internetbankieren, waar de klant al vertrouwd mee is.

Verschillende banken bieden verschillende methoden aan voor die integratie. De Postbank geeft 2 varianten: iDEAL basic en iDEAL advanced. Wij hebben de variant iDEAL advanced gebruikt.

Het integreren van iDEAL basic met een webwinkel is het eenvoudigst, maar geeft minder mogelijkheden voor het automatisch afhandelen van betalingen. iDEAL advanced integreren is lastiger en vraagt technische kennis. Wanneer u ervaren bent in het ontwikkelen van web-toepassingen kunt u zonder probleem iDEAL advanced gebruiken. Wanneer u deze ervaring niet heeft, dan zult u iemand moeten inhuren die die ervaring wel heeft.

Bekijk ter verdere verduidelijking van het verschil tussen iDEAL basic en iDEAL advanced de stappen van het betalingsproces:

Actie	Omgeving
1. Bestelling plaatsen	Klant
2. Bank selecteren	Klant/Bank
3. Klant betaalt	Bank
4. Betaling wordt verwerkt	Klant/Bank
5. Melding betaling ontvangen	Klant

Het verschil tussen iDEAL basic en iDEAL advanced zit in de stappen 2. en 4. Bij iDEAL basic regelt de bank deze stappen, bij iDEAL advanced zorg de ondernemer hier zelf voor.

Weet u niet wat u moet kiezen? Kies dan eerst voor iDEAL basic. U kunt altijd later nog kiezen voor iDEAL advanced, bijvoorbeeld als u merkt dat u zoveel via het internet verkoopt, dat u dat niet meer met de hand wilt bijwerken.

Start iDEAL: Om iDEAL te gebruiken meldt u zich bij de bank waar u een zakelijke rekening heeft. Kijk op www.ideal.nl, onderdeel Zakelijk – helemaal onderaan, wanneer u de informatie niet snel op de website van uw bank kunt vinden.

Wij ontvingen na aanmelding de inloggegevens voor de iDEAL test-site, ook wel het dashboard genoemd.

Integreren iDEAL – java advanced Postbank: Wanneer u iDEAL niet zelf gaat installeren dan zijn deze en de volgende secties misschien minder interessant voor u. Wanneer u iDEAL wel zelf gaat installeren, maar via een andere bank, of via PHP, dan kunnen deze en de volgende secties het algemene begrip vergroten en helpen bij troubleshooten.

Op de idealtest-site staat een zip-download-bestand met daarin bestanden die gebruikt kunnen worden voor de installatie van iDEAL advanced. Het gaat om een handleiding, een referentiegids (achtergrond informatie), een demoshop (bij java een war-bestand), de sleutels mpi_ssl.truststore en mpi.xml.truststore en het configuratie bestand thinmpi.properties.

Voor het integreren van iDEAL advanced hebben wij zelf een scherm ontwikkeld waarop klanten kunnen kiezen voor een internet-betaling. Wij hebben met de commando’s in de handleiding een eigen paar sleutels aangemaakt en het configuratie-bestand gewijzigd. Vervolgens hebben wij functionaliteit ontwikkeld voor het automatisch verwerken van betalingen. Voor etikettenprinten.nl werken wij met credits. Als een betaling is voldaan worden automatisch de credits van de klant verhoogd en de factuur naar de klant en de boekhouding gestuurd. De voorbeeldschermen die meegeleverd worden in het download-bestand waren een goede leidraad voor het ontwikkelen van de eigen functionaliteit.

Het maken van sleutels: De beveiliging voor de betaling is geregeld met de zgn sleutels. Deze techniek is gebaseerd op de cryptografie uit de wiskunde. Sleutels verschijnen in paren. Er zijn steeds 2 verschillende sleutels die bijelkaar horen. Twee partijen kunnen alleen met elkaar praten als zij ieder een unieke sleutel uit hetzelfde paar bezitten. Met zo’n sleutel kunnen ze berichten naar de andere partij versleutelen, d.i. onleesbaar maken voor onbevoegden, en versleutelde berichten van de andere partij ontsleutelen, d.i. weer leesbaar maken. Sleutels zijn codes, bestaande uit cijfers, letters en lettertekens. Eenzelfde sleutel kan niet gebruikt worden voor versleutelen en ontsleutelen.

Bij de integratie van iDEAL advanced zijn 2 paren sleutels betrokken. Het ene paar zit in het download bestand, het zijn de sleutels in de bestanden mpi_ssl.truststore en mpi_xml.truststore. Daarnaast moet een webwinkelier zelf een paar sleutels genereren. De handleiding geeft duidelijk aan met welke commando’s dit paar sleutels gegenereerd kan worden. Hiervoor is wel speciale software nodig. De referentie-gids legt in detail uit in welke communicatie welk paar sleutels wordt gebruikt. Het resultaat zijn 2 bestanden, 1 bestand eindigend op .keystore en 1 bestand eindigend op .cer. Het bestand eindigend op .cer bevat de sleutel die doorgegeven moet worden aan iDEAL. Het bestand eindigend op .keystore wordt verwerkt in de applicatie. Dus 2 sleutels – 1 van ieder paar – worden beheerd door uw bank en de twee overgebleven sleutels – de andere van ieder paar – integreert u met uw applicatie, in dit geval de WAR-file.

Aanpassen van het configuratie-bestand: In de handleiding wordt uitgelegd hoe de velden ingevuld moeten worden. In de handleiding stond niet duidelijk vermeld wat ingevuld moest worden in het veld ideal.thinmpi.certificateAlias=?. Dit moet myprivatekey zijn, de sleutel uit het paar sleutels dat de webwinkelier zelf gegenereerd heeft, en dat niet is toegevoegd aan de testomgeving van iDEAL.

Het packagen van de web-applicatie: de applicatie wordt gepacked in een war-bestand. Wanneer uw applicatie alleen uit een war-bestand – bijvoorbeeld applicatie.war – bestaat, pak dit bestand dan uit met:
# jar -xvf applicatie.war
U ziet nu een directory structuur ontstaan beginnend bij applicatie
U plaatst de volgende bestanden in het war bestand:

• owner.keystore
• mpi_xml.truststore

En u plaatst deze bestanden in de directory applicatie.war/ of in de directory applicatie.war/WEB-INF/classes. Daarna recreeert u de applicatie met het commando:
#jar -cvf applicatie.war applicatie/*
De handleiding was bijzonder onduidelijk over welke bestanden toegevoegd moeten worden. In de praktijk lijken deze 2 bastanden voldoende.

Wanneer uw applicatie een enterprise applicatie is, dwz uw bestand eindigt op ear, bijv. applicatie.ear, dan kunt u het war bestand daaruit extraheren met het commando:
# jar -xvf applicatie.ear
Een van de bestanden eindigt op .war. Voor dit bestand volg de stappen uit het begin van deze paragraaf. Merk op dat de betalingen volledig in het .war bestand wordt geregeld. U hoeft dus niets te wijzigen in uw enterprise-server – bijv JBOSS – en u de betaling op de development server testen en vervolgens de applicatie op een productie server installeren zonder dat u nieuwe sleutels hoeft te genereren of te uploaden.

Testen: Als laatste stap moet de nieuwe toepassing getest worden met test-transacties. Voor een test-transacties doet u achtereenvolgens een betaling van 1, 2, 3 …. 7 euro naar de testomgeving van iDEAL. De iDEAL testomgeving reageert op deze test bedragen, soms met een acceptatie en soms met een weigering. Wanneer deze testen niet correct worden beantwoord dan kan het zijn dat u de verkeerde bedragen overmaakt. In ons geval was niet 1 euro overgemaakt, maar 10 eurocent. En de 2 euro was 20 cent. Het overzicht scherm op het dashboard kunt u controleren welke bedragen zijn binnengekomen.

Helpdesk: Wanneer de installatie niet lukt, dan biedt de helpdesk wellicht uitkomst. De helpdesk is goed bereikbaar en deskundig in het advies. Voor PHP installaties is er een gemeenschap OSEcommerce met heel veel informatie over online betaalsystemen.

Tot slot: Wat zijn uw ervaringen met het integreren van uw webwinkel met iDEAL? Of heeft u vragen over de integratie die we niet beantwoord hebben? Laat het weten met een berichtje!

Sophie Fischer
BV Sponiza !T
www.sponiza.nl
www.etikettenprinten.nl

PDF praktijk installatie iDEAL advanced java