Glengamoi (Forum) · AspHeute · .NET Heute (RSS-Suche) · AspxFiles (Wiki) · .NET Blogs

Erstellung eines Intranets in ASP - Grundlagen

Geschrieben von: Alexander Zeitler
Kategorie: ASPIntranet.de

This printed page brought to you by AlphaSierraPapa

Herzlich willkommen zum ersten Teil einer mehrteiligen Artikelserie zur Erstellung eines Intranets in ASP am Beispiel von ASPIntranet. In diesem Teil werden wir auf die Anforderungen und Grundlagen unseres Intranets eingehen. Außerdem werden wir unseren Server konfigurieren, die Tabellenstruktur erarbeiten und einige grundlegende Prozeduren und Funktionen erstellen.

Die zur Installation und Verwendung von ASPIntranet notwendigen Systemvorraussetzungen finden Sie hier. Alle in den Artikeln erwähnten Dateien zum Download finden Sie am Ende des jeweiligen Artikels.

Grundlagen und Anforderungen an das Intranet

Definieren wir zunächst unsere Wünsche an das Intranet:

Das Intranet soll leicht bedienbar sein. Hieraus ergibt sich, daß es sinnvoll ist, das Intranet vom Look’n’Feel an die Produkte von Microsoft Office anzupassen. Es soll weiterhin möglich sein, zwischen den Anwendungen ohne großen Aufwand zu wechseln und ohne Daten manuell (zwischen-)speichern zu müssen. Außerdem soll die Anmeldung über das Netzwerk funktionieren, das heißt der Benutzer soll sich nicht am Intranet anmelden müssen.
Das Intranet soll leicht erweiterbar sein, das heißt neue Seiten müssen sich leicht in die Menüstruktur integrieren lassen. Auch hier stand ein Office-Produkt von Microsoft „Pate“: Microsoft Outlook
Es sollen individuelle Berechtigungen für verschiedene Benutzer existieren, um zu gewährleisten, daß jeder Benutzer nur die Daten „sieht“, die für ihn bestimmt sind.
Jede Anwendung bzw. Seite soll die Möglichkeit zum Ausdruck bieten.
Die Navigation innerhalb des Intranets soll unabhängig von den vom Browser zur Verfügung gestellten Navigationsmöglichkeiten funktionieren.

Das Ergebnis unserer Überlegungen führt zu folgendem „Ergebnis“:

Lassen Sie uns nun daran gehen, unsere Ideen in die Tat umzusetzen.

Anlegen der Verzeichnisstruktur

Zunächst benötigen wir die unten dargestellte Verzeichnisstruktur. Diese beinhaltet folgende Verzeichnisse:

myaspintranet.: das Hauptverzeichnis für das Intranet innerhalb Ihres Root-Verzeichnisses des Webservers
~db: Datenbank
~include: Include-Dateien für häufig benötigte Funktionen
~olmenu: Daten für das im vorigen Screenshot dargestellte Grundgerüst
~setup: Daten für das Setup von ASPIntranet

Einrichten des Hostheaders

Um das Intranet für jeden Mitarbeiter schnell und einfach zugänglich zu machen, richten wir für unser Intranet einen Hostheader ein. Die Theorie und weitere Vorgehensweisen zur Einrichtung eines Hostheaders finden Sie hier.

Für unsere Zwecke genügt eine Kurzanleitung in Form einiger Screenshots: Zunächst legen wir im DNS-Manager einen neuen Host an....

In unserem Fall nennen wir ihn “aspintranet”. Die IP-Adresse ist identisch mit der des Webservers.

Danach erscheint unser neuer Eintrag in der Liste:

Im Internetdienste-Manager erstellen wir eine neue Website mit dem Namen “aspintranet”:

Dieser ordnen wir den Hostheader und die IP Adresse zu, die wir vorher im DNS eingetragen haben:

Das zugeordnete Verzeichnis ist das Verzeichnis "myaspintranet", das wir am Anfang erstellt haben.

Nachdem wir den "Assistent für neue Website" erfolgreich beendet haben, können wir nun die Windows-Authentifizierung des IIS aktivieren.

Aktivierung der Windows-Authentifizierung

