We are seeing a rather strange behavior and wanted to double check with you.
While running csla in 3-tier mode, a value set for csla.ApplicationContext.USer after authentication gets lost on reaching the client. When we debug, we see this value correctly inside the server code. On the client it changes to "Un-authenticated user".
So, as a work around, we are passing the IPrincipal value to the client and then manually setting it there again. But, this doesn't sound right.
Everything works great in 2-tier mode.
Shouldn't the csla.ApplicationContext.User value be the same on both client and server in 3-tier mode as well?
Really appreciate your help.
Actually, it is the other way. In a 3-tier mode you must set Csla.ApplicationContext.User on the client side.
And when authentication mode is not "Windows" that principal object must serializable and will be sent in the
DataPortalRequest to the server and set as ApplicationContext.User on the server side.
The principal object is NOT returned from the server to the client.
Thanks Jonny for the quick reply.
Let me clarify this, are you saying that csla.ApplicationContext.User flows only from the client to the server?
Since the authentication would involve code running inside our business layer/middle tier(security classes), this part naturally fell
on the server side for us, especially since it involves DB interaction. Now once authenticated on the server, there are other aspects that get set on the client side where in we need this User value. Are you suggesting that the authentication must happen on the client side?
Really appreciate your input.
Yes, ApplicationContext.User flows from client to server only when authentication mode is anything BUT "windows".
The authentication may well run code in the serverside. In Csla4 your principal object should inherit from Csla.Security.CslaPrincipal.
And you must set ApplicationContext.User on the "client" side in a 3 tier mode.
You could also look at the updated code for ProjectTracker:
All the authentication behaviors are discussed in the Using CSLA 4: Data Portal Configuration ebook.
The issue you see is due to state management.
The assumption is that the server is stateless - remembering nothing between client-initiated data portal requests. Therefore, the only place you can have long-term state is on the client.
Additionally, the client always needs the principal, because it will be continually checking authorization rules (in a smart client scenario anyway).
So it is reasonable to think that the client, always having the principal, would send it to the server with each data portal request, because the server never has the principal unless it is set on each client data portal call.
There are some variations on these themes - for Windows domain authentication, for web applications, or to minimize bandwidth for each data portal call over the network. These are discussed in the ebook.
Thanks both of you for clarifying this concept for us. I will make sure to double check the e-book.
Copyright (c) Marimer LLC