Januar 24, 2021, 22:57:22

Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!


Zugriff auf Form erlauben, aber auf die zugehörige Tabelle sperren

Begonnen von mradlmaier, Mai 18, 2010, 14:55:37

⏪ vorheriges - nächstes ⏩

mradlmaier

Ist es möglich mittels der Benutzerverwaltung den direkten Zugriff auf ein Tabelle zu unterbinden, und den Zugriff über ein gebundenes Formular zu erlauben?

Soweit ich das jetzt ausprobiert habe, kann man mittels Benutzerverwaltung entweder nur den Zugriff auf Tabelle und Formular erlauben oder aber für beide Tabelle und Formular sperren. Was ich ziemlich beknackt finde...

Dann würde nur noch als Alternative .mde Dateien übrig bleiben, und damit wäre dann Zugriff auf Tabellen generell unterbunden. Dann müsste man zu administrativen Zwecken regelmäßig die Daten in eine andere DB importieren, was auch nicht praktisch wäre...

Danke

DF6GL

Hallo,


a) nein.    Allenfalls könnte man die Anzeige des DB-Fensters unterdrücken.   

b) MDE: ist keine Alternative, auch dort ist der Zugriff auf Tabellen nicht unterbunden, lediglich Code und (Form/Berichts-) Entwurfsansichten sind nicht einsehbar, bzw. aufrufbar.

Vom Datendank-Kennwort spreche ich jetzt mal nicht, weil das auch keine "sichere" Methodik ist.

mradlmaier

Dass wären so erhebliche Drawbacks, dass MS Access für wirklich professionelle Anwendungen kaum brauchbar ist. Schade, die Formulare als GUI wären schick und schnell zu entwicklen...

Zitat von: DF6GL am Mai 18, 2010, 15:40:31
Hallo,


a) nein.    Allenfalls könnte man die Anzeige des DB-Fensters unterdrücken.   

b) MDE: ist keine Alternative, auch dort ist der Zugriff auf Tabellen nicht unterbunden, lediglich Code und (Form/Berichts-) Entwurfsansichten sind nicht einsehbar, bzw. aufrufbar.

Vom Datendank-Kennwort spreche ich jetzt mal nicht, weil das auch keine "sichere" Methodik ist.

Josef

Hallo!

ZitatDass wären so erhebliche Drawbacks, dass MS Access für wirklich professionelle Anwendungen kaum brauchbar ist. Schade, die Formulare als GUI wären schick und schnell zu entwicklen...

Und genau das ist auch die Stärke von Access. :)

Du kannst aber Access auch mit aktiven DBMS verbinden und deren Sicherheitssystem nutzen.
Wenn du dann z. B. das Formular an ein Recordset bindest (egal ob DAO oder ADODB) und nur dieses Recordset mit den erforderlichen Zugangsberechtigungen öffnest, ist zumindest ein direkter Zugriff auf die Tabellen unterbunden.

Wenn du allerdings die DB nicht entsprechend absicherst, ist dieser Schutz sinnlos. Das gilt auch, wenn du eine Anwendung mit C++, C# & Co. erstellst. Sobald das Backend offen ist, ist jeder Schutz im Frontend sinnlos.

Für sicherheitskritische Anwendungen würde ich auf jeden Fall nur ein aktives DBMS mit entsprechenden Sicherheitsmechanismen verwenden - das Frontend ist genau genommen egal.

mfg
Josef

mradlmaier

Den Code zur Bindung an MS Access Formulare muss ich dann allerdings sebst schreiben, oder? Damit wären die Access Formulare nicht viel mehr als ein Windows Toolkit?

Zitat von: Josef am Mai 18, 2010, 15:57:04
Hallo!

ZitatDass wären so erhebliche Drawbacks, dass MS Access für wirklich professionelle Anwendungen kaum brauchbar ist. Schade, die Formulare als GUI wären schick und schnell zu entwicklen...

Und genau das ist auch die Stärke von Access. :)

