Office: (Office 2010) Access 2010: Benutzernamen auslesen und verwenden

\@SRichter:
http://www.ms-office-forum.net/forum...light=passwort
Das sollte man sich halt mal in Ruhe ansehen und ausprobieren.
Darauf hatte ich in #5 schon mal hingewiesen.

 

Die Datenbank PasswortModul_Hash ist leider sehr amateurhaft.
Typisch für jemanden der ins Programmieren "hineingewachsen" ist, und dem jegliche Grundlagen fehlen.

Ich weiß, dass hört sich nicht gut an. Aber sich der Realität zu verschließen bringt auch nichts.
LG Markus

 

\@markusxy:
Wenn es bei der Kritik um die Effektivität der DB geht, dann bitte Fakten,
welche auch Rückschlüsse auf eine nachvollziehbare Kompetenz des Kritikers aufzeigen.
Es ist ja bekannt, dass jedermann sich online (also auch hier) schon zum Fachmann ernennen kann, indem man einfach andere als unfähig bezeichnet.
Die Beispiel DB funktioniert und kann natürlich von jedem nachträglich an spezielle Situationen angepasst werden.
Erst ab einer faktischen und nachweisbaren Verbesserung nehme ich Dich also ernst.
Dazu kein weiterer Kommentar.

Wenn es um ein "sophisticated programming" bei identischem Ergebnis geht,
dann sehe ich da ganz sicher Optimierungsmöglichkeiten.
Dazu würde aber ganz sicher jeder hier von Dir etwas mehr Kompetentes sehen wollen, als das geschriebene Labern, welches wir ja nun hinreichend
aus Politik, Wirtschaft....etc. kennen. Dort behauptet auch jeder etwas, ohne es jemals wirklich nachweisen zu müssen.

 

\@Ohrkester
Wenn du ernsthaft daran interessiert bist, eröffne einen neuen Thread.
Vorab: Die Usability ist das Problem.
Keine brauchbare Übersicht für den Admin.
Bei Umgebungen mit mehreren hundert Formularen und duzenden Anwendern nicht wartbar, da nicht überschaubar.

Willst du ernsthaft aus 200 Formularen 1000 machen um dein Konzept unterzubringen, mal ganz abgesehen von der 1000 Modul Grenze in Access?

Das Problem ist das Gesamtkonzept.
Schau mal das Berechtigungskonzept von Datenbanken oder Windows an.
Also neuer Thread -> brauchbares Programm, damit auch die Profis Grundsatzvorschläge machen (ich bin ja auch nur ein nebenbei Programmierer)

LG Markus

 

\@markusxy:
Nein, ich bin nicht interessiert, weil es nicht notwendig ist und weil nicht ich der Ersteller der Beispiel DB bin. Das Original gibt es hier:
http://www.arbtersound.de/sonderseit...ielauswahl.htm

Fragen dazu sind an derArb im Forum www.office-loesung.de zu richten.

Ich hatte geschrieben.

Ich verwende diese Beispiel DB in einigen meiner DB-Anwendungen mit leichten Modifizierungen
und finde Folgendes sehr angenehm:
1. Es wurde dabei im Wesentlichen daran gedacht, dass der Admin Passworte und Usernamen zwar löschen und neu vergeben, aber nicht verändern kann, weil sie ihm durch die Verschlüsselung nicht bekannt sein können. Da freut sich doch jeder Datenschutzbeauftragter einer Firma.
2. Der User kann jederzeit seine Zugangsdaten verändern, ohne dass diese irgendjemand auslesen kann.
3. Es wurde an einen Klarnamen gedacht, welcher dem User einmalig vom Admin zugeordnet wird und trotz Usernamen-bzw. PW-Änderung durch den User selbst sich nicht ändern wird.
Das ist ein erfreulicher Aspekt für Zuordnungen und Auswertungen von Daten der jeweiligen nachfolgenden DB-Anwendungen.
4. Es gibt eine Historie über kurzfristige und langfristige illegale Versuche, in die DB zu gelangen.
5. Die monierte Form der Formularaufrufe in nachfolgenden DB-Anwendungen ist eine
durchaus passable Beispielmöglichkeit, wenn man sich vor Augen hält, dass es 5 Userkreise gibt.
Userkreis1 = Write Formulars, Userkreis2 = read Formulars, Userkreis3 = Admin Formulars,Â…etc.
Da gibt es bestimmt auch viele andere Wege nach Rom, welche mir zu grossem Teil bekannt sind.
Wichtig auf all diesen Wegen ist die Ãœbergabe der Klarnamen an ein Formular der nachfolgenden
DB-Anwendung, egal welchen Weg nach Rom man nun benutzen mag.
Dein Zitat:

