added berechtigungen der user
This commit is contained in:
@@ -41,7 +41,8 @@ werden die neun Tabellen der Modelle erstellt. Um diese dann auch anwenden zu k
|
||||
\noindent\hspace*{10mm}%
|
||||
\$ python3 manage.py migrate
|
||||
\\
|
||||
darauffolgend ebenso in die Kommandozeile eingegeben werden.
|
||||
darauffolgend ebenso in die Kommandozeile eingegeben werden.\\
|
||||
|
||||
|
||||
\textbf{UserModel:}
|
||||
\begin{addmargin}[25pt]{0pt}
|
||||
@@ -49,6 +50,8 @@ Hierbei ist das Authentifizierungssystem von Django mit einem \textit{UserModel}
|
||||
\begin{itemize}
|
||||
\item username, fist\_name, last\_name, email, groups, user\_permissions, is\_staff, is\_active, is\_superuser, last\_login, date\_joined, tags
|
||||
\end{itemize}
|
||||
Das Feld \textit{groups} wird in dieser Arbeit nicht verwendet und deshalb im Folgenden ignoriert.
|
||||
|
||||
In models.py ist der \textit{CustomUser} dafür verantwortlich das neue Feld mit dem \textit{Default-User} zu verknüpfen. Durch das \textit{OneToOneField} (siehe Abbildung 3.2.) wird die Verbindung zum schon bestehenden Modell hergestellt. \textit{OneToOne} bildet eine einzigartige Zuordnung von zwei Objekten, sodass der Rückgabewert nur aus einem Objekt besteht (vgl. [Fou18a]). Das hei"st, dass hier keine Rekursiven, also auf sich selbst verlinkende oder \textit{lazy} Beziehungen möglich sind um Konflikte bei der Authentifizierung zu vermeiden. Dies ist die übliche Vorgehensweise um mit einem Primärschlüssel das Default-Model zu erweitern.
|
||||
\begin{figure}[!h]
|
||||
\centering
|
||||
@@ -67,17 +70,18 @@ Das \textit{PostModel} beschreibt alle Felder die ein Post enthalten kann. Basie
|
||||
\item author, title, text, created\_date, published\_date, tags
|
||||
\end{itemize}
|
||||
Der Autor ist durch einen \textit{ForeignKey} mit dem \textit{UserModel} verbunden. Diese sogenannte \textit{ManyToOne} Verbindung reicht hier aus um einem Post den Autor, also dem eingeloggten User, zuzuweisen. Title ist ein \textit{CharField} und wird mit einer Zeichenbegrenzung festgelegt. Der Text hingegen kann eine beliebige Menge an Zeichen enthalten und wir deshalb als \textit{TextField} deklariert. Erstellungsdatum und Publikation sind beides \textit{DateTimeField}s. Ersteres muss vom Ersteller angegeben werden, Zweiteres kann zunächst offen gelassen werden durch die Zusatzangabe \glqq null=True\grqq. Ein weiteres Feld tags wird hinzugefügt um den Posts unabhängig von den Usern Tags zuordnen zu können.
|
||||
|
||||
\\
|
||||
\end{addmargin}
|
||||
|
||||
|
||||
\textbf{Gesamtmodellierung:}
|
||||
\begin{addmargin}[25pt]{0pt}
|
||||
|
||||
\begin{addmargin}[25pt]{0pt}
|
||||
Die Abbildung 3.3. zeigt die Modellierung der Tabelle \glqq User\grqq\ und \glqq Post\grqq. Au"serdem verdeutlicht es die Erweiterung des User-Modells von Django mit dem in der Applikation angelegtem CustomUser. Die im User vorkommenden booleschen Felder werden im Kapitel Berechtigung der User genauer erörtert.
|
||||
\begin{figure}[!h]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{figures/datamodel}
|
||||
\caption{Forschungsdesign}
|
||||
\includegraphics[width=0.9\textwidth]{figures/datamodel}
|
||||
\caption{Datenmodellierung von User und Post}
|
||||
\hfill
|
||||
\end{figure}
|
||||
\end{addmargin}
|
||||
@@ -90,7 +94,13 @@ Ein Django-Projekt bildet bereits beim Einrichten, \textit{per Default}, eine Ad
|
||||
|
||||
|
||||
\subsection{Berechtigung der User}
|
||||
Welche Berechtigungen gibt es im Prototyp, welche werden vom Active Directory übernommen?
|
||||
Im Allgemeinen verwendet man Berechtigungen um Benutzern Zugang zu bestimmten Resourcen in einem Netzwerk einzuräumen. Au"serdem bestimmt es die Arte des Zugangs, also ob der User die Resourcen nur lesen oder auch verändern oder löschen darf(vgl. [Com18]). Die Rechte werden meist einzelnen Individuen oder einer Gruppe zugeordnet.
|
||||
|
||||
Das gestaffeltes Berechtigungsmanagement ist im Prototyp notwendig um den Umgang mit Informationen so sicher wie möglich zu gestalten und um die Nachhaltigkeit dieser zu bewahren. Des Weiteren soll der Prototyp als Vorlage für die Erweiterung der Hochschulwebsite dienen und daher ist eine ähnliche Verteilung der Zugangsberechtigungen sinnvoll.
|
||||
|
||||
Studenten sollen zunächst Informationen weder einpflegen, noch editieren dürfen. Die einzigen Änderungen die sie vornehmen können sind auf Ihre eigene Datenbank fokussiert. Das Hinzufügen von Tags um die damit verbunden Posts auf dem persönlichen Dashboard zu sehen wird ihnen gewährleistet. Dies soll verhindern, dass Informationen nicht zu leichtfertig geändert oder gelöscht werden.
|
||||
|
||||
Dozenten und Angestellte der Hochschule sind dazu berechtigt, Posts zu erstellen, zu editieren und wieder zu löschen. Zudem können sie, wie Studenten, Tags abonnieren und ebenso das persönliche Dashboard gestalten. Das Einloggen in die Administratoroberfläche kann vorgenommen werden, jedoch sind der Gruppe noch keinerlei Rechte zugewiesen. Möchte man dies ändern, kann man das von Django bereitgestellte Feld \glqq User Permissions\grqq\ im Admin-back-end unter Users, und dem Namen der zu ändernden Person, die gewünschte Berechtigung erteilen.
|
||||
|
||||
|
||||
\section{Funktionen}
|
||||
|
||||
Reference in New Issue
Block a user