|
Dokumentation Übersicht |
 |
WebAG
Automat 6.2
|
Inhaltsverzeichnis
1. WebAG Automat 6.2 - Was ist neu?
1.1 Cookie-Autorisierung
1.2 Systemmeldungen
1.3 Aufruf von HTML-Triggern in Schablonen
1.4 Neue Version des Webseiteneditors
2.1 Installations-Voraussetzungen
2.2 Upgrade auf Release 6.2 - Installationsanweisung
2.3 WebAG Automat - Neu-Installation
1. WebAG Automat Release 6.2 - Was ist neu?
1.1 Cookie-Autorisierung
Bislang verwendete der WebAG Automat beim Login ein einfaches Basic-Authentication-Verfahren. Dabei öffnete der Browser ein kleines Anmeldefenster zur Eingabe des Benutzernamens und des Passworts. Diese Art der Anmeldung ließ es nicht zu, dass ein eigenes Anmeldefenster gestaltet werden konnte. Das neue Verfahren speichert nach der Anmeldung einen Cookie mit einer zufälligen Zeichenkette, die vom Automat jeweils mit den Anmeldedaten verglichen wird, die er nach der Anmeldung zu diesem Cookie in der Datenbank hinterlegt hat. Mit dieser Technik ergeben sich für die Benutzer und auch für die Webdesigner einige Bedienungsvorteile:
Für die Administration ändern sich einige Details an der Struktur der Autorisierung:
- Die Anmeldemaske kann frei gestaltet werden und auch ohne eigenes Popup-Fenster direkt ins Portal integriert werden, denn es handelt sich um ein einfaches HTML-Formular, statt wie zuvor um ein Browser-internes Login-Fenster
- Die Benutzer können mit der Option "[x] Dauerhaft angemeldet bleiben" optional festlegen, dass die Anmeldung auch nach dem Beenden und dem Neustart des Browser gelten soll. Durch die Windows-Anmeldung beim Start des PCs ist für viele Firmen eine ausreichende Autorisierung des Benutzers bereits geschehen, so dass mit dieser neuen Option morgens beim Start des Intrantes keine weiter Eingabe des Benutzernamens mehr notwendig ist.
- Die Benutzer können sich Abmelden, ohne den Browser beenden zu müssen.
- Die Benutzer können sich einfach ein neues Passwort senden lassen, wenn sie ihr Passwort vergessen haben. Dazu ist nur die Angabe des Benutzernamens nötig. Der Automat generiert ein neues Passwort und sendet es per E-Mail an die E-Mail-Adresse, die in den Benutzerparametern des Benutzers gespeichert ist.
- Die Korrektheit der Anmelde-Eingabedaten und damit das Akzeptieren bzw. Ablehnen der Autorisierung wird weiterhin im Package OWA_CUSTOM abgewickelt. Allerdings wurde die Prüfung des vom Benutzer eingegeben Passworts in das neue Package WEBAG_CUSTOM ausgelagert. Vorteil: Bei der Implementation eines eigenen Passwort-Checks (z.B. mit DBMS_LDAP) muss nur noch in WEBAG_CUSTOM geändert werden und das Standardpackage OWA_CUSTOM bleibt unberührt.
- In OWA_CUSTOM besteht die Function authorize nur noch aus dem Aufruf einer der beiden Varianten "authorize_cookie" oder "authorize_basic". Eine der beiden Varianten ist auskommentiert, so dass die jeweils andere Variante aktiv ist. Bei der Auslieferung ist die neue Variante "authorize_cookie" aktiv. Sie können jedoch auch die alte Basic-Authentication "autorize_basic" aktivieren, wenn Sie z.B. keine Cookies auf Ihren Intranet-Browser akzeptieren möchten:
FUNCTION authorize
RETURN BOOLEAN
IS
BEGIN
--------
-- Please change heere and choose your authentication mode.
-- One of the two authorize-functions should be active.
--------
RETURN authorize_cookie;
-- RETURN authorize_basic;
END; -- authorize
Für das neue Anmeldeverfahren gibt es zwei neue System-Parameter:
- LOGIN_APPLICATION_NAME
Diese Zeichenkette wird über dem neuen Anmeldefenster eingeblendet, damit der Benutzer weiß, für welches System er sich gerade anmeldet. Dort könnte z.B. stehen: "Firma XYZ Intranet".- LOGIN_SUPPORT_EMAIL
Das ist die E-Mail-Adresse, die innerhalb der neuen Login-Masken zur Hilfe angeboten wird, falls ein Benutzer sich nicht anmelden kann, weil er z.B. nicht nur sein Passwort, sondern auch seinen Benutzernamen vergessen hat. Oftmals weicht dieses Aufgabe von den Aufgaben des Webmasters ab, so dass es Sinn macht, für die Benutzerprobleme eine eigene E-Mail-Adresse anzugeben.Programmierer können mit der Function "wt_authorize.get_auth_mode" herausfinden, welche der beiden Anmelde-Systeme (Cookie oder das alte Basic-Au2thentication-Verfahren) verwendet wird. Diese Function gibt einen der folgenden drei Werte zurück:
- 1 = BASIC-Authentication mit OWA_CUSTOM (Konstante wt.db_auth_mode_BASIC)
- 2 = WebAG COOKIE-Authentication (Konstante wt.db_auth_mode_COOKIE)
- NULL = Es liegt keine Anmeldung vor.
1.2 Systemmeldungen
Der Systemadmninistrator findet im Automat-Navigationsbaum unter "System -> Allgemein" die neue Option "Systemmeldungen". Ab diesem Release speichert der Automat wichtige Meldungen und Fehler in der neuen Tabelle WT_SYSLOG. Mit dem neuen Menuepunkt "Systemmeldungen" kann der Administrator diese Meldungen ansehen. Sie werden nach Datum absteigend ausgegeben.
In den globalen Parametern kann der Administrator mit dem Parameter SYSLOG_DAYS angeben, wieviele Tage lang diese Systemmeldungen verwahrt werden sollen. Alle älteren Meldungen löscht der Automat selbstständig. Wenn Sie keinen SYSLOG_DAYS-Parameter anlegen, werden alle Meldungen 10 Jahre lang verwahrt.
Der Umfang der protokollierten Systemmeldungen umfasst in diesem Release alle auftretenden Anwendungs- und Oracle-Fehlermeldungen, alle Logins mit dem neuen Cookie-Autorisierungsverfahren und Hinweise auf Passwortänderungen durch die Benutzer.
1.3 Aufruf von HTML-Triggern in Schablonen
In Schablonen macht es oft Sinn, Teile des HTML-Codes über den Aufruf von HTML-Triggern wie "PAGE_OPEN" einzublenden, denn man braucht den Code dann nicht in jeder Schablone erneut zu pflegen. Bislang wurde dabei die ID des Triggersets und der Name des Triggers angegeben, also z.B.:<AUTOMAT_INCLUDE TYPE="TRIGGER" TRIGGER_SET_ID="ID" TRIGGER_NAME="PAGE_OPEN" />
Die Angabe der Triggerset-ID ist jedoch oft unpraktisch, denn bei der Übernahme des Schablonen-Designs von der Entwicklungs- in die Produktionsumgebung wird beim Anlegen des Triggersets i.d.R. eine neue ID vergeben, so dass die ID-Angabe im AUTOMAT_INCLUDE-Element angepasst werden muss. Daher kann ab jetzt statt der ID auch der Name des Triggersets angegeben werden, also z.B.:
<AUTOMAT_INCLUDE TYPE="TRIGGER" TRIGGER_SET_NAME="WebAG Triggerset" TRIGGER_NAME="PAGE_OPEN" />
1.4 Neue Version des Webseiteneditors
Mit dem Automat wird die neueste Version des integrierten Webseiten-Editors ausgeliefert. Neben internen Verbesserungen bringt der neue Editor für Autoren Erleichterungen beim Bearbeiten von Tabellen: Die Spaltenbreiten können nun mit der Maus verschoben werden, indem mit gedrückter Maustaste die Spaltenränder angeklickt und verschoben werden.2. Installation
2.1 Installations-Voraussetzungen
Server
- Datenbank:
- Oracle RDBMS ab 9.2
- Webserver:
- Oracle 9i Application Server mit Apache Webserver oder
- Oracle RDBMS ab 9.2 mit integriertem Apache WebserverAutoren-Arbeitsplatz
- Firefox ab Version 2.0, MS Internet Explorer ab Version 6.0 oder Opera ab 7.0
- Javascript aktiviert
2.2 Upgrade auf Release 6.2 - Installationsanweisung
1. Benutzer abmelden
Dazu wird am besten der Webserver für die Dauer der Installation heruntergefahren.2. Backup
3. Software installieren
Sichern Sie vor dem Upgrade Ihre Automat-Datenbank und die Automat-Webserverzeichnisse. Während der Migration des alten Datenmodells in das neue Automat 6.0 Datenmodell werden einige neue Tabellen angelegt und andere Tabellen geändert.
Klicken Sie doppelt die Kommandodatei upgrade.bat auf der obersten Ebene der CD an. Dieses Skript startet das Oracle-Tool SQL*Plus. Sie beantworten die Fragen nach dem Connect an Ihr Automat-Schema. Danach werden automatisch die entsprechenden SQL-Skripte gestartet. Prüfen Sie im Anschluß die Logfiles im Verzeichnis C:\Temp.
Vor der eigentlichen Installation prüft die Upgrade-Prozedur, ob das Automat-Schema alle nötigen Rechte besitzt. Falls dabei Fehler festgestellt werden, erhalten Sie als Ausgabe zu jeder Fehlermeldung die nötigen SQL-Befehle zur Korrektur des Automat-Schemas. Die Korrektur-Befehle sollten Sie in einem neuen SQL*Plus-Fenster ausführen. Danach müssen Sie das Upgrade-Fenster schließen und das Skript upgrade.bat nochmal starten.
4. Automat Online-Hilfe aktualisieren
Die Online-Hilfedateien müssen durch die neuen Versionen im Verzeichnis \doc auf der Installations-CD ersetzt werden. Die URL des virtuellen Webserver-Pfades zu den Hilfedateien finden Sie in den globalen Einstellungsparametern "HELPFILE_DIR". Kopieren Sie alle Dateien und Unterverzeichnisse des CD-Verzeichnisses \doc dorthin.5. Automat-Grafiken kopieren
Kopieren Sie die Grafiken des WebAG Automat von der Installations-CD aus dem Verzeichnis "automat\webserver\html\wt_img" in Ihr Webserververzeichnis "/wt_img". Die bestehenden Dateien in diesem Verzeichnis können überschrieben werden.6. Editor-Javascripte kopieren
Kopieren Sie das Verzeichnis "\automat\webserver\html\automat\fckeditor" mit allen Unterverzeichnisse in Ihr Webserververzeichnis "/automat". In diesen Verzeichnissen befinden sich alle Javascript-Komponenten des neuen WYSIWYG-Webseiteneditors.7. Webserver starten
Nun können Sie den Apache Webserver wieder hochfahren.8. Workflow Hintergrund-Job kontrollieren und ggfs. neu starten
Die Automat Workfowsteuerung benötigt einen Oracle-Hintergrundjob. Dieser Job sorgt dafür, dass Dateien, die in die Datenbank geladen werden, in der Suchmaschine indiziert werden. Prüfen Sie, ob der Job korrekt läuft und legen Sie den Job ggfs. neu an, indem Sie im Automat-Baum die Maske "System / Allgemein / Hintergrund-Jobs" ausfrufen. Als Intervall:für den Job schlagen wir 5 Minuten vor.2.3 WebAG Automat - Neu-Installation
Die Installation eines neuen WebAG Automat-Systems wird ausführlich im Installationshandbuch beschrieben.
WebAG Automat Dokumentation
Copyright © Enterprise Web AG.
Alle Rechte vorbehalten.