Im noch geöffneten "Internetdienste-Manager" aktivieren wir nun im Menüpunkt "Verzeichnissicherheit" die Windows-Authentifizierung. Diese ermöglicht uns später das Auslesen des Windows-Benutzernamens.

Tiefergehende Informationen zum Thema "Verzeichnissicherheit mit NTFS und IIS Authentifizierung" finden Sie hier.

Datenbankdesign

Jetzt, da wir unseren Server vorbereitet haben, können wir uns der Einrichtung unserer Datenbank für das Intranet widmen. Wie bereits erwähnt, speichern wir unsere Datenbank mit dem Namen "aspintranet.mdb" in dem Unterverzeichnis "~db".

Doch welche Tabellen benötigen wir überhaupt?

Zunächst wäre hier eine Tabelle organisatorischer Art: Betriebsdaten - hier befinden sich Informationen zu Ihrem Unternehmen, die häufig benötigt werden, z.B. für Arbeitsverträge o.ä.

Eng verknüpft in diesem Zusammenhang sind die Tabellen für weitergehende betriebsinterne Informationen, wie Telefonnummern, Abteilungen etc.

Tabelle Abteilungen

Tabelle EmailAdressen

Tabelle FaxNummern

Tabelle MobilNummern

Tabelle NetzwerkUser

Tabelle TelefonNummern

Was natürlich nicht fehlen darf, sind die Mitarbeiter Ihres Unternehmens. Auch für sie legen wir eine Tabelle an:

Weiterhin gibt es die Tabellen "Abteilungsleiter" (zur Definition der Abteilungsleiter Ihres Unternehmens) und "Feiertage" (für Kalender/Urlaubsplaner ö.ä.).

Tabelle Abteilungsleiter

Theorie und weiteres Datenbankdesign

Wie in der ersten Grafik des Artikels zu sehen ist, besitzt das Intranet ein an das Look’n Feel von Microsoft Outlook angepasstes Menü. Dieses erlaubt die Definition von Rechten für jeden einzelnen Anwender des Intranets. Hieraus ergibt sich die Notwendigkeit für zwei weitere Tabellen in unserer Datenbank:

Die erste Tabelle ist die Tabelle "OLMenue": in ihr werden die Einträge des Menüs gespeichert. Hierbei stellen Einträge mit dem Wert "0" im Feld "IstUntermenuevon" die verschiedenen Menügruppen dar. Die Anwendungen der jeweiligen Gruppen enthalten dann in "IstUntermenuevon" die "ID" der übergeordneten Gruppe.

Bei der zweiten Tabellen handelt es sich um die Tabelle "OLMenueRechte". Wie der Name bereits verrät, werden hier die Rechte der Benutzer für die in der Tabelle "OLMenue" gespeicherten Menüpunkte hinterlegt.

Um den Zusammenhang zwischen den Tabellen "NetzwerkUser", "OLMenue" und "OLMenueRechte" zu verdeutlichen, sehen Sie nachfolgend die Beziehungen für die drei Tabellen:

Das Problem, das nun besteht, ist daß zum Zeitpunkt der "Installation" unseres Intranets noch keine Benutzer angelegt sind, die Zugriff auf das Intranet haben. Einzig der Benutzer "Administrator" ist (bzw. sollte) bei einem funktionierendem Windows-2000 (oder NT 4.0)-Server bereits vorhanden.

Deshalb steht dieser bereits in den Tabellen "NetzwerkUser" bzw. "Administratoren". Weiterhin sind die Felder "IstLoeschbar" und "IstAenderbar" für diesen Benutzer in beiden Tabellen auf false gesetzt. So wird vermieden, daß in der in einem späteren Teil besprochenen Benutzer- bzw. Mitarbeiterverwaltung der Administrator gelöscht werden kann.

Tabelle NetzwerkUser mit dem bereits angelegten Benutzer "Administrator"

Tabelle Administratoren mit dem zugewiesenen Standard-Administrator

Um nun zu gewährleisten, daß man nicht ständig als Administrator angemeldet sein muß, erstellen wir uns eine Routine (Setup), die es dem Administrator ermöglicht, einen Benutzer anzulegen, der berechtigt ist, weitere Benutzer und Mitarbeiter anzulegen. Außerdem legt der Administrator die grundlegenden Betriebsdaten für Ihr Unternehmen an - auch dies passiert Setup-gesteuert.

