Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Portal
  • |
  • Mitglieder
Beiträge von Quallo
Thema: Konferenzen etc. zu Java, .NET, Softwareengineering und -Architektur
Am im Forum: Smalltalk

Naja, SOA ist nicht ganz so interessant für uns. Wir suchen eher nach guten Architektur- und Engineeringansätzen für SmartClients mit Webservicebackend.

Aber sei es drum, ein paar der SOA Konzepte sind darauf ja übertragbar.

Vielleicht kannst Du mir den Zeitplan ja zuschicken. Was ist denn deine Session da? Wäre schön Dich mal wieder zu treffen. Man erkennt Dich ja auf den Fotos schon kaum mehr wieder, mal ganz abgesehen davon, dass du jetzt verheiratet bist etc.


Grüße, Christoph

Thema: Konferenzen etc. zu Java, .NET, Softwareengineering und -Architektur
Am im Forum: Smalltalk

Danke!

Die prio klingt gut. Ich hoffe, dass es nicht nur speziell um .NET geht, sondern dass man auch abstrakteres Wissen mitnehmen kann, welches dann beispielsweise in Java Anwendung findet. Wie ist deine Einschätzung zu diesem Thema Golo?

War schon mal wer von Euch auf der jaoo? Was kennt ihr sonst für konferenzen im Java Bereich?


Grüße, Christoph

Thema: Konferenzen etc. zu Java, .NET, Softwareengineering und -Architektur
Am im Forum: Smalltalk

Hallo Community,

da wir in der nächsten Zeit eine unternehmensweite Entscheidung für .NET oder Java treffen werden, sind wir im Moment stark am Suchen nach den Vor- und Nachteilen der Plattformen und nach guten Tipps für die Architektur des folgenden Migrationsprojektes einer sehr großen Anwendung.

Welche Konferenzen oder Summits oder wie man das auch immer nennt zu den Themenbereichen .NET, Java, Softwareengineering und -Architektur könnt Ihr mir empfehlen? Bitte mit Links...

Danke im Voraus, Christoph

Thema: Aufräumen (Wie in Eclipse Menu --> Source --> Clean up)
Am im Forum: Entwicklungs- und Laufzeitumgebung (Infrastruktur)

Hallo Community,

nach einem etwas längeren Ausflug zu Java und Eclipse bin ich jetzt wieder beim Visual Studio. Unter Eclipse hat mir besonders gut gefallen, dass es eine Funktion für das Aufräumen des Quellcodes gibt, zu finden unter Menu --> Source --> Clean up. Diese Funktion sortiert Member innerhalb einer Klasse, fügt ein this.(...) ein wo es fehlt und vieles mehr. Man kann auch einstellen, dass dies automatisch beim Speichern vorgenommen wird.

Gibt es eine ähnliche Funktion in Visual Studio?


Grüße, Christoph

Thema: Liste darstellen und manipulieren
Am im Forum: GUI: Windows-Forms

Hallo Forum,

ich habe einen Webservice mit folgenden Operationen(hier Beispielhaft für Customer):
List<Customer> List();
void Update(Customer customer);
void Create(Customer customer);
void Delete(Guid ID);

Folgendes: Auf einem Windows Form möchte ich die List<Customer> darstellen (per DataGridView) und bei entsprechenden Manipulationen sofort(direkt nach dem Verlassen der Zeile) die Webservice Methoden aufrufen.
Wie ist das möglich? Es sieht mir so aus, als wenn Microsoft wieder super seine (ach so tollen...) Datasets unterstützt, die Sache mit Objekten aber nur halbherzig umsetzt.

Im Prinzip, sehe ich im Moment nur den Weg die ListItemChanged Events von BindingList<Customer> abzufangen und für das Delete von BindingList<Customer> abzuleiten und das RemoveItem zu überschreiben...

Ich bin auch mit einer tabellarischen Darstellung und RowChanging / RowDeleting / RowInserting Ereignissen zufrieden...

Am Besten wäre eine BindingSource / BindingList wo für jedes oben genannte Ereignis ein Event mit dem entsprechenden Objekt als Parameter aufgerufen würde.


Grüße, Christoph

Thema: Delete in 3 Schichten Architektur
Am im Forum: Datentechnologien

Zitat
Original von Yellow
Die Aggregatsfunktion SUM verletzt nach meinen Verständnis das Schichtenmodell nicht, da die SQL-Anweisung in der Businesslogik implementiert ist.

