I could not verify the behavior you described.

 

In an Interceptor, if I try:

 

 

newEm will be logged in and it will not trigger the LoginManager.

However, if I try:

 

 

newEm will not be logged in and the LoginManager will be triggered when the query is executed. (expected behavior)

 

Can you provide a simple solution reproducing your issue?

 

Silvio.

 

 

 

 

the newEm will be logged in as well.

 

 

As for using Login(Guid SessionKey), it takes a "different route" (i.e. internal route) than Login(ILoginCredential credential) and doesn't actually go thru your login manager.

 

I can't think of a way of detecting where the login is coming from. I will double check with our senior engineer.

However, since the LoginManager is only triggered when using Login(ILoginCredential credential), the common case would be it being triggered by the client. That's unless you are passing credentials to a RSMC, have it hardcoded in the interceptors, or simply is logging in with null credentials.

 

Silvio.

 

What of linking an entitymanager to the entitymanager in a saveinterceptor? I presume the one is logged in, but when you use it to link a new entitymanager the new one is not logged in. Something like...

Per the IsClient. I was meaning that in the LoginManager I saw no way to detect if the login was triggered via the client or server (ie. serverside I create an entitymanager and log it in vs create one on the client and log it in). Is there a way?

When you create an Entity Manager in the client, it's not logged in.

If you don't explicitly login, but tries to perform and operation (i.e. query/save) the Entity Manager will automatically login as a Guest (assuming you allow guest users - in your app.config). Logged in, but not authenticated.

In the server the base type EntityManager will be logged in and, if the client is authenicated, authenticated as well. Even though you cannot access the Principal via EntityManager.Principal, you can do so via the Save/QueryInterceptor (i.e. this.Principal) with all the information would find in the client's EM.Principal.

Regarding your second post, wouldn't passing the Principal from the Interceptor (i.e. this.Principal) to the audit code resolve the issue? (if you wanted the code to be the same in the client and server, couldn't you pass mgr.Principal from the client as well?)

As for your last post, in my tests my local (i.e. in the client) mgr.IsClient will return true while my SaveInterceptor's EntityManager.IsClient will return false. Can you provide a simple test case reproducing the issue?

Regards,

      sbelini.

I tried EntityManager.IsClient when our app initially logs in and it returns false. Testing when triggered in the saveinterceptor and it returns false also.

 

Please answer everything, not just this last post.

 

We have some audit code that tracks who edited what. When an entity is touched (add, edit, delete) it uses...or was trying to use...the Principal of the EntityManager to attached these actions to the user in question.

 

Once we improved our security so every action must be truely logged in this no longer works. It works fine when edits are triggered from the client, but from the server, as in the saveinterceptor, Principal is null so though I can confirm( kinda) that the EntityManager is logged in (has a session key) I can't rely on the Principal existing. If I create an entity in the saveinterceptor when the audit code checks entity.EntityAspect.EntityManager.Principal it cries profusely. This code doesn't know its triggered in a saveinterceptor and has no access to the this.Principal. This would work if the Principal wasn't null.

 

In the previous thread it was mentioned that populating the Principal should be possible...where did that end up?

 

Also, if you create a new EntityManager and pass in the EntityManager from the save interceptor to link it...it does nothing. Any reason this couldn't be made to work too?

 

Am I beating a red-headed step child (SaveInterceptor)? I have considered moving this around but thats not a quick fix.

What can I use to test that an EntityManager is logged in? Its not the IsLoggedIn, its not the Principal. Maybe SessionKey? What can I use that will work 100% of the time and not depend on what EntityManager is handling the Entity?

 

Also this goes back to a thread I started a while ago about the Principal being null on the EntityManager. Its causing me big headaches right now. I am assuming an EntityManager will be logged in and I need to use the Principal for context of the update - or I have to figure a different way to pass around who is logged in which seems I shouldn't have to do since the EntityManager is handling logging me in and in most cases has the Principal and in some cases the IsLoggedIn is accurate.