Die Grundlage für das Anlegen weiterer Mitarbeiter durch einen Nicht-Administrator bildet die Tatsache, daß eben dieser Benutzer Zugriff auf den Bereich "Mitarbeiter" in der Gruppe "Verwaltung" erhält. Deshalb sind für diese beiden Menüpunkte in der Tabelle "OLMenue" bereits Einträge vorhanden - auch diese sind nicht löschbar:

Das Setup muß nun also nur noch dafür sorgen, daß der neue Mitarbeiter bzw. NetzwerkUser in der Tabelle "OLMenue_Rechte" für diese beiden Einträge gespeichert wird. Doch dazu kommen wir später - zunächst müssen wir wissen, ob das Setup bereits ausgeführt wurde.

Sie ahnen es bereits: auch hierfür gibt es eine Tabelle. Diese mit einem Feld zugegebenermaßen kleinen Tabelle beinhaltet ein Ja/Nein-Feld namens "SetupIsOK", welches im True-Zustand anzeigt, daß das Setup erfolgreich durchgeführt wurde:

Die Überprüfung, ob dieses Feld „true“ beinhaltet, stellt neben der Verbindung zur Datenbank sowie dem Abschalten des Cachings die ersten programmiertechnischen Handlungen an unserem Intranet dar.

Grundlegende Programmierung

Beginnen wir mit dem Abschalten des Cachings. Dieses wird in jeder Seite benötigt, weshalb es sich empfiehlt, diesen Vorgang in einer Subroutine auszulagern. Da wir im weiteren Verlauf der Entwicklung unseres Intranets erwartungsgemäß sehr viele Funktionen und Subs erstellen werden, empfiehlt es sich, die Routinen und deren Aufruf in getrennte Dateien zu verpacken. Somit ergeben sich zwei Dateien functions.asp (für die Funktionen und Subs) und callfunctions.asp (für den Aufruf von Funktionen und Subs, die in jeder Seite benötigt werden), welche sich in dem Unterverzeichnis /~include befinden.

Das Abschalten des Cachings befindet sich in der Sub DisableCaching, welche wie folgt aussieht:

Sub DisableCaching
  Response.Expires=0
  Response.AddHeader "Pragma","no-cache"
  Response.AddHeader "cache-control", "no-store"
End Sub

Eine weitere, in jeder Seite benötigte "Anwendung" ist der Zugriff auf die Datenbank, welche sich in der Sub MakeDBConn befindet:

Sub MakeDBConn
  Dim StrConn
  Set Conn = Server.CreateObject("ADODB.Connection")
  strConn = "Driver={Microsoft Access Driver (*.mdb)};DriverID=25;DBQ="
  strConn = strConn & Server.MapPath("/~db/aspintranet.mdb")
  strConn = strConn & ";FIL=MS Access;MaxBufferSize=512;PageTimeout=5;"
  Conn.Open strConn
End Sub

Als nächste Aufgabe steht die Überprüfung des Setups an. Da wir hier eine Rückmeldung benötigen, verwenden wir eine Funktion namens Check_Setup:

Function Check_Setup
  Dim StrSQL
  Dim rs
  strSQL = "SELECT SetupIsOK FROM Setup"
  Set rs = Conn.Execute(strSQL)
  If rs.Eof Then 
    Check_Setup = False
  ElseIf rs("SetupIsOK") = False Then
    Check_Setup = False
  Else
    Check_Setup = True
  End If
  rs.Close
  Set rs = Nothing
End Function

Zunächst wird überprüft, ob ein Eintrag für den Status des Setups in der Tabelle vorhanden ist. Ist dies nicht der Fall, wird False zurückgeliefert. Selbiges gilt für den Fall, daß der Wert von "SetupIsOK" False ist, also das Setup noch nicht ausgeführt wurde. Wurde das Setup korrekt ausgeführt, so steht in „SetupIsOK“ der Wert True, welchen die Funktion dann zurückliefert.

Bevor wir einem Benutzer Zugang zu unserem Intranet gewähren, müssen wir feststellen, mit welchem Benutzernamen dieser am Rechner (bzw. Netzwerk) angemeldet ist. Unsere Funktion hierfür trägt den Namen Check_User.