Implementiert ist die SQL-Anweisung nicht in der Businesslogik.
Allerdings ist dort der Aufruf einer Methode aus der Datenbankschicht implementiert, die einen summierten Wert erwartet. Das ist für mich in Ordnung.

Thema: Delete in 3 Schichten Architektur
Am im Forum: Datentechnologien

Zitat
Original von FZelle
Tja und ich würde lieber einen Dicken Appserver dazwischen hängen, der die BL hostet, und nen kleinen DB Server.

Der Appserver kostet "nur" Hardware, der DB-Server einen haufen für lizenzen.
Was meinst Du, ab wann da für den kunden der Preis stimmt?
Richtig ab der ersten installation.

Und natürlich gibt es fälle in denen man der db auch aufgaben geben kann/sollte,
aber nicht bei den Businessrules.

Da gebe ich dir prinzipiell recht, aber man sollte bedenken, dass die Datenbank umso stärker belastet wird, wenn ich die gleiche Datenmanipulation einzeln anstoße und dazu noch zwischenzeitig Informationen abrufe. Soll heißen, Stored Procedures sind oft so schnell, referentielle Integrität ebenso, dass die Datenbank kaum belastet wird. Wenn ich gleiche Funktionen über die Businessschicht mit CRUDL-Methoden abbilde, dann wird die Datenbank eher stärker belastet.

Thema: Delete in 3 Schichten Architektur
Am im Forum: Datentechnologien

Bei letzterem Punkt muss ich dir natürlich recht geben.

Aber wenn man das so betrachtet, dann sollte man durch die Datenbank ja gar nichts mehr machen lassen, ausser reines CRUD auf die Entitäten.

Wie sieht es mit der referentiellen Integrität(ohne löschen) aus, wie sieht es mit Aggregatsfunktion wie Sum... aus?


Grüße, Christoph

Thema: Delete in 3 Schichten Architektur
Am im Forum: Datentechnologien

Für Stored Procedures in der DB bin ich in so einem Fall auch nicht, außer es ist performancemäßig wirklich kein Stück anders abzubilden.

Aber ist das ausnutzen der referentiellen Integrität wirklich etwas, dass gegen Skalierbarkeit spricht? In meinen Augen nicht.
Wenn ich die Datenbank erst noch Fragen muss, wie die Schüler der Klasse heissen, bevor ich die Klasse lösche, und dann noch einzelne Löschbefehle für die Schüler loslasse, dann ist die Datenbank garantiert mehr ausgelastet, als wenn ich den Weg 1 wähle.

Wäre also nett, wenn Du deine Gedanken noch ein wenig erläutern könntest.


Grüße, Christoph

Thema: Delete in 3 Schichten Architektur
Am im Forum: Datentechnologien

Danke für Eure Antworten.

Im Prinzip kristallisiert sich die Lösung 1 heraus, besonders die Meinung von Yellow entspricht genau meiner Meinung.

Ich habe das in der Oracle DB bereits über Referentielle Integrität abgebildet. Sollte die beste Performance bieten und am wenigsten Aufwand sein.

Thema: Delete in 3 Schichten Architektur
Am im Forum: Datentechnologien

Der geschäftsfall heißt "lösche Klasse" und die Businessschicht muss dann eben wissen, dass sie eben alle schüler und deren noten löschen muss. das muss nicht das fontend wissen, richtig!

Die Frage ist, ob die DB das auch wissen darf!?

Thema: Delete in 3 Schichten Architektur
Am im Forum: Datentechnologien

Werte Mitstreiter,

ein paar Fragen zum Löschen in 3 Schichten Architekturen:

Ich habe Beziehungen zwischen Entitäten in der Datenbank, nehmen wir mal an, dass eine Klasse Schüler hat, die Schüler haben Noten.

Klasse 1 -- n Schüler 1 -- n Noten

Wenn ich jetzt in der Businessschicht den Geschäftsvorfall "lösche Klasse" habe, dann könnte ich auf zwei Arten vorgehen:

1.: Ich habe in der Datenbankschicht hinterlegt, dass beim Löschen von Klasse auch die entsprechenden Schüler und Noten gelöscht werden.

