IEntityServerFetching - Which entities are we retrieving?

Hi,
We have implemented our security in the IEntityServerFetching interceptor but have come up against a tricky situation.
When we devised our security structure using RIA, the MS based services gave us the underlying GetClient, GetOrder etc methods, and for any client Linq request those methods were always called, even if the query was a join of a '.Include("Orders")' style request.
In each method we would then append the query with the filter function to ensure the user only receives objects for which they have valid permissions.
In DevForce though the OnFetching method is only called once for any query, so although we may look at args.Query.QueryableTypeto find the entity type to filter, it is far more difficult to find any 'other' relationships in the query.
For example, if wesay something like
from c in dd.Customers.Include("Orders").ToList()
then we would have to add two filters to our query, one on Customers, one on Orders, but the option is not presented as it is in RIA unless we work out how to parse the Query tree and see which tables are referenced, then add individual .Where filters in conditional blocks to extend the query appropriately.
Do you have any suggestions as to how we might approach this?

Cheers,
  Jason

My RIA coding is now a little rusty (after switching mindsets to DevForce), but I seem to remember you use the [Include] attribute in the metadata partial class, and that forces eager fetching, and I think there was another method on the Linq statement.
Either way, the subsequent fetches were also directed through the GetX() methods, allowing true filtering at each level of the query tree, so whether you did 'from c in Customers() join o in Orders()' or simply 'from c in Customers().Include("orders"), the interception was still possible.
This is extremely important in any auditing or security system, so I'll be interested to see if the EntityQueryFilterCollection addresses the first example, but it is extremely important that the filters also apply against 'Included' relationships because this is effectively an eager fetch in the same way as any conventional left outer join.
If the syntax wasn't so awful for the outer joins we would use them in place of the Includes, so we may have to do this in the short term.

Are there any good reasons to not apply the filter collection to the Included elements? What are the conceptual differences between .Include and the tortuous left outer join in Linq?  Is there anything we should beware of?

Cheers,
 Jason

I may have been mixing my technologies.  Astoria definately allows this per-entity type interception, and as the RIA and Astoria teams are merging I expect we will see the same thing once RIA is finalised.
Either way, it's a crucial requirement when you're providing client-side querying, as otherwise there is no practical intercept point in eager-loading to ensure the client is requesting only the data they have access to.
I wonder how Astoria do it, since they also sit on top of EF.
The EF preview for .Net 4 is released today, so I'm sure this will open up a whole new world of pain...

Cheers,
 Jason