Otis wrote:
I see your problem, the thing is though that in your case, what's allowed and what not depends on the code consuming the entity, not the entity and its authorizer. So in effect, the authorization is external to the entity
I think authentication always depends on the code consuming the entity--or rather, the user on behalf of whom the code is consuming the entity--rather than on the entity itself.
Otis wrote:
if an entity is moved from method A to method B, it might be that other security rules exist: at some point when a piece of code wants to do something with an entity, what exactly decides what's allowed and what not?
This is not the case with my model. My conception (which I guess is a different pattern than the approach llblgen uses) is that an object is assigned to a "context" or "session" when it is created, and remains there until it is destroyed, and that context determines its security rules.
Otis wrote:
May I ask why you don't spawn a thread per client? It would make things much easier as you could use thread principal and also [ThreadStatic] to create thread local storage.
I do have one thread per client, and I've started looking at TLS. The catch is that while the thread will be servicing only one client, it may also need to do things that the client can't do. For example, maybe the client updates an object, which it has permission to do, but then the service needs to write an audit record, but clients don't have permission to create audit records directly. There are ways other than authorization to handle this, though, so I'm still thinking it through.
Ultimately I may just handle everything outside the llblgen framework, since I have the service layer processing the data requests from the client anyway.
I may also take a look at factory code as you suggested. Thanks for the ideas.