2.: Ich erstelle einen Geschäftsvorfäll für das Löschen eines Schülers und rufe diesen für alle Schüler der Klasse auf. Genauso wird bei den Noten für jeden Schüler verfahren.

Ich sehe bei dem 1. Modell weniger Aufwand und eine bessere Performance, bei dem 2. Modell sehe ich eine bessere Schichtentrennung, da es ja letzlich eine fachliche Anforderung ist, dass beim Löschen auch die abhängigen Entitäten gelöscht werden.


Was meint ihr dazu?

Thema: Intelligenz" der Datenzugriffsschicht
Am im Forum: Datentechnologien

Sorry für das hochschieben!

Bin aber inzwischen auch an Aussagen zu den DataTables/DataSets interessiert. Könnte ich mal einen Testfall zu aufsetzen.


Grüße, Christoph

Thema: Intelligenz" der Datenzugriffsschicht
Am im Forum: Datentechnologien

Die Änderungen an den Daten werden auch in Modell 2 nur von der Businessschicht vorgenommen.
Es ist ja die Businessschicht, die beispielsweise die Methode SetStatus(ID) aufruft.
Es wird also alles von der Businessschicht gesteuert und die Datenzugriffsschicht ruft nicht eigenmächtig solche Funktionen auf.

Sind die DataTable eigentlich unabhängig von den Datentypen der Datenbank?
Ich habe beispielsweise GUIDs in Oracle als raw(16), im Prinzip ein Bytearray, abgebildet. Die DataTable müssten also völlig unabhängig von der Datenbank arbeiten, damit sie auch wirklich als Schnittstelle zwischen der Businessschicht und einem austauschbaren Datenlayer liegen können.

Grüße, Christoph

Thema: Intelligenz" der Datenzugriffsschicht
Am im Forum: Datentechnologien

Zu geringe Flexibilität(Datenmodell sowie Businessobjekte müssen sich an ORM anpassen(besonders unschön, wenn man mit WCF auf Client und Server arbeitet und die Businessobjekte Attribute des ORM haben...)) und geringe Performance(teilweise arbeiten wir nicht nur mit optimierten SQl-Befehlen, sondern auch mit Optimizer Hints oder berechnen sogar Daten in temporären Tabellen vor, auf die wir dann per View zugreifen). Teilweise wurde haufenweise Code genriert oder man musste bei kleinen Änderugen immer wieder mit Assistenten arbeiten...

Für kleinere Sachen ist es sicherlich schöner als die per Assistent generierten Monolithen, bei performancekritischen Programmen wird es schon schlechter...


Grüße, Christoph

Thema: Intelligenz" der Datenzugriffsschicht
Am im Forum: Datentechnologien

Hallo,

ich habe eine Frage zur "Intelligenz" der Datenzugriffsschicht.
Generell muss ich sagen, dass die Datenzugriffsschicht mir eine List<T> zurückgibt.

Zwei Ansätze:
1.: Die Datenzugriffsschicht hat Methoden für Create, Read, Update, Delete und List, die mir Businessobjekte ohne Beziehungen zurückgeben.
In der Businesschicht würde ich dann wenn ich ein Attribut ändern will erst ein Read machen, die Eigenschaft ändern und dann ein Update. Beziehungen zwischen Objekten würde ich in der Businesschicht aufbauen(Beispiel: Nutzer hat Adresse...).

2.: Die Datenzugriffschicht hat intelligentere Methoden, beispielsweise eine SetStatus(ID) Methode, mit der ich den Status des Nutzers mit der Identität ID ändern kann. Man sollte dabei natürlich nicht absolut ins Detail gehen und für jedes Feld eine eigene Methode implementieren, sondern nur für Felder, wo es auch wirklich Geschäftsvorfälle für gibt.

Ich bevorzuge die zweite Variante, da sie deutlich mehr Performance und Rahmen für Optimierungen bietet (in diesem Projekt sehr wichtig). Natürlich ist der Implementierungsaufwand ungleich höher, was man aber durch ein geschicktes Framework wieder deutlich senken kann. Ich möchte mich allerdings nicht völlig auf den Holzweg begeben!


Bitte nicht in Diskussion ausarten lassen, ob ein OR-Mapper sinnvoller wäre oder ob man Datasets an die Businessschicht zurückgegeben sollte. Wir haben uns bewusst dagegen entschieden!


Grüße, Christoph

Thema: Gliederung von css / Best pactice
Am im Forum: Web-Technologien

