12. Desktop: technische achtergronden

Auteur	Marc Jeurissen
Aanmaak	8 sept 2003
Oud BVV nr	2069

12.1. Abstract

Zowel de opbouw als de werking van de desktop omhelst verschillende stadia die in dit document beschreven worden.

12.2. Algemeen

12.2.1. Delphi waarden

desktop-archive-dir: Directory waarin de zip-file terecht komt indien in de meta-informatie van de desktop gekozen wordt voor Archiveer het zipbestand.
desktop-default: Desktop die als omgeving gekozen wordt indien in een opstarturl geen desktop gespecificeerd is.
desktop-install-dir: Directory waarin de ontwikkelomgeving de bestanden plaatst, meer bepaald in de subdirectories phtml, images en xhtml.
desktop-process-dir: Hoofddirectory voor verwerkingen.
desktop-start-file: Locatie van het bestand dat door delphi-start-url wordt aangesproken.
desktop-start-url: Begin van de url waarmee de gebruiker een desktop opgestart.
desktop-web-base-dir: Basis van de locatie van de webomgeving. Omvat subdirectories per desktop.
desktop-web-base-url: Start van de url waarmee intern naar de omgeving van een bepaalde desktop wordt verwezen.
submit-start-url: Intern gevormde url indien de in de meta-informatie opgegeven url van een service, een Brocade roepcode is.

12.2.2. Bestanden

12.2.2.1. Essentiële bestanden

Essentiële bestanden zijn in wezen dezelfde voor elke desktop. Eventuele desktop-afhankelijke aanpassingen worden software-matig, dus niet door de gebruiker, aangebracht. Ze worden dan ook bij elke update van een desktop overschreven.

alert.phtml: opbouw van het verborgen alert-frame
desktop.phtml: oude startfile van een desktop, deze bestaat nog om oude bookmarks te ondersteunen.
celindex.phtml: vervanger van desktop.phtml
icon.html: opbouw van het facultatieve icon-frame
index.phtml: opbouw van de frameset, opbouw van Brocade-sessie, opstart van gekozen service, opstart van authenticatie
menu.phtml: opbouw van het menu-frame
menuH.js: javascript commando's voor horizontaal menu
menuH_system.js: systeem css commando's voor horizontaal menu
menuV.js: javascript commando's voor verticaal menu
menuV_system.js: systeem css commando's voor verticaal menu
services.phtml: startfile van een service
submit.phtml: submitfile van een service met een Brocade roepcode

12.2.2.2. Desktop-afhankelijke bestanden

Desktop-afhankelijke bestanden hebben allemaal met de layout van de desktop te maken. Het betreft css-files, images e.d.

Al deze files zitten in het zipbestand dat via de meta-informatie van een desktop kan gedownload en geupload worden voor die specifieke desktop. Deze bestanden worden niet globaal door de toolcat applicatie desktop overschreven, tenzij de parameter force wordt gebruikt.

alert.css: css file het verborgen alert-frame
icon.css: css file van het facultatieve icon-frame
menu.css: css file van het menu-frame. Omvat een volledig framework met commentaarlijnen voor definities van de verschillende elementen van het menu-frame.
service.css: default css-file voor een service

12.3. Opbouw van de webomgeving

12.3.1. Ontwikkelomgeving

De ontwikkelomgeving plaatst zowel essentiële bestanden als desktop-afhankelijke bestanden in de desktop proces omgeving desktop-install-dir, meer bepaald in de subdirectories phtml, images en xhtml. Bovendien worden desktop.phtml, services.phtml en submit.phtml geplaatst in de hoofddirectory van de webomgeving web-base-dir, evenals in de startdirectory van de desktop webomgeving desktop-web-base-dir.

12.3.2. desktop -webdesktop

Het klikken op de Registreer knop in de meta-informatie van een desktop, start het commando anetsu desktop -webdesktop desktopidentifier mode=safe op. De parameter safe verhindert dat de desktop-afhankelijke bestanden overschreven worden.

Volgende acties worden uitgevoerd:

desktop.phtml, services.phtml, submit.phtml worden gekopiëerd vanuit desktop-install-dir/phtml naar desktop-web-base-dir
er wordt met behulp van de celestial toolcat ook een celindex.html aangemaakt, redirects via bijvoorbeeld rewrite rules komen hier terecht.
indien het om een nieuwe desktop gaat worden de nodige directories in de desktop proces- en webomgeving aangemaakt
alle essentiële bestanden worden van de procesomgeving naar de webomgeving gekopiëerd, met omzetting van de s4 constructies
er wordt een zipfile aangemaakt van alle desktop-afhankelijke bestanden en in de desktop webdirectory desktop-web-base-dir/desktopidentifier geplaatst

12.3.3. desktop -store

Vanuit de meta-informatie van een desktop kan een file geupload en gedownload worden.

Download: geeft altijd het zipbestand van de desktop-afhankelijke bestanden terug vanuit de desktop webdirectory desktop-web-base-dir/desktopidentifier.
Upload: start desktop -store op. Het kan een zipbestand zijn of een gewone file. Hierbij wordt de file eerst gekopiëerd naar desktop-process-dir/desktopidentifier. Vanuit deze directory wordt alles overgezet naar de webomgeving van die desktop en er wordt daar tevens een nieuwe zipfile aangemaakt.

12.4. Opstarten van de desktop

Een desktop wordt opgestart met de url http://hostname/desktop.phtml[?desktop=desktop-identifier[&service=service-identifier]].

Deze worden geredirect naar celindex.phtml die index.phtml op waarin een Brocade sessie aangemaakt wordt via m-login-exe, en de framesets opgebouwd worden.