Du kannst aber Access auch mit aktiven DBMS verbinden und deren Sicherheitssystem nutzen.
Wenn du dann z. B. das Formular an ein Recordset bindest (egal ob DAO oder ADODB) und nur dieses Recordset mit den erforderlichen Zugangsberechtigungen öffnest, ist zumindest ein direkter Zugriff auf die Tabellen unterbunden.

Wenn du allerdings die DB nicht entsprechend absicherst, ist dieser Schutz sinnlos. Das gilt auch, wenn du eine Anwendung mit C++, C# & Co. erstellst. Sobald das Backend offen ist, ist jeder Schutz im Frontend sinnlos.

Für sicherheitskritische Anwendungen würde ich auf jeden Fall nur ein aktives DBMS mit entsprechenden Sicherheitsmechanismen verwenden - das Frontend ist genau genommen egal.

mfg
Josef

Josef

ZitatDen Code zur Bindung an MS Access Formulare muss ich dann allerdings sebst schreiben, oder?


Ja.
Das wäre einmalig eine Funktion, die das Öffnen eines ADODB-Recordsets kapselt.
Und diese Funktion du dann in jedem Formular verwenden, wo du so einen Zugang nutzen möchtest.
Im Formular sieht das bei mir z. B. so aus:
private sub Form_load()
   set me.recordset = openAdoRecordset("select ... ", .... )
end sub


Die Textfelder usw. kannst du so nutzen, als würdest du eine Tabelle oder gespeicherte Abfrage als Datenquelle verwenden.
Deren Datenbindung übernimmt auch in diesem Fall Access.

Oder du verwendest in den Formularen eine spezielle Benutzerkennung aus deiner Access-Benutzerverwaltung:
Prinzip:
Dim ws As dao.Workspace
dim db as dao.Database
Set ws = DBEngine.CreateWorkspace("sichererWorkSpace", "Username", "Passwort")
set db = ws.OpenDatabase(....)
set me.Recordset = db.Openrecordset("select ...")

Anm.: dass man bei Wiederholter Verwendung von CreateWorkspace das ganze natürlich in eine Hilfsprozedur verlegt, ist sowieso klar. ;)

Aber: falls du eine Sicherheitskritische Anwendung erstellen willst, dann vergiss das Access-Sicherheitskonzept gleich wieder. Das ist ruck-zuck geknackt.


Falls du ein aktives DBMS verwendest, hättest du auch noch die Möglichkeit die Verbindungsdaten direkt in die Datenquelle das Formulars einzuarbeiten.
select ... form [ODBC;...].Tabelle
Dann würde es keine verknüpften Tabellen geben und somit hätte der Anwender auch keine Möglichkeit über die Tabellen die Daten zu ändern.

Apropos Anwender: für den Otto-Normalverbraucher kannst du eine Access-Anwendung auch so gestalten, dass das Datenbankfenster bzw. ab A07 die Navigationsleiste nicht sichtbar sind. Das ist aber nur ein Schein-Schutz. Wenn du die Daten vor mutwilliger Manipulation schützen willst, musst du meiner Ansicht nach im Backend dafür sorgen, dass nichts ohne Prüfung rein kommen kann. Dafür eignen sich z. B. gespeicherte Prozeduren oder auch Trigger.
Jeder Versuch so etwas nur über das Frontend abzusichern, ist meiner Meinung nach kein Schutz vor mutwilliger Manipulation.

mfg
Josef


Josef

Nachtrag:

Eine Variante mit dem Access-Sicherheitssystem fällt mir noch ein.
select ... from Tabelle WITH OWNERACCESS OPTION
Ich weiß allerdings nicht, ob das auch funktioniert, wenn man nur die SQL-Anweisung als Datenquelle fürs Formular einstellt.
Da aber im Hintergrund auch bei dieser Variante eine Abfrage (bei der ersten Verwendung) erstellt wird, könnte ich mir vorstellen, dass es trotzdem funktionieren könnte. Die Frage ist nur, wer dann der Eigentümer dieser im Hintergrund erstellten Abfrage ist.
Vielleicht kann das jemand bestätigen oder vereinen, der ein geschütztes Access/Jet-BE im Einsatz hat.

