PDA

Vollständige Version anzeigen : Private Property ist gar nicht so privat wie erwartet


Toast78
21.04.2011, 07:24
Hallou,

ich speichere die Daten (RightsID, Abteilung, WindowsUserName...) in einer Klasse ab. Alle Variablen sind als private Klassenvariablen deklariert. Alle Property Lets sind als private deklariert, damit sie nicht verändert werden können.

Nun ist mir allerdings gerade aufgefallen, dass sowohl die Klassenvariablen als auch die Property Lets über das Testfenster problemlos verfügbar sind und somit geändert werden können. :upps: :entsetzt:
Das soll natürlich nicht so sein!

Das Objekt für den eingeloggten User ist als Public deklariert.

Wie kann ich denn Eigenschaften nach außen hin schreibschützen?

Josef P.
21.04.2011, 07:32
Hallo!

Verstehe ich dich richtig: du hast eine Property-Prozedur in einer Klasse als private deklariert und kannst auf diese Property von außen zugreifen?

Könntest du das bitte in einer Beispiel-Datei zeigen.

Was ist das Testfenster?

mfg
Josef

Atrus2711
21.04.2011, 07:32
Hi,

im Überwachungsfenster sind die zugänglich, ja.

Sie sind aber auch zugänglich, wenn du mal eben im Direktfenster m_DeineKlassenVariable = 4711 setzt.

Privat heißt, dass andere Codebestandteile nichts ändern dürfen. Händische Eingriffe von "Entwicklern" sind quasi immer möglich.

Und Entwickler ist jeder, der an den Code kommt.

Wenn du noch privater als private arbeiten willst, musst du mit Geheimtinte coden. Am besten Zitronensaft! :D

Toast78
21.04.2011, 07:53
@Josef: Es war der Direktbereich gemeint.
Danke Atrus für die Info. Na ein Glück, dass ich meinen Code durch ein super sicheres Passwort geschützt habe. :rolleyes:
Ich mag keine MDEs, aber das scheint wohl die nächste Stufe der Sicherheit zu sein. *grummel*

Josef P.
21.04.2011, 07:58
Ich mag keine MDEs, aber das scheint wohl die nächste Stufe der Sicherheit zu sein.
Du kannst den Code auch in eine COM-dll stecken.

Wenn du beschreibst, was du eigentlich erreichen willst, können vielleicht noch weitere Möglichkeiten gefunden werden.

mfg
Josef

Toast78
21.04.2011, 08:04
Ich möchte erreichen, dass die Eigenschaften eines Users, vor allem seine Rechte, zur Laufzeit nicht geändert werden können.
Dazu hätte ich am liebsten schreibgeschützte Eigenschaften, die nur beim Initialisieren durch (Me).Eigenschaft = Wert gesetzt werden können.

Atrus2711
21.04.2011, 08:07
Ich mag keine MDEs, aber das scheint wohl die nächste Stufe der Sicherheit zu sein

Aber auch nur die nächste. Denn auch MDE sind halbwegs re-engineerbar:

http://ms-office-forum.de/forum/showthread.php?t=270580&page=2&highlight=MDE+Schutz

Atrus2711
21.04.2011, 08:09
Initialisieren ist aber während der Laufzeit :) Merkst du was?

Wenn du ganz hart drauf bist, liest du den Kram von einer Smartcard oder einem Fingerabdrucksensor. Nur Hardware ist softwareseitig unveränderlich.

Josef P.
21.04.2011, 08:11
Ich möchte erreichen, dass die Eigenschaften eines Users, vor allem seine Rechte, zur Laufzeit nicht geändert werden können.

Wenn die Property-Let-Prozeduren als private deklariert worden sind, könntest du vielleicht überhaupt darauf verzichten und sie durch Sub-Prozeduren ersetzen. Wenn es nur für die Initialisierung ist, kommst du vielleicht auch nur mit einer einzigen Init-Prozedur aus.

Damit wäre dann nur die Get-Property verfügbar und somit auch über den Direktbereich keine Wertübergabe an die Property möglich.

Wenn du aber davon ausgehst, dass die Anwender den Direktbereich nutzen, kommt mir das so vor, als würden sie selbst Anwendungen entwickeln und du stellst ihnen eine Bibliothek zur Verfügung.
Sobald du die Anwender in den Code lässt ist sowieso jede Kapselung bei Bedarf änderbar, da sie den Code umschreiben können.

BTW: Wo sind eigentlich die Rechte gespeichert? Falls das in einer Tabelle ist, auf die jeder Zugriff hat, könnten die Anwender auch dort die Rechte umstellen - das ist vermutlich einfacher als bei jedem Anwendungsstart über den Direktbereich. ;)

