Re: Weak points in the framework. Do they exist?

Re: Weak points in the framework. Do they exist?

Old forum URL:

ajj3085 posted on Monday, January 07, 2008

1) To fetch objects from server the data access must reside in another  assembly, on client it must be excluded. Data that was filled into the business object must be obtain from data access layer in intermediate collections (or data tables). But there is problem with saving data to database, there must be some object which accepts business objects, and updates database. There must be some way not to expose data layer code to the client.

Why?  The data access code won't work on the client, if you set things up properly.  If the client isn't speaking directly to the database, which is the case if you use remoting, then the client "knows" about the schema and such, but that doesn't help someone attempting to hack.

Whether or not you use Csla, you must code against Sql injection attacks.

The business rules must be rechecked on server. May be it can be done in the framework, i dont know. But in the books there are no examples on this case. Examples, dont give fully protected solution, and there are no guidelines how to get full security from the framework.

That can be done very simply; call ValidationRules.CheckRules() as the first line of code in your DataPortal_Insert or DataPortal_Update. 

If the data access code absolutely cannot be on the client, then you'll need to create a web service (or some other RPC scheme), because your client is outside the trust boundry.  In this case, Csla can be helpful to check rules on the client, the DP methods will call web services.  Then you can have Csla business objects powering the web service.  At that point though you're duplicating a lot of logic.  If the cilent is outside the trust boundry, you don't really have a choice though.


Copyright (c) Marimer LLC