Anm.: Grundsätzlich ist/war OWNERACCESS dafür vorgesehen, dass man dem User den Zugriff auf die Tabelle verwehrt und diesen nur über eine Abfrage erlaubt. So kann man z. B. in die Abfrage Datensätze vorfiltern  oder bestimmte Felder nicht anzeigen, die den User verwehrt bleiben sollen.

mfg
Josef

mradlmaier

Klingt aufs erste Durchlesen ja gar nicht so kompliziert. Und das würde mit jeder DBMS, z.B. MySQL oder MS SQL Express funktionieren? Über ODBC?

In wie weit und wie, vestecke ich die Access-Menüleisten? Durch den Access-Optionen Dialog? Da bleibt aber eine Menüleiste stehen (die mit den Filtern, Schrifarten u.a.)

Apropos Filter: Würde die Access-Filter-infrastruktur dann auch noch funktionieren. Die Datensatz-Navigation funktioniert ja wohl auch in so einem Szenario?

Danke, das war sehr interessant und erleuchtend...
Zitat von: Josef am Mai 18, 2010, 17:13:26
ZitatDen Code zur Bindung an MS Access Formulare muss ich dann allerdings sebst schreiben, oder?


Ja.
Das wäre einmalig eine Funktion, die das Öffnen eines ADODB-Recordsets kapselt.
Und diese Funktion du dann in jedem Formular verwenden, wo du so einen Zugang nutzen möchtest.
Im Formular sieht das bei mir z. B. so aus:
private sub Form_load()
   set me.recordset = openAdoRecordset("select ... ", .... )
end sub


Die Textfelder usw. kannst du so nutzen, als würdest du eine Tabelle oder gespeicherte Abfrage als Datenquelle verwenden.
Deren Datenbindung übernimmt auch in diesem Fall Access.

Oder du verwendest in den Formularen eine spezielle Benutzerkennung aus deiner Access-Benutzerverwaltung:
Prinzip:
Dim ws As dao.Workspace
dim db as dao.Database
Set ws = DBEngine.CreateWorkspace("sichererWorkSpace", "Username", "Passwort")
set db = ws.OpenDatabase(....)
set me.Recordset = db.Openrecordset("select ...")

Anm.: dass man bei Wiederholter Verwendung von CreateWorkspace das ganze natürlich in eine Hilfsprozedur verlegt, ist sowieso klar. ;)

Aber: falls du eine Sicherheitskritische Anwendung erstellen willst, dann vergiss das Access-Sicherheitskonzept gleich wieder. Das ist ruck-zuck geknackt.


Falls du ein aktives DBMS verwendest, hättest du auch noch die Möglichkeit die Verbindungsdaten direkt in die Datenquelle das Formulars einzuarbeiten.
select ... form [ODBC;...].Tabelle
Dann würde es keine verknüpften Tabellen geben und somit hätte der Anwender auch keine Möglichkeit über die Tabellen die Daten zu ändern.

Apropos Anwender: für den Otto-Normalverbraucher kannst du eine Access-Anwendung auch so gestalten, dass das Datenbankfenster bzw. ab A07 die Navigationsleiste nicht sichtbar sind. Das ist aber nur ein Schein-Schutz. Wenn du die Daten vor mutwilliger Manipulation schützen willst, musst du meiner Ansicht nach im Backend dafür sorgen, dass nichts ohne Prüfung rein kommen kann. Dafür eignen sich z. B. gespeicherte Prozeduren oder auch Trigger.
Jeder Versuch so etwas nur über das Frontend abzusichern, ist meiner Meinung nach kein Schutz vor mutwilliger Manipulation.

mfg
Josef



mradlmaier

Josef,

Und da wäre nur das Öffnen des Recordsets im Formular nötig?
Wie erkennt dann MS Access welche Spalte im Recordset mit welchen Textelement im Formular korrespondiert? Dadurch dass die Spalten die gleichen Namen wie die Textelemente haben?

Und alles andere funktioniert automatisch...?


Zitat von: mradlmaier am Mai 18, 2010, 20:52:18
Klingt aufs erste Durchlesen ja gar nicht so kompliziert. Und das würde mit jeder DBMS, z.B. MySQL oder MS SQL Express funktionieren? Über ODBC?

