We are still using CSLA 3.83.
When we send requests from the Silverlight Client to the Host, code in GetBaseCriteriaRequest in WcfProxy.cs does this:
request.Principal = MobileFormatter.Serialize(ApplicationContext.User);
and that causes our Principal object, which is rather large (30k) to get sent to the server. On the server, we pull the User from the session so we are discarding the principal sent up from the client.
I don't see an override option to eliminate the sending of the Principal.
Should I just modify our Csla code to do this?
I haven't had to tackle this problem before - but conceivably could you go with a more manual serialization for your Principal/Identity. That is, overriding the serialization methods as necessary (OnGetState/OnSetState/OnGetChildren/OnSetChildren) such that you look @ whether you're in the Silverlight context and serialize a shell of the information you need (if any) versus the full amount - maybe through a compiler directive, etc.
In that way - you may be able to communicate a smaller scale Principal/Identity pair when making requests to the server from the client.
Anyway, just two cents.
This was an option added to CSLA, but I think it was in CSLA 4. In current versions it is absolutely possible to prevent the principal from serializing from client to server.
If you need to stick with the older version of CSLA then you may need to modify the framework code. But at least you can probably look at the current code to see how we did it.
This is related but a little off-topic -
I would guess that a 5k-10k principal/identity (ours is around that size) would be more efficient to pass with the request rather than have to re-fetch permissions/etc based on a forms authentication cookie on the server on each call...
What is the general motivation around this setting - is it security related? We have a certain "hash" that goes into our identity that is checked against the rest of the identity with each server call (not that something like that is entirely secure, but it definitely helps).
Thanks for replying. We keep the Principal in session in memory on the server. When the call from the client hits the server, code in
Application_AcquireRequestState populates the principal:
principal = (Lucity.Security. ];
So we are completely ignoring the Principal sent up from the client. Our app has lots of fine grained permissions (10,000+). When the Silverlight client needs a permission it has not already loaded it calls the server for updated permissions and keeps the updated Principal object locally in Silverlight. Over time, this object grows in size. For us it is usually 10k to start with, and often grows to 30k, but could grow to 100k or more if a user does a lot of different stuff within one session.
Thanks Rocky, we have been testing here and our change is working well! We appreciate the confirmation that our approach is probably valid as well as all the time you spend responding to questions about Csla!
Copyright (c) Marimer LLC