Vielen Dank, dann werde ich mit CSS-Klassen arbeiten!

Scheint ja eigentlich nur Vorteile zu geben, besonders mit einem externen Designer!


Grüße, Christoph

Thema: Gliederung von css / Best pactice
Am im Forum: Web-Technologien

Der Designer kann mir aber auch sagen, dass ich bei bestimmten ServerControls bestimmte Styles einfügen soll

Ich glaube, dass ich erstmal gar kein CSS einfüge(außer wo dringend(!!!) notwendig) und dann mit dem Designer spreche.

Du machst also grundsätzlich für jedes Element mit gleichem Design eine eigene CSS-Klasse und weist sie dem ServerControl zu? Oder arbeitest du mit den IDs der Controls und referenzierst die im CSS?


Grüße, Christoph

Thema: Gliederung von css / Best pactice
Am im Forum: Web-Technologien

Hallo Community,

gibt es eine best practice für die Gliederung von css mit ASP.NET 2.0?

Mit Gliederung meine ich hierbei, wann ich innerhalb eines Server Controls direkt den Style setze (style="...", bzw. wann ich auf Klassen verweise (CSS-Class="...") oder mit der ID (id="...") arbeite.

Meine Anwendung wird absolut basic erstellt und soll dann zu einem Designer gehen, der im Idealfall nur noch das CSS bzw. ein paar html-Tags verändert.


Grüße, Christoph

Thema: GUID als Parameter ausreichend sicher?
Am im Forum: Web-Technologien

Zitat
Original von burning snow
Ich für meinen Teil bin für Sicherheit und nicht für generische Lösungen. Es wird bei einer Sicherheitsschicht nie eine generische Lösung wie du das haben möchtest geben.

SSL finde ich beispielsweise eine nette Lösung für jedes Projekt in dem ich Verschlüsselung brauche. Klappt bei Amazon und Ebay, in dem Sinne meine ich generisch!
Zitat
Und unter anderem sollte das Argument "die und die Firma machen es auch nicht" auf jedenfall nicht gelten. Das Argument kannst du beim Kunden auf gar keinen Fall verwenden und hebst dich dann auch nicht von der Konkurrenz ab.

Ich denke, dass ich es nicht gut finde, wenn andere soetwas tun und dass ich es auch nicht tun werde, ist wohl klar. Außerdem arbeite ich in einem Laden, der groß genug ist, dass man als Entwickler / Architekt keine Projekte an Land holen muss
Zitat
Dein Problem die Parameterverfälschung entsprechend zu umgehen, kannst du auch so durchführen dass du keine Parameter in der URL übergibst sondern nur über Sessions. Das wäre zur den Business Rules ein weiterer Schritt die Anwendung sicherer zu machen.

Wie gesagt, es geht nicht nur um Parameter, sondern auch um auf Smart Clients hinterlegte Stammdaten. Das ist nicht innerhalb von Sessions. Ansonsten würde deine Lösung mich schon interessieren, rein vom Konzept her.
Zitat
Ich möchte mit VizOne anschliessen und möchte dir wirklich ans Herz legen, dass du das Thema Sicherheit mit in die Planungsphase mitnimmst.

Die Planungsphase läuft im Moment, es ist noch keine Zeile Produktivcode geschrieben. Es wird gerade über die Architektur nachgedacht und es werden Prototypen für einzelne Teile entwickelt, nur als Proof-Of-Concept.

Trotzdem danke für die Wünsche und die Hilfe!

Thema: GUID als Parameter ausreichend sicher?
Am im Forum: Web-Technologien

Zitat
Original von VizOne
Ich glaube dir natürlich, dass dir die Sicherheit wichtig ist, sonst würdest du dir sicher nicht so viele Gedanken machen. Mit "auf die leichte Schulter nehmen" meinte ich eher, dass du auf der Suche nach einer leichten Lösung vielleicht nicht ganz bis zu Ende gedacht hast.

Mir ging es auch weniger darum, die Möglichkeit der Parameterfälschung zu beurteilen, sondern vielmehr darum, ein Bewusstsein zu schaffen, Sicherheit zu einem First-Class-Member der Programmlogik zu machen. Eben wirklich Sicherheit by Design und nicht "by Zufall der Datenkeys"

Zudem ließe sich eine flexible, wiederverwendbare Lösung sicherlich programmieren. Wenn man Businessrules im Code forciert und Sicherheit zu einer Businessrule erhebt, lässt sie sich relativ problemlos in die Anwendung integrieren. Man kann das aber auch trennen und dann eine recht einfaches API à la bool MayPerform(User user, Action action) verwenden, welches intern die Rollen des Nutzers und z.B. den Zustand der Anwendung überprüft und daraus Rückschlüsse über die Zulässigkeit bestimmter Aktionen zieht.

Viel Erfolg auf jeden Fall weiterhin!

Viele Grüße,
Andre

So eine wie von dir angedachte Lösung habe ich bereits in einem Projekt implementiert. Dort liegt allerdings ein Großteil der Überprüfungslast in der Datenbank und schluckt auch ganz gut Performance (ist aber auch wirklich recht komplex). In der Businessschicht ist im Prinzip nur der Aufruf an die Datenbank schicht, dass das überprüft werden soll. Naja, womit es im Prinzip auch in der Businessschicht liegt... Es ist dann übrigens eher ein MayPerform(Wer, Was, Womit). Womit bezeichnet den Datensatz / die Datensätze.
Die Berechtigungsdaten werden zu Anfang der Session einmalig aus der Datenbank geladen (bzw. bei Berechtigungsänderungen neu geladen). Für die Prüfung auf Satzebene ist dann ein zusätzlicher Roundtrip erforderlich.

War halt sehr viel Arbeit, auch wenn ich es zum Teil migrieren kann.

Vielen Dank für deine Bemühungen auf jeden Fall!

Thema: GUID als Parameter ausreichend sicher?
Am im Forum: Web-Technologien

Mit dem persönlich meinte ich persönlich verletzend, ist aber zurückgenommen, da es so von dir nicht gemeint war.

Ich sehe Sicherheit als sehr wichtig an, dass kannst du mir sehr wohl glauben! Sonst würde ich keine Diskussionen darüber führen und nicht (als normalerweise Nicht-Webprogrammierer) über Dinge wie Parameterfälschung nachdenken. Ich kenne übrigens einige Firmen bzw. Anwendungen, die dies gar nicht tun. Dass ich hier nicht herauspuste wer das sind, ist wohl klar (wir sind es nicht(!!!)).

Ich habe mich übrigens nicht dagegen gesträubt, zumindest nicht mehr als ihr diesen Vorschlag anzuerkennen. Es wäre doch sicherlich schön, für soetwas wie parameterfälschung / -veränderung eine generische, sichere Lösung zu haben, das war mein Gedankengang.

Ich habe übrigens im Bereich der Webservices, wo ja auch alles fälschbar ist, bereits Lösungen implementiert, wo ich die Sicherheit auf die Satzebene gebracht habe. Ist nur sehr viel Aufwand, eine generische Lödung wäre da schön!

Hoffe, dass du diesen versöhnlichen Worten zustimmen kannst.




Grüße, Christoph

Thema: GUID als Parameter ausreichend sicher?
Am im Forum: Web-Technologien

Zitat
Original von burning snow
Was möchtest du denn eigentlich nun bezwecken?

Ein User soll keine Daten von einem anderen User sehen? Richtig?

Wenn ja, kannst du ja soetwas wirklich super über die Authentifizierung lösen oder sehe ich irgendetwas falsch?

Die Frage ist nur, ob man an bestimmten Stellen das Berechtigungssystem auf Datensatzebene herunterziehen will, oder ob man davon ausgehen kann, dass es durch die Nichtkenntnis einer Identität(als GUID), die vom Server nur an authorisierte Benutzer herausgegeben wird, hineichend sicher ist.


Grüße, Christoph

Thema: GUID als Parameter ausreichend sicher?
Am im Forum: Web-Technologien

Zitat
Original von VizOne
Hallo,

Mit deinem Vorschlag versuchst du lediglich, die Wahrscheinlichkeit bestimmter Symptome (Datenzugang für unbefugte Nutzer) klein zu halten, statt dich um die Ursache zu kümmern (unsichere Anwendung). Was du vorhast ist keine Lösung, sondern ein Hack, der wahrscheinlich funktioniert.
siehe unten...
Zitat
  • Was ist, wenn eine MS SQL Server Datenbank verwendet wird, bei der statt NEWID() NEWSEQUENTIALID() verwendet wird?
  • Was ist, wenn man statt Guid.NewGuid() Combs verwendet?
  • Was ist, wenn die IDs unter WinNT generiert werden, wo GUIDs nicht zufällig, sondern mit hoher Wahrscheinlichkeit sequentiell sind? [/quote]Die GUIDs werden allesamt mit GUID.NewGuid() erzeugt. Dass das ganze von der sicheren Zufälligkeit der GUIDs abhängt ist mir klar, das sollte auch aus den Ursprungsposts herausgekommen sein...
    Zitat
  • Was ist mit Browser-History? Die GUIDs stehen dort im Klartext drin. Mal eben nachsehen, was der Kollege macht... [/quote]Das ist übrigens der einzige Punkte, den ich auch, die Zufälligkeit der GUIDs vorausgesetzt, als Angriffspunkt sehe. Sonst ist es praktisch unmöglich so eine GUID zu erraten. Ich denke, dass wir da übereinstimmen, oder?
    Werden die Daten, die innerhalb von SSL-Verbindungen zustande gekommen sind überhaupt in der Browser-History gespeichert?
    Btw.: Bei Cookies ist es übrigens ebenso. Sobald man etwas auf dem Client speichert, in welcher Form auch immer, ist es unischer.
    Zitat
  • Was ist mit Szenarien, die du und ich nicht kennen? [/quote]Wenn dann sollte es by Design "ausreichend" sicher sein, "ausreichend" per üblicher Definition (im Prinzip kann man mit genügend Zeit alles knacken, auch PPK).
    Zitat
    [/list]

    Ups. Vielen Dank. Bei sensiblen Daten möchte ich mich auf so ein "System" nicht verlassen. Obige Punkte enthalten übrigens einige Punkte, bei denen die Sicherheit deiner Anwendung tatsächlich von der Datenhaltungsschicht abhängen. Bei einer Prüfung innerhalb der Businessschicht ist das eben nicht der Fall. Dort wird ganz klar geguckt: wer will was machen? Was darf er?
    Innerhalb der Datenschicht ist dies auch der Fall, nur technisch anders realisiert.
    Das das im Idealfall besser in der Businessschicht aufgehoben ist, ist mir wohl klar.
    Das sollte aber nicht Zentrum dieser Diskussion sein!
    Zitat

    Im Sinne deiner Kunden kann ich dich nur bitten, das Thema Sicherheit etwas tiefergehend zu betrachten als "Wird schon nichts passieren."
    Ähem, das finde ich dann doch ein wenig flapsig! Was meinst du, warum ich solche Ideen in einem Forum zur Diskussion stelle! Wahrscheinlich nicht, weil ich sie schon implementiert habe, sondern, weil sie eine Idee sind.
    Zitat

    Grüße,
    Andre

    Bitte nicht gleich persönlich werden (zumindest habe ich es so aufgefasst), wenn man technische Ideen diskutiert.

    Ebenso Grüße.

  • Thema: GUID als Parameter ausreichend sicher?
    Am im Forum: Web-Technologien

    Die Chance, dass jemand ein Passwort errät ist allerdings höher. Also ist das ein wesentlich besseres Angriffsziel...
    Es geht ja um bewusste Manipulation. Und ich glaube nicht, dass sich da wer ran traut eine GUID zu erraten, wäre auch ziemlich blöd...

    Thema: GUID als Parameter ausreichend sicher?
    Am im Forum: Web-Technologien

    @VizOne: Ich weiß nicht, ob Burning Snow das ebenso sieht.
    Im Prinzip hast du natürlich völlig Recht! Ich weiß zwar nicht, ob ich diese Rules alle im Business Layer unterbingen kann, aber wenn man Rechteverwaltung teilweise auch mit in der Datenbank festmacht, sollte es keine grobe Verletzung der Schichtenarchitektur darstellen. Es muss nur klar sein, dass diese Rechteverwaltung bei Austausch des Datenbanklayers auch implementiert werden muss.
    Ich bin noch am evaluieren, ob ich das alles im Business Layer unterbringen kann. Die Grundlegende Rechteverwaltung auf jeden Fall, auf Datensatzebene mal schauen.

    Ich bitte jetzt noch einmal folgendes zu diskutieren:
    Ich denke trotzdem, dass man gewisse Dinge nicht auf Datensatzebene absichern muss, beispielsweise wenn es um Daten geht, die nur angesehen werden können, bzw. bei denen jeder Benutzer seine eigenen Daten ändern darf.

    Noch mal ein Beispiel: Es gab bei der Telekom (ohne Garantie auf Richtigkeit, habe es selbst nur im Web gelesen) mal einen Fall, in dem man Daten von anderen Kunden einsehen konnte.
    Man musste nur eine ID in einem Link ändern (Beispiel: ViewVertragsdaten.aspx?Kundenid=175 in ...?Kundenid=176 ändern) und hatte dann die Daten von jemand anders.

    Wenn ich in diesem Fall eine Guid einsetzte, ist es allerdings nicht möglich, die GUID eines anderen Kunden zu erraten. Die GUID ist 128 bit lang, also müsste ich selbst bei Millionen von Datensätzen 2^x, wobei x größer als 100 ist, also beispielsweise 81129638414606681695789005144064 für 2^106 Versuche starten, um eine GUID zu erraten. Selbst wenn es durch irgendein statistisches Phänomen (Geburtstagsparadoxon etc.) noch mal eine Million mal weniger wären, wäre es immer noch praktisch völlig unmöglich. Das wären bei 10 Versuchen pro Sekunde über 257.260.395.784.521.441.196.692 Jahre. Vorher geht das Universum noch zig mal unter. Da ist es doch einfacher das Passwort eines Benutzers zu knacken.

    Thema: GUID als Parameter ausreichend sicher?
    Am im Forum: Web-Technologien

    Ich denke schon, dass ich weiß was Sessions sind.

    Es geht darum, dass jedes Objekt in der Datenbank eine GUID hat. Wenn jetzt ein Benutzer der Webanwendung innerhalb seiner Session irgendeine Aktion macht, bezieht sich diese Aktion meist auf eben solche Objekte.
    Beispiel: Er hat einen Buchungsdatensatz angelegt und will ihn wieder löschen.
    Er muss irgendwie sagen, welchen(!) Buchungsdatendatz er löschen will. Dies geschieht dadurch, dass er eine Auswahlliste hat. Die Auswahlliste besteht aus sehr vielen Links, jeder steht für einen Datensatz und jeder Link hat als Parameter die GUID des Datensatzes.
    Übertragen auf den Webservice, ruft der Webservice eine Funktion auf, die die GUID als Parameter hat.
    Die GUID innerhalb des Links ist natürlich durch den Benutzer manipulierbar (so wie alle Daten die auf dem Client landen grundsätzlich manipulierbar sind).

    Bei einer GUID ist die Manipulierbarkeit m. E. kein großes Problem, da er sie ruhig ändern kann. Die Anfrage trifft dann stumpf ins Leere, da er nicht die GUID eines anderen Datensatzes erraten kann. Dies ist bei sequentiellen IDs natürlich anders.
    Meine Frage war, ob dies zutrifft.

    Problematisch wird es erst, wenn er eine GUID eines Datensatzes kennt (weil er beispielsweise ein View darauf hat), diesen Datensatz aber nicht löschen darf. Er darf allerdings andere Datensätze löschen. Dann könnte er die GUID (als Parameter eines Links) eines Datensatzes den er löschen darf durch die GUID des Datensatzes ersetzen, den er nicht löschen darf. Dies muss ich sicherlich applikationsseitig abfangen.


    Grob gesagt, geht es um die Manipulierbarkeit von Parameterdaten auf dem Client und ob es best practices gibt um das zu verhindern oder zu umgehen.


    Grüße, Christoph

    Thema: GUID als Parameter ausreichend sicher?
    Am im Forum: Web-Technologien

    Also sollte ich jede GUID in der Session speichern und in die URL eine andere ID übergeben, beim Aufruf der URL dann Mappen?
    Auch ein ganz schöner Aufwand, besonders bei Quersprüngen...

    Problematisch wird es dann allerdings, wenn ich die zu Grunde liegenden Komponenten auch für Webserviceaufrufe nehmen will, die teilweise von Smart Clients mit Stammdaten stammen, die GUIDs wurden vorher in der Session also nicht übermittelt.

    Thema: GUID als Parameter ausreichend sicher?
    Am im Forum: Web-Technologien

    Vielen Dank für eure Meinungen!

    @burning_snow: Wie sollen mir Sessions in dem konkreten Fall helfen? Dass ich Sessions benutze steht wohl außer Frage.

    @Andavos: Ich sehe das nicht als Security by Obscurity an um ehrlich zu sein.
    Wenn wirklich nur der User diese GUID zu Gesicht bekommt, kann man sich die GUID wie ein Passwort pro Datensatz vorstellen. Die GUID ist wesentlich länger als ein normales Passwort und durch die Zufälligkeit auch schwerer zu erraten. Wie gesagt, bevor ich versuche die GUID eines Users per Brute Force zu attackieren, kann ich eher sein Passwort per Bruce Force knacken.

    Wie gesagt, dass gilt alles nur, wenn lediglich der User, der das Recht auf einen Datensatz hat, die GUID auch sieht, sonst ist es hinfällig.


    Natürlich sind die Rechte ein wenig komplizierter gelagert. Das Ganze geht eher über 15-20 Tabellen, teilweise relational bzw. ineinander hierarchisch verknüpft.
    Da verlangt es schon ein wenig Power Datenbankseitig um zu jedem Datensatz über mehrere Tabellen zu prüfen, ob der Nutzer auf genau diesen Datensatz zugreifen darf.

    Eine Extra Tabelle ist zwar eine nette Idee, aber das würde die Datenbank doch sehr aufblähen und ich müsste bei jedem eingefügten Datensatz einen weiteren Datensatz schreiben bzw. beim Löschen einen weiteren löschen.
    Falls jemand mal so ein Modell implementieren muss, sollte er das bedenken. Und natürlich sollte man "rechte" dann nicht als Flag in der Datenbank speichern(es soll ja alles atomar sein), sondern als verschiedene Felder.



    Gibt es nicht irgendwie einen anderen Ansatz?




    Grüße, Christoph

    Thema: GUID als Parameter ausreichend sicher?
    Am im Forum: Web-Technologien

    Hallo Jungs und Mädels!

    Ich habe in einer Datenbank GUIDs als Primärschlüssel und benutze sie auch als Identität für meine Business Objekte.
    Folgendes Szenario: Ein User X hat Datensätze und ein User Y hat Datensätze, alle Datensätze in einer Tabelle. User X darf nicht mit den Datensätzen von User Y in Berührung kommen, User Y nicht mit den Datensätzen von User X.

    Nehmen wir an ich hätte jetzt sequentielle IDs statt GUIDs.
    Folgende Methode, die einen Datensatz anzeigt und als link im geschützen Bereich von User X ist: http://www.mydom/myapp/viewdata.aspx?id=123 .
    Nun könnte jeder "Hacker" auf die Idee kommen, wenn er statt einer 123 eine 124 eingibt, einen anderen Datensatz zu sehen. Deswegen muss ich applikationsseitig prüfen, ob der Datensatz 124 auch zu User X gehört. Dass dies viel Arbeit und Implementierungsaufwand ist, ist wohl klar, von der Performance mal zu schweigen...


    Wie sieht es jetzt bei meiner Applikation aus, die ja GUIDs als Schlüssel benutzt.
    Reicht es da aus zu sagen, dass die GUIDs zufällig gewählt und nicht vorhersehbar sind, um ein ausreichendes Maß an Sicherheit zu erhalten? Es sind ja 2^128 Möglichkeiten, die vorhanden sind, also selbst bei ca. 1.000.000 Datensätzen noch ca. 2^108 Versuche um eine GUID zu erraten. Es wäre auf jeden Fall stets weniger Aufwand, per Brute Force das Passwort eines Users herauszufinden.

    Gibt es vieleicht bzgl. History im Browser oder temporärer Internetdateien noch etwas zu bedenken?

    Falls ich doch etwas implementieren muss, da ein Benutzer zwar einen Datensatz sehen, ihn aber nicht löschen darf, was ist die einfachste Art so einen Mechanismus zu implementieren?

    Gibt es was generisches(Best Practices, Patterns) oder muss man das je nach Business Case prüfen?



    Grüße, Christoph

  • Made with ♥ and ASP.NET Core. Rendered in 112.11ms. Running Version 0.1.323+41ca3bb1e5 on Azure App Service (debian.10-x64 with .NET 5.0.8)
    Copyright 2003-2021 myCSharp.de - Alle Rechte vorbehalten. Benutzerinhalte unterliegen cc-by-sa 4.0