DevForce 2010: Losing Principal

Losing Principal

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=2479
Printed Date: 13-May-2026 at 10:48am

Topic: Losing Principal

Posted By: midnit
Subject: Losing Principal
Date Posted: 01-Feb-2011 at 7:30am

We have a very simple loginmanager that does indeed return a userbase with a genericidentity that does have a name and isauthenticated...but our EntityManager.Principal.Name = null and IsAuthenticated is always false, IsLoggedIn=true.

Then, in our EntityServerSaveInterceptor the credentials are always null which is causing us to not know who is saving.

Any idea's?

6.0.7

Also, how can I avoid having to log in every EntityManager I create? Both server and client side. As I create entitymanagers they each must login. This is made worse by the above problem because its attempting to log in for every command. If I create an entitymanager on the server (in interceptor) that one must log in also. I am fine with this...but it doesn't know who it is.

Replies:

Posted By: DenisK
Date Posted: 02-Feb-2011 at 12:04am

Hi midnit;

1. I was not able to repro this. Could you post a code snippet on how you implement your LoginManager as well as your EntityManager.Login call if you do it explicitly?

2. You should be able to refer to the credentials inside an EntityServerSaveInterceptor using this.Principal.Identity. Are you saying that this returns null?

3. Every new sub type EntityManager created will need to login once, either implicitly or explicitly, before it can perform a query to the BOS. This is by design. The base type EntityManager on the server does not require this. It is already logged in by default. The server's EntityManager can be referred by calling this.EntityManager.

4. Any EM should not attempt to login for every query. Could you post a code snippet or a repro for this as well?

Posted By: midnit
Date Posted: 08-Feb-2011 at 8:19am

1. The login manager is cut up to try and debug this but is as follows:


#if !SILVERLIGHT
    public class SimpleLoginManager : IEntityLoginManager
    {
        #region IEntityLoginManager Members
        public IPrincipal Login(ILoginCredential credential, EntityManager entityManager)
        {
            //Work around for DEVART bug
            Devart.Data.Oracle.Entity.OracleEntityProviderServices.TypedNulls = true;
            //TransactionSettings.Default = new TransactionSettings(IsolationLevel.ReadCommitted, new TimeSpan(0, 1, 0), false);
            if (credential == null)
            {
                if (string.IsNullOrEmpty(AppIdentity.UserId))
                {
                    Logging.Log("LOGIN ERROR: Credential null, AppIdentity.UserId null.");
                    AppIdentity.UserId = "SYSTEM";
                }
                credential = new LoginCredential(AppIdentity.UserId, null, null);
            }
            else
            {
                if (string.IsNullOrEmpty(credential.UserName))
                {
                    credential.UserName = "SYSTEM";
                }
                if (string.IsNullOrEmpty(AppIdentity.UserId)) AppIdentity.UserId = credential.UserName;
            }
            //AppIdentity.UserId = credential.UserName;
            return new UserBase(new GenericIdentity(credential.UserName), null);
        }

2. yes if I reference the EntityManager in the saveinterceptor I am getting a null on the principal.

4. We are seeing this when we use Coroutine.StartParallel to query when the entitymanager has not finished logging in (but is has been called LoginAsync).

I have gotten our entity manager logged in now so I no longer see it hitting the loginmanager with every query. We are still not getting a principal in the saveinterceptor.

Posted By: DenisK
Date Posted: 08-Feb-2011 at 5:31pm

Hi midnit;

You don't reference the EntityManager in the save interceptor to get the principal. The principal is contained inside the EntityServerSaveInterceptor class.

public class CustomEntityServerSaveInterceptor : EntityServerSaveInterceptor {

protected override bool AuthorizeSave() {

var principal = this.Principal;

var identity = this.Principal.Identity;

var name = this.Principal.Identity.Name;

//This will return null

principal = this.EntityManager.Principal;

}

Posted By: gkneo
Date Posted: 14-Feb-2011 at 6:34am

Hi.

Why don't you just fill interceptor's EntityManager's Principal property with "this.Principal"? I have query/save interceptors and static server methods (with AlloRPC attribute) which call other static methods (in other library) and I have to pass the entity manager and the principal as arguments (as they do some logic with both classes). Is there a technical reason for not filling this property with the current principal?

Regards,

Guillermo

Posted By: midnit
Date Posted: 15-Feb-2011 at 9:35am

EntityManager.Principal being null is one part of my problem, we have code that runs fine on the client as it has a principal but when that code executes on the server and the principal is null...where is it supposed to get the principal from? Our SaveInterceptor does some manipulation before saving and in that sometimes it needs the current user. This was part of our models logic as we assumed the entity being worked with would always have access to the principal of the entitymanager it was in. I can change the code for multiple paths but, as asked by gkneo, is there a reason why the entitymanager.Principal is null?

Posted By: DenisK
Date Posted: 15-Feb-2011 at 12:00pm

Hi midnit;

The reason for why the EntityManager.Principal is null is because that EntityManager is a base type EM and not the sub type EM that you normally use on the client. I have to check with our lead developer to find out whether we can add this as a feature request, i.e. passing the sub-type EM and getting access to the Principal using EntityManager.Principal.

Posted By: DenisK
Date Posted: 15-Feb-2011 at 1:04pm

Additional clarification:

My apologies for the slightly wrong information. The null EntityManager.Principal has nothing to do with it being a base-typed EM or a sub-typed EM, although the statement is still correct in regards to base-typed (server) vs sub-typed (client). We just did not implement it that way. After having a quick word with the lead developer, we found out that it is possible to implement this. I will add this as a feature request for a future release. As of now, I don't have any information which version this will come out but will post more as soon as I do.

Posted By: midnit
Date Posted: 08-Mar-2011 at 4:15am

Btw, thanks for the help.

Posted By: midnit
Date Posted: 11-Apr-2011 at 6:39pm

Originally posted by DenisK

Additional clarification:

Any info on when this will show up? I just had to work around it again so I thought I would ask :)

Posted By: DenisK
Date Posted: 13-Apr-2011 at 10:28am

Hi midnit;

Sorry but this is still not high priority right now. I just want to make sure that you still have a workaround?

Posted By: midnit
Date Posted: 14-Apr-2011 at 4:18am

Other than to be rid of a few extra lines of code I have no immediate need.

Posted By: DenisK
Date Posted: 14-Apr-2011 at 11:03am

Thanks for letting me know midnit. Again, as soon as there's an update, I'll post it here.

Posted By: gkneo
Date Posted: 13-Feb-2012 at 2:37am

Hi.

I upgraded my SL project to version 5 with devforce 6.1.5, and when I call and RPC method, the entity manager's Principal is null. I will have to change my static methods to pass the rpc's IPrincipal parameter.

Why did u change that? As you see, a way long before I asked you to include the principal of the Save interceptor into the the entity manager (the rpcs methods did so) . Now i am asking you to do the same for both rpc methods and save interceptor: to fill the entitymanager's Principal property.

Regards,

Guillermo

Posted By: DenisK
Date Posted: 13-Feb-2012 at 12:04pm

Hi Guillermo,

Re: RPC's EntityManager.Principal - I'll file a bug report for this. Thanks for pointing it out.

Re: Interceptor's EntityManager.Principal - This design is currently being reviewed and is put on high priority.