6. Ich sehe keine „hunderte von Formularen“ in einer Accessanwendung.
Ich sehe pro Usergruppe eine bestimmte Form von Formularen.
Eine Übersicht für den Admin darüber zu erstellen dürfte ja wohl eine der leichtesten Übungen sein.
Sollte aber eine Unterscheidung je User in einem generellem Formular der folgenden DB-Anwendung programmiertechnisch gewünscht sein, dann ist das ein anderer (mit erweiterterten Optionen)
Weg nach Rom, welcher dann im Gegensatz zur Beispiel DB dann sich an die nachfolgende DB-Anwendung anpassen muss und nicht mehr als generelle Beispiel DB dienen kann.
7. Ich erlaube es mir nicht, andere einfach wegen eines "anfechtbaren" Programmierstils zu desavouieren. Das überlasse ich den Profis, welche das aber auch nicht machen. Ich lasse aber auch nicht zu, dass man etwas funktionerendes einfach nur auf Grund eines "amateurhaften" Programmierstils in eine Stümperecke zu stellen versucht.

 

\@Ohrkester,
es geht nicht um Programmierstiel.
Das GrundKonzept ist Schrott.
Nicht die Frage was ist verschlüsselt und welche Fehler hat der User beim Einloggen gemacht. Das sind nette Extras die mit dem Wesentlichen aber nichts zu tun haben.

LG Markus

 

\@markusxy:
siehe#33
Es nützt nichts, dauernd etwas zu behaupten, ohne schlüssige
Beweise und/oder Gründe dafür zu erbringen.

 

Hallo,

die "eifrige" Diskussion (oder eben auch nicht) um das (hier ursprünglich gar nicht nachgefragte) Thema "Passwortschutz" hat mich neugierig gemacht, so dass ich mir die hier verlinkte Beispiel-DB einmal angeschaut habe, um mir meine eigene Meinung zu bilden.

Es steht ja nirgendwo, dass dies als Fertigprodukt angeboten wird, es ist lediglich ein Beispiel für diverse "Machbarkeiten". Also steht es dir frei die dir fehlenden Übersichten hinzuzufügen. Somit ist dies kein akzeptabler Grund für eine Abwertung.

Es ist auch nirgendwo gesagt, dass eine Version/Kopie eines jeden Formulars für jede Benutzergruppe bereitgestellt werden muss.
Das wäre wohl auch ein ziemliches Unding und da würde man doch eher die Sichtbarkeit oder auch Funktionalität gewisser Buttons, Textfelder etc. abhängig vom angemeldeten User innerhalb eines Formulars dynamisch steuern. (oder etwa nicht?!)

Ich vermute, dass du hier einfach zuviel hinein interpretierst, was gar nicht so gemeint ist.

Meine Bedenken gehen eher in die Richtung, dass ich es für wenig praktikabel halte, eine Anwendung für verschiedene Benutzergruppen zu erstellen, wenn es dabei keinen Mehrwert durch gegenseitigen "Nießnutz" gibt. Das heißt, wenn tatsächlich jede Gruppe eine eigene Gruppe von Formularen (und Berichten etc.) benötigt, könnte man das ebensogut in separate Anwendungen aufteilen.

Dafür kannst du aber erstaunlich große Töne spucken... ;-)

 

\@MaggieMay:

Diese Variante ist bis zu einem gewissen Grad an Komplexität ebenfalls sehr sinnvoll. Wahrscheinlich ist die Kombination mehrerer Varianten je nach Anwendungsfall sinnvoll.

Könnte der Nießnutz sein, dass es für einen Admin einfacher zu verwalten ist auch bezgl. Auswertungen von Fehleingaben der Userdaten?
Könnte weiterhin ein Nießnutz sein, dass der Admin dadurch eine saubere Trennung von Formularen bekommt, wodurch er nicht versehentlich Formulare der Aufsichtsratsebene einem Mitglied des Betriebsrat's zuweist?
Also eine zusätzliche Sicherheitsmassnahme? Mir scheint es so jedenfalls.

 

Hallo Ohrkester,

das kann natürlich rein theoretisch nicht ausgeschlossen werden, meiner Erfahrung nach trifft das aber eher nicht zu bzw. ein derartiger Anwendungsfall liegt außerhalb meiner Vorstellungskraft. ;-)