Een van de frames is de menu-frame, die opgebouwd wordt door menu.phtml. Die spreekt daarvoor de M-routine /desktop/meta/dmesmenu.m aan.

Klikken op een service, of een service rechtstreeks aanspreken via de url http://hostname/services.phtml[?desktop=desktop-identifier[&service=service-identifier][&extra=[loi=loi][~lg=taal][~wks=werkstation]]] komt via services.phtml in index.phtml terecht, waar de M-routine /desktop/meta/dmesserv.m aangesproken wordt.

Deze routine maakt uit of er voor deze service moet geauthenticeerd worden en geeft de controle terug aan index.phtml. Indien geen authenticatie vereist wordt de service-url opgestart, anders wordt de authenticatieprocedure in gang gezet.

12.5. Authenticatie

In de meta-informatie van de desktop kan een authenticatiemechanisme ingevuld worden. Default gebeurt authenticatie via het eindgebruikersbeheer, dit is een e-loi als login of iets dat tot een e-loi kan omgevormd worden (streepjescode,...), en als paswoord het ingevulde eindgebruikerspaswoord of het resultaat van de Formule voor authenticatie zoals ingevuld in het beheer van het eindgebruikerssysteem. Er kan echter ook gekozen worden voor een applicatie-gebonden authenticatie, waarbij de opgegeven M-executable het ingevulde login en paswoord moet checken.

Het opstarten van een service begint met het uitlezen van de cookie hostname_service door de routine index.phtml. De inhoud van deze cookie bestaat uit 2 delen:

de loginnaam
het tijdstip van authenticatie.

Dat tijdstip, of blanco indien de cookie niet bestond, wordt doorgegeven aan de M-routine /desktop/meta/dmesserv.m die aan de hand van de meta-informatie van de service in kwestie, en het eventuele verschil tussen het huidige tijdstip en het tijdstip van authenticatie, beslist of er (opnieuw) moet geauthenticeerd worden.

Indien authenticatie vereist is, geeft index.phtml de controle door aan de M-routine /desktop/authenticatie/dauwauth.m:

Er is een login meegekomen met de url (...&extra=login=login)

Het authenticatiescherm wordt getoond met het login-veld ingevuld

Er is ook een paswoord meegekomen met de url (...&extra=login=login~pw=pw)

Er wordt vanuit gegaan dat dit paswoord md5-geëncodeerd is en dat de authenticatieprocedure van de desktop weet met welke sentinel extra moet geëncodeerd worden. De controle wordt dan ook onmiddellijk doorgegeven aan r4_desktop_authenticate_url (/desktop/authenticatie/iam.phtml), waarbij de sentinel op blanco gezet wordt.

Geen login en geen paswoord meegekomen met de url

Er is op dit werkstation al in Brocade ingelogd (check gebeurt via de inhoud van cookie hostname_userid) en dat geldt voor deze service als authenticatie. Dit kan voor het authenticatiemechanisme via Brocade gebruikersnaam en paswoord, en voor het default authenticatiemechanisme als het Brocade userid hetzelfde is als het enduserid, en als voor de desktop slechts 1 eindgebruikerssysteem is opgegeven.
Is de Brocade inlog geldig dan wordt de cookie hostname_service gezet en de url van de service opgestart, anders wordt alsnog het inlogscherm getoond.

Submit van het inlogformulier voert volgende acties uit:

Er wordt een sentinel berekend (huidige tijd).
Van het ingegeven paswoord wordt een md5 berekend.
Deze md5 wordt geconcateneerd met de sentinel en er wordt opnieuw een md5 berekend.
In het menu-frame wordt met een timeout van 2 sec. de functie checkReload geactiveerd. Deze functie checkt de cookie en herlaadt eventueel het menu-frame om taalveranderingen e.d. door te voeren.
De controle wordt doorgegeven aan r4_desktop_authenticate_url (/desktop/authenticatie/iam.phtml).

Script /desktop/authenticatie/iam.phtml moet username en password checken en doet dit door M-routine r4_m_login_exe (/universe/authentication/usewlog.m op te starten.

Bij een default authenticatiemechanisme checkt deze routine bij de eindgebruikergegegevens. Bij het Brocade authenticatiemechanisme wordt de Brocade gebruikersnaam en paswoord gecheckt maar niet omgevormd tot een e-loi. Dit mechanisme is dus niet bruikbaar voor desktops die eindgebruikersdiensten aanbieden.

Bij een applicatie-gebonden authenticatiemechanisme wordt de opgegeven routine opgestart, deze levert een paswoord af dat met de sentinel md5 geëncodeerd wordt en gecheckt tegen de meegekomen md5. Zat het paswoord al in de url, dan is de sentinel leeg en moet de applicatieroutine alle paswoord checking doen.

Is de inlog niet geldig dan wordt het inlogformulier terug getoond. Is de inlog geldig dan wordt de cookie hostname_service gezet en de url van de service opgestart.

Een service kan een aanvraag doen voor een nieuwe authenticatie. Dit gebeurt met m4_setSessionLoginId. Van zodra er een nieuwe service opgestart wordt waarvoor authenticatie vereist is, detecteert het systeem de aanvraag en wordt de authenticatie procedure terug doorlopen. Eerst wordt dan gecheckt of 1 van de eventueel met de oorspronkelijke url meegekomen paswoorden, geldig is voor de gevraagde login. Dit moet gebeuren via de applicatie-authenticatie routine vermits enkel deze routine weet hoe die paswoorden geencodeerd werden. Als dit geen match oplevert wordt gecheckt tegen andere reeds gebruikte geldige paswoorden. Indien nog geen match wordt het authenticatiescherm terug getoond.