Die Grundlagen, um unser Vorhaben zu realisieren, haben wir mit der Aktivierung der Windows-Authentifizierung geschaffen. Um diese vom Server zur Verfügung gestellten Informationen auslesen zu können, bedienen wir uns der Servervariable "LOGON_USER".

StrUserName = Request.ServerVariables("LOGON_USER")

Da uns diese allerdings den UNC-Namen des Users liefert, müssen wir den "Serveranteil" noch aus dem String “eliminieren”. Hierzu verwenden wir den Befehl Split:

ArrUser = Split(StrUserName, "\", -1, 1)
StrLogged_In_User = ArrUser(1)

In der Variable „StrLogged_In_User“ befindet sich nun der Benutzername des am Intranet anzumeldenden Benutzers.

Da wir nun wissen, wer aktuell eingeloggt ist, müssen wir feststellen, ob dieser User überhaupt Zugriff auf das Intranet haben soll, was bedeuten würde, daß zumindest ein Eintrag für diesen Benutzer in der Tabelle "NetzwerkUser" vorhanden ist:

StrSQL = "SELECT ID FROM NetzwerkUser WHERE NetzwerkUser = '" & StrLogged_In_User & "'"
Set rs = Conn.Execute(StrSQL)
If rs.Eof Then
    Check_User = False
Else
    Session("Logged_In_User_ID") = rs("ID")
    Check_User = True
End If
rs.Close
Set rs = Nothing

Ist für den aktuellen eingeloggten Netzwerkuser kein Eintrag vorhanden (= rs.Eof), liefert unsere Funktion „False“ zurück, andernfalls wird in der Sessionvariable "Logged_In_User_ID" die ID des Netzwerkusers aus der Tabelle "NetzwerkUser" gespeichert. Außerdem liefert die Funktion Check_User den Wert True zurück.

Doch was nützen die besten Funktionen, wenn diese nicht aufgerufen werden? Diesen Mißstand werden wir jetzt beseitigen, indem wir uns unserer ersten Seite im Intranet widmen, der Datei default.asp im Hauptverzeichnis (myaspintranet).

Der erste Befehl dieser Seite ist die Anweisung Option Explicit, welche eine explizite Deklaration aller Variablen in einem Skript mittels Dim, Private, Public oder ReDim erzwingt. Die Verwendung dieser Anweisung erleichtert uns später die Fehlersuche, wenn wir z.B. Schreibfehlern bei Variablen o.ä. auf die Spur kommen wollen.

Danach inkludieren wir unsere bisher erstellten Subs und Funktionen:

<!--#include virtual="/~include/functions.asp"-->

Direkt im Anschluß folgt der Aufruf der Subroutine "DisableCaching".

Nachdem wir dann unsere Verbindung mit dem Namen Conn deklariert haben, rufen wir die Subroutine MakeDBConn auf. Die Deklaration mittels Dim Conn außerhalb der Subroutine ist notwendig, um die Verbindung zur Datenbank innerhalb des kompletten Scripts default.asp zur Verfügung zu stellen.

Der Aufruf der Funktion Check_Setup ist der nächste Schritt in unserem Script:

If Check_Setup = False Then 
    Response.Redirect("/~include/error.asp?Error=1")
    Response.End
End If

Wir überprüfen das Ergebnis unserer Funktion - ist dieses False, so leiten wir den User auf eine Seite error.asp. An diese übergeben wir die Fehlernummer "1". Doch dazu später mehr.

Sollte das Ergebnis der Prüfung von "Check_Setup" True lauten, wenden wir uns der Überprüfung unserer Funktion "Check_User" zu:

If Check_User = False Then 
    Response.Redirect("/~include/error.asp?Error=2")
    Response.End
End If

Auch hier leiten wir im Fehlerfalle (entspricht False) zu der Datei error.asp mit Angabe einer Fehlernummer weiter.

War auch diese Prüfung positiv (also True), so wird der Rest des Scripts ausgeführt, welcher zunächst aus der Tabelle "Betriebsdaten" den Firmennamen ausliest und diesen als Titel des generierten Framesets anzeigt. Näher befassen wir uns mit der Datei default.asp im Moment nicht.

Fehlerbehandlung

Bei der Überprüfung der Funktionen "Check_Setup" und "Check_User" haben wir im Fehlerfall auf eine Datei namens error.asp weitergeleitet - diese wollen wir nun näher betrachten.

Hintergrund der Datei error.asp ist, daß im laufenden Betriebs des Intranets immer wieder Fehlerzustände auftreten können, die es erfordern, den Betrieb des Intranets bis auf weiteres komplett zu unterbinden. Zwei dieser Zustände haben wir bereits kennengelernt: das Setup wurde nicht ausgeführt oder der aktuell angemeldete User ist nicht berechtigt, das Intranet zu nutzen. Um den User über den Fehler ohne kryptische Fehlermeldungen zu informieren, integrieren wir deshalb die Seite „error.asp“. Diese gibt je nach (abfangbarem) Fehler eine verständliche Fehlermeldung und eine oder mehrere Lösungsmöglichkeiten aus.

Aus dem theoretischen Aufbau der Seite ergibt sich, daß wir auch hierfür eine Tabelle in unserer Datenbank anlegen - die Tabelle "Errors":

In der Datei error.asp erzwingen wir zunächst - wie in allen anderen Seiten des Intranets, die wir noch behandeln werden - mittels Option Explicit die Deklaration von Variablen. Nach der Deklaration derselben lesen wir aus dem QueryString die ErrorID. Dies ist die Nummer, die wir in der Datei default.asp übergeben haben. Wir überprüfen dann, ob diese Fehlernummer in der Tabelle "Errors" vorhanden ist. Ist dies der Fall, so wird der entsprechende Fehler angezeigt. Sollte die Fehlernummer nicht in der Tabelle existieren, so hat der Benutzer die Fehlernummer von Hand manipuliert, oder die Datenbank ist beschädigt - beides ist ein Grund, um den Administrator des Intranets zu verständigen, was dem Benutzer auch mitgeteilt wird:

ErrorID = Request.QueryString("Error")
If (ErrorID <> "") AND (IsNumeric(ErrorID) = True) Then
    Dim Conn
    MakeDBConn
    StrSQL = "SELECT * FROM Errors WHERE ID = " & ErrorID & ""
    Set rs = Conn.Execute(StrSQL)
    If Not rs.Eof Then
        Response.Write rs("Ueberschrift") & "<br><br>"
        Response.Write "Fehler:&nbsp;" & rs("Fehler") & "<br><br>"
        Response.Write "Lösung:&nbsp;" & rs("Loesung")
    Else
        Response.Write "Schwerwiegender Fehler - verständigen Sie den Administrator"
    End If
Else
    Response.Write "Schwerwiegender Fehler - verständigen Sie den Administrator"
End If

Sicher fragen Sie sich, weshalb außer der Überprüfung, ob die via Querystring übergebene Error-ID leer ist, auch eine Prüfung mittels IsNumeric (ist die Error-ID eine Zahl?) durchgeführt wird. Der Grund dafür lässt sich wohl am einfachsten mit einem Beispiel zeigen. Angenommen der Benutzer würde die URL wie folgt ändern:

http://myaspintranet/~include/error.asp?Error=1 OR 1=1

Das Ergebnis wäre eine veränderte SQL-Abfrage, welche nun wie folgt lauten würde:

SELECT * FROM Errors WHERE ID = 1 OR 1=1

Hierdurch wäre es möglich, alle Daten der Tabelle aufzulisten - eine Sicherheitslücke, die wir unbedingt vermeiden wollen.

Schlußbemerkung

Nachdem wir nun die ersten theoretischen und auch praktischen Grundlagen für unser Intranet geschaffen haben, beenden wir hiermit den ersten Artikel zur Erstellung eines Intranets mit ASP. Gleichzeitig lade ich Sie zum zweiten Teil der Artikelserie ein, welcher morgen veröffentlicht wird. Dort beschäftigen wir uns unter anderem mit der Programmierung des Setups und dem Aufbau des "Outlook-Menüs".

Redaktioneller Hinweis

Aufgrund des Umfanges des Intranets - und der damit möglichen Fehlerquellen bei der Umsetzung auf den unterschiedlichen Serverkonfigurationen der Leser - bittet der Autor, die Anfragen über öffentliche Foren (so zum Beispiel aspGerman) oder die ASPIntranet Mailingliste abzuwickeln. Fehler in ASPIntranet können Sie auf der Bugreport-Seite von ASPIntranet melden.