mfg
Josef

Toast78
21.04.2011, 08:42
Initialisieren ist aber während der Laufzeit :) Merkst du was?
Wenn du ganz hart drauf bist, liest du den Kram von einer Smartcard oder einem Fingerabdrucksensor. Nur Hardware ist softwareseitig unveränderlich.Ja, das weiß ich, dass das Initialisieren während der Laufzeit erfolgt. Aber da die Property Let ja nur privat zugfreifbar ist, soll sie ja auch nur bei der Initialisierung benutzt werden. Die Initialisierung ist ja eine Methode der Klasse.
Wenn die Property-Let-Prozeduren als private deklariert worden sind, könntest du vielleicht überhaupt darauf verzichten und sie durch Sub-Prozeduren ersetzen. Wenn es nur für die Initialisierung ist, kommst du vielleicht auch nur mit einer einzigen Init-Prozedur aus.

Damit wäre dann nur die Get-Property verfügbar und somit auch über den Direktbereich keine Wertübergabe an die Property möglich.

Wenn du aber davon ausgehst, dass die Anwender den Direktbereich nutzen, kommt mir das so vor, als würden sie selbst Anwendungen entwickeln und du stellst ihnen eine Bibliothek zur Verfügung.
Sobald du die Anwender in den Code lässt ist sowieso jede Kapselung bei Bedarf änderbar, da sie den Code umschreiben können.

BTW: Wo sind eigentlich die Rechte gespeichert? Falls das in einer Tabelle ist, auf die jeder Zugriff hat, könnten die Anwender auch dort die Rechte umstellen - das ist vermutlich einfacher als bei jedem Anwendungsstart über den Direktbereich. ;)

mfg
JosefJa, die Rechte sind in einer Tabelle abgespeichert. Die Anwender können sich aber selbst nicht höhere Rechte einräumen, als sie selbst haben. Wenn sie denn überhaupt Änderungen an der Personen-Tabelle durchführen dürfen. Dort wird nämlich auch nochmal unterschieden.

Josef P.
21.04.2011, 08:51
Die Anwender können sich aber selbst nicht höhere Rechte einräumen, als sie selbst haben. Wenn sie denn überhaupt Änderungen an der Personen-Tabelle durchführen dürfen.
Wie steuerst du das in einer Access-DB?
Die Schreibrechte können doch nur auf Tabellenebene eingestellt werden. => Entweder man darf schreiben - dann darf man alles schreiben (was nicht durch RI verboten ist), oder man darf nur lesen.
Oder verwendest du ein aktives DBMS und gar keine Jet-DB?

Anm.: ich gehe derzeit davon aus, dass die Anwender vollen Zugriff auf das Datenbankfenster haben und den Direktbereich verwenden können - sonst wäre die ganze Diskussion in diesem Thread umsonst gewesen. ;)

zur property let für die Initialisierung:
Wie bereits erwähnt: ersetzte diese Property-Prozedur durch eine Sub und schon kann der Anwender die Property nicht mehr über den Direktbereich verändern.
Er würde allerdings die private Member-Variable (Feld) ändern können, sobald er es schafft einen Haltepunkt innerhalb der Klasse zu setzen.

mfg
Josef

Atrus2711
21.04.2011, 08:52
Hi,

du könntest

die Rechte bei Class-Initialize einlesen und die Property-Let-Routine dann ganz wegwerfen
oder eine Init-Prozedur schreiben, die zwangsweise benutzt werden muss (Factory-Pattern).


Dann ist die Instanz schreibgeschützt.

Alelrdings verhindert das nicht

dass man sich eine neue Instanz erzeugt
dass man die Werte in der Tabelle manipuliert.


Um mal Lord Kelvin abzuwandeln: "Everything that is stored is stored in a digital manner and can therefore be altered." Isso.

Toast78
21.04.2011, 09:19
Ich nutze eine Access-DB als Backend. Ich entwickle unter Access 2003 und die Formate für BE und FE sind Access 2000.
Momentan ist das noch alles offen zugreifbar. Datenbankfenster und Direktbereich können noch im jetzigen Stadium voll genutzt werden. Beim Starten wird lediglich das DB-Fenster nicht angezeigt. VBA-Code hat ein Passwort.
Im späteren Verlauf möchte ich allerdings noch die Shift-Taste deaktivieren und die Symbolleisten ersetzen, damit man nicht mehr an die Entwurfsansicht rankommt.

@Atrus: Ich habe mal den Thread gelesen. Frau 2.0 scheint ja gar nicht schlecht zu laufen :D