In wie weit und wie, vestecke ich die Access-Menüleisten? Durch den Access-Optionen Dialog? Da bleibt aber eine Menüleiste stehen (die mit den Filtern, Schrifarten u.a.)

Apropos Filter: Würde die Access-Filter-infrastruktur dann auch noch funktionieren. Die Datensatz-Navigation funktioniert ja wohl auch in so einem Szenario?

Danke, das war sehr interessant und erleuchtend...
Zitat von: Josef am Mai 18, 2010, 17:13:26
ZitatDen Code zur Bindung an MS Access Formulare muss ich dann allerdings sebst schreiben, oder?


Ja.
Das wäre einmalig eine Funktion, die das Öffnen eines ADODB-Recordsets kapselt.
Und diese Funktion du dann in jedem Formular verwenden, wo du so einen Zugang nutzen möchtest.
Im Formular sieht das bei mir z. B. so aus:
private sub Form_load()
   set me.recordset = openAdoRecordset("select ... ", .... )
end sub


Die Textfelder usw. kannst du so nutzen, als würdest du eine Tabelle oder gespeicherte Abfrage als Datenquelle verwenden.
Deren Datenbindung übernimmt auch in diesem Fall Access.

Oder du verwendest in den Formularen eine spezielle Benutzerkennung aus deiner Access-Benutzerverwaltung:
Prinzip:
Dim ws As dao.Workspace
dim db as dao.Database
Set ws = DBEngine.CreateWorkspace("sichererWorkSpace", "Username", "Passwort")
set db = ws.OpenDatabase(....)
set me.Recordset = db.Openrecordset("select ...")

Anm.: dass man bei Wiederholter Verwendung von CreateWorkspace das ganze natürlich in eine Hilfsprozedur verlegt, ist sowieso klar. ;)

Aber: falls du eine Sicherheitskritische Anwendung erstellen willst, dann vergiss das Access-Sicherheitskonzept gleich wieder. Das ist ruck-zuck geknackt.


Falls du ein aktives DBMS verwendest, hättest du auch noch die Möglichkeit die Verbindungsdaten direkt in die Datenquelle das Formulars einzuarbeiten.
select ... form [ODBC;...].Tabelle
Dann würde es keine verknüpften Tabellen geben und somit hätte der Anwender auch keine Möglichkeit über die Tabellen die Daten zu ändern.

Apropos Anwender: für den Otto-Normalverbraucher kannst du eine Access-Anwendung auch so gestalten, dass das Datenbankfenster bzw. ab A07 die Navigationsleiste nicht sichtbar sind. Das ist aber nur ein Schein-Schutz. Wenn du die Daten vor mutwilliger Manipulation schützen willst, musst du meiner Ansicht nach im Backend dafür sorgen, dass nichts ohne Prüfung rein kommen kann. Dafür eignen sich z. B. gespeicherte Prozeduren oder auch Trigger.
Jeder Versuch so etwas nur über das Frontend abzusichern, ist meiner Meinung nach kein Schutz vor mutwilliger Manipulation.

mfg
Josef



Zitat von: mradlmaier am Mai 18, 2010, 20:52:18
Klingt aufs erste Durchlesen ja gar nicht so kompliziert. Und das würde mit jeder DBMS, z.B. MySQL oder MS SQL Express funktionieren? Über ODBC?

In wie weit und wie, vestecke ich die Access-Menüleisten? Durch den Access-Optionen Dialog? Da bleibt aber eine Menüleiste stehen (die mit den Filtern, Schrifarten u.a.)

Apropos Filter: Würde die Access-Filter-infrastruktur dann auch noch funktionieren. Die Datensatz-Navigation funktioniert ja wohl auch in so einem Szenario?

Danke, das war sehr interessant und erleuchtend...
Zitat von: Josef am Mai 18, 2010, 17:13:26
ZitatDen Code zur Bindung an MS Access Formulare muss ich dann allerdings sebst schreiben, oder?


