Zitat von
bundy:
Ich habe alle
SQL Scripts in die Middelware ausgelagert.
Sehr vorrausschauend!
Zitat von
Bundy:
Und da liegt jetzt wohl der Hund begraben, weil ja machen sachen nicht wirklich Datenbankabhäng sind.
Und? Lass diese Sachen auch von der Middleware berechnen und genauso wie alle anderen Daten auch als Datenpaket an den Client schicken. Wie gesagt, der Client sollte mit der sicherheitsabhängigen Logik nichts zu tun haben. Der Client sagt der Middleware "Gib mir Report, now!!!11", die Middleware schaut nach, ob der das überhaupt darf, sagt dann "Nö, iss nich", und der Client gibt eine passende Fehlermeldung aus, daß die Privilegierungsstufe nicht ausreicht. Wenn deine Datenschnittstelle zwischen Client und Middleware richtig designed wurde, ist es für den Client unerheblich, ob die Daten von der Middleware irgendwie erfasst wurden, oder ob die Middleware die Daen aus der Datenbank gepult hat. Der Client kriegt Daten und zeigt sie an, oder er kriegt keine und teilt dem Benutzer mit, daß er das nicht darf.
Zitat von
Bundy:
Sollte der User es schaffen den Knopf sichbar zu machen, besitzt er nicht das recht die Datenbankabrage durchzuführen.
Das wäre die Konsequenz davon, ja.
Aber, ähh... Wieso ist die Middleware zwar auf dem Server, die Firewall aber erst *hinter* der Middleware?
Zitat von
mschaefer:
Letzlich ist man bei Softwarentwicklung üblicherweise mit wachsenden Systemen am Arbeiten. Und da ist man Pleite, wenn alles vorher durchgeplant werden soll.
Wenn ich weiß, daß ich eine Datenverwaltung für einen größeren Datenbestand machen soll, bei dem ich mehrere Benutzer habe, die unterschiedliche Privilegien haben und ich sichergehen muss, daß niemand an Daten herankommt, an die er nicht herankommen darf, programmiere ich nicht einfach munter drauf los, sondern überlege mir *vorher* wie ich das bewerkstelligen kann. Gegen wachsende Systeme habe ich überhaupt nichts gesagt, aber hier liegen die Anforderungen bereits vor.
Zitat von
mschaefer:
Es wird immer gern gleich mit Webservices geschossen, aber das die
VCL wesentlich komfotablere Programme zuläßt als eine rein browserorientierte Anwendung, dies wied oft übersehen.
Das habe ich nicht übersehen und ich habe Webservice nicht auf ASP.NET beschränkt, sondern darauf hingewiesen, daß es auch andere Möglichkeiten gibt. XForms zum Beispiel. Oder das, was hier bereits halbfertig ist, ein schnöder Thin Client mit passendem Application Server dazu. Alles legitime Webservices, solange der eigentliche Service nicht beim Client liegt. Ich habe nicht den vorbesetzten Begriff für Webservice gemeint, als etwas, das mit einem Browser kommuniziert, weil das nur eine Möglichkeit von vielen ist. Browser muss nicht sein (und wäre hier der Usability wohl wenig dienlich).
Zitat von
Karstadt:
Wie kann ich den damit die nicht sichbare Objekte erkenne? Button1.visible False und nun?
Mit EDA kannst du die von der
VCL gar nicht erkennen, aber EDA zeigt, wie man's macht und somit bundy, daß ein solches Vorgehen nicht sicher sein kann. Schon mit EnumerateWindows() lassen sich nette Sachen machen, wenn man einfach nur abfragt, ob das Fenster sichtbar ist, oder nicht und plötzlich neugierig wird, wenn man auf ein unsichtbares Fenster stößt. Labels und alles andere ohne
Handle sind das einzige, was vor einer solchen Attacke sicher ist, es sei denn man hat Lust irgendwelche Message-Handler von allerhand Fenstern zu überschreiben und zu reimplementieren. Dazu lohnt aber der Aufwand schlichtweg nicht, die Gründe dafür finden sich in diesem Fred.