Restricting access to retrieved data - How?

Ah, I finally got it to work by adding it to the namespaces to the correct parts of the Web.config file.
Unfortunately, this doesn't appear to do what I hoped, as it receives the full query rather than the base entity collection being accessed.
Should I be doing this restriction in IdeaBlade at all, should I modify the underlying EDM, or is there another approach?

Cheers,
 Jason

One possible point of confusion which I'd like to clear up.  In DevForce the entire LINQ expression (of any complexity) is sent to and executed on the server, and only the results of that query are returned to the client.  So for example, a query like the following:

I understand that the entire Linq expression is passed, and the security risk here is that somebody is easily able to modify the client to remove the Where clause, returning every Product, whether we intended them to have access or not.

If we have a wholesaler system we might have the clause:
_mgr.Products.Where(p=> p.Id == 1 && p.WholesalerId == mywholesalerid)

The client executing the query may be logged in as Wholesaler #123, so the query the client sends out will be:
_mgr.Products.Where(p=> p.Id == 1 && p.WholesalerId == 123)

Now if I hack the client I can change this to
_mgr.Products.Where(p=> p.Id == 1 && p.WholesalerId == 321)
giving another client's records.

The solution is to use security at the server end to record the wholesalerID, and ensure every response sent is *always* filtered by wholesaler, effectively giving the currently connected client a projection of the database that only shows their data, giving a hacked server-side query of:
_mgr.Products.Where((p=> p.Id == 1 && p.WholesalerId == 321) && p.WholesalerId == 123)

As you say, adding a Filter property to IEntityServerFetching's EntityFetchingEventArgs would presumably modify the Linq expression to add the specified clause.
My code might then be something like this (all ficticious, but you get the idea)

        void OnFetching(object sender, EntityFetchingEventArgs e)
        {
            if (e.Query.ReturnType == typeof(Product))
            {
                int wholesalerid = GetWhilesalerId(HttpContext.Current.User.Identity.Name);
                iRisk.DataModel.iRiskEntities de = new iRisk.DataModel.iRiskEntities();
                e.Query.Filter = new Filter(p => p.Wholesaler.WholesalerID == wholesalerid);
            }
        }

In Linq2SQL you can easily override the accessors for the very bottom level collection, so even a complex join will have each low-level table filtered correctly, effectively allowing automatic server-side changing of
Customers Join Orders Join Items
to
(Customers where xxx) join (Orders where yyy) join (Items where zzz)

My (failed) attempt was as follows:
        public void OnFetching(EntityServerFetchingEventArgs args)
        {
            if (args.Query.ReturnType == typeof(Portfolio))
            {
                string uname = args.Principal.Identity.Name;
                args.Query = (args.Query as EntityQuery<Portfolio>).Include("Client").Where(p => p.Client.ClientID == 1);
            }
        }

Unfortunately this breaks when the system tries to load child entities:
{value(IdeaBlade.EntityModel.v4.EntityGroupProxy`1[DomainModel.Portfolio]).Where(t => (t.PortfolioId = 1)).OfType().SelectMany(t => t.Securities)}
:>
Expression of type 'System.Linq.IQueryable`1[DomainModel.Security]' cannot be used for parameter of type 'System.Linq.IQueryable`1[DomainModel.Portfolio]' of method 'System.Linq.IQueryable`1[DomainModel.Portfolio] Where[Portfolio](System.Linq.IQueryable`1[DomainModel.Portfolio], System.Linq.Expressions.Expression`1[System.Func`2[DomainModel.Portfolio,System.Boolean]])'

I seem to be almost there by overriding the CreateQuery of the ADO.Net Entity provider:

    public partial class iRiskEntities : global::System.Data.Objects.ObjectContext
    {
        public new ObjectQuery<T> CreateQuery<T>(string qry, params ObjectParameter[] parameters)
        {
            Debug.WriteLine(">>>>>" + qry);
            //if (typeof(T) == typeof(Portfolio))
            //{
            //    ObjectQuery<T> oq = base.CreateQuery<T>(qry, parameters);
            //    oq = from pf in oq where ((Portfolio)pf).Client.ClientID == 1) select pf;
            //    return (ObjectQuery<T>)oq;
            //}
            //else
            return base.CreateQuery<T>(qry, parameters);
        }
    }

Again, it's just the modification of the ObjectQuery that has me stumped.

I'll experiment with the InvokeServerMethod tonight, and possibly subject you to further questions tomorrow :)

I think the questions I'm asking are not unusual, and the dilema all .NET developers face nowadays is that you frequently have no idea whether you're using a product as the developers intended, or if you've completely missed the point in the 2,800 object definitions and interfaces in a suppliers object model :)
The abundance of "auto-generated documentation" (also known as "crap") is stifling, so I was very impressed with your extensive PDF manuals, and this is one aspect that attracted me to DF, so keep up the good work, and can I suggest that you release one soon with real-world example of security, both at basic role and row level, and include some nice demos of integration with MVVM approaches.

Cheers,
 Jason

One flaw in this plan;there is no HttpContext available to find the currently logged in user in the DF webservice, so I can't see any way of deriving the currently logged in user (either DF identity or the ASP.NET logged-in user).
Can you suggest either a way of retrieving this, or (better still) a workaround for the OnFetching problem I listed above?

Unfortunately, waiting until sometime in May to see what happens isn't a practical option for us.

Cheers,
 Jason