Ja.
Das wäre einmalig eine Funktion, die das Öffnen eines ADODB-Recordsets kapselt.
Und diese Funktion du dann in jedem Formular verwenden, wo du so einen Zugang nutzen möchtest.
Im Formular sieht das bei mir z. B. so aus:
private sub Form_load()
   set me.recordset = openAdoRecordset("select ... ", .... )
end sub


Die Textfelder usw. kannst du so nutzen, als würdest du eine Tabelle oder gespeicherte Abfrage als Datenquelle verwenden.
Deren Datenbindung übernimmt auch in diesem Fall Access.

Oder du verwendest in den Formularen eine spezielle Benutzerkennung aus deiner Access-Benutzerverwaltung:
Prinzip:
Dim ws As dao.Workspace
dim db as dao.Database
Set ws = DBEngine.CreateWorkspace("sichererWorkSpace", "Username", "Passwort")
set db = ws.OpenDatabase(....)
set me.Recordset = db.Openrecordset("select ...")

Anm.: dass man bei Wiederholter Verwendung von CreateWorkspace das ganze natürlich in eine Hilfsprozedur verlegt, ist sowieso klar. ;)

Aber: falls du eine Sicherheitskritische Anwendung erstellen willst, dann vergiss das Access-Sicherheitskonzept gleich wieder. Das ist ruck-zuck geknackt.


Falls du ein aktives DBMS verwendest, hättest du auch noch die Möglichkeit die Verbindungsdaten direkt in die Datenquelle das Formulars einzuarbeiten.
select ... form [ODBC;...].Tabelle
Dann würde es keine verknüpften Tabellen geben und somit hätte der Anwender auch keine Möglichkeit über die Tabellen die Daten zu ändern.

Apropos Anwender: für den Otto-Normalverbraucher kannst du eine Access-Anwendung auch so gestalten, dass das Datenbankfenster bzw. ab A07 die Navigationsleiste nicht sichtbar sind. Das ist aber nur ein Schein-Schutz. Wenn du die Daten vor mutwilliger Manipulation schützen willst, musst du meiner Ansicht nach im Backend dafür sorgen, dass nichts ohne Prüfung rein kommen kann. Dafür eignen sich z. B. gespeicherte Prozeduren oder auch Trigger.
Jeder Versuch so etwas nur über das Frontend abzusichern, ist meiner Meinung nach kein Schutz vor mutwilliger Manipulation.

mfg
Josef




Josef

Hallo!

ZitatWie erkennt dann MS Access welche Spalte im Recordset mit welchen Textelement im Formular korrespondiert?


Das läuft im Prinzip wie bei einer Tabelle als Datenherkunft für das Formular. - Du kannst ganz normal mit den gebundenen Steuerelementen arbeiten und den Feldnamen in der Eigenschaft "Steuerlementinhalt" festlegen.

Wenn ich ein Formular an ein ADODB-Recordset binde, schreibe ich meistens in die Datenherkunft des Formulars ein Dummy-Datenherkunft, damit ich die Feldnamen nicht für jedes Steuerelement heraussuchen muss, sondern der Namen aus dem Dropdown wählen kann.
z. B.:
select 0 as ID, NULL AS ABC, NULL AS XYZ from tab1DS where 1 = 0
(tab1DS ist eine lokale Hilfstabelle im Frontend mit einem DS. Eine Tabelle ist notwendig, da man sonst bei den Steuerelementen die Feldnamen nicht auswählen kann.)

Das ist natürlich nicht unbedingt notwendig - du kannst auch in die Eigenschaft "Steuerelementinhalt" den Text manuell eintippen. Ich finde es nur praktischer und nebenbei auch weniger fehleranfällig (Tippfehler), wenn man die Felder der Datenquelle vorab definiert (den Select-Teil kann man direkt aus dem später genutzten SQL-String erzeugen).


BTW: Deine Beiträge werden durch die umfangreichen Zitate nicht unbedingt übersichtlicher. ;)


mfg
Josef

mradlmaier

Josef,

Könntest Du mir eine Buchemfehlung geben, die sich detailliert mit Konzept und Codierung von Microsoft Access Formularen als Frontend zu SQL Datenbanken befasst?

Danke