12. Desktop: technische achtergronden
Auteur |
|
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
enxhtml
.- 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 vanuitdesktop-install-dir/phtml
naardesktop-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
constructieser 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 naardesktop-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.