Print Page | Close Window

Login Principal

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2009
Forum Discription: For .NET 3.5
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1167
Printed Date: 22-Sep-2025 at 4:19pm


Topic: Login Principal
Posted By: smi-mark
Subject: Login Principal
Date Posted: 24-Mar-2009 at 9:11am
Hi,

We are having some problems with the LoginManager in EF, for some reason the Thread.CurrentPrincipal is being reset to a WindowsPrincipal instead of our custom principal in between the IEntityLoginManager.Login and the IDataSourceKeyResolver.GetKey call.

In the login function I set the Principal like so:
Thread.CurrentPrincipal = aUserPrincipal
debugging shows it has set correctly.

When it hits the DataSourceKeyResolver I get the principal using "Dim aPrincipal As IPrincipal = Thread.CurrentPrincipal" it now shows up as a windows principal/identity. Is there a reason why this is happening?

Thanks,

Mark


Replies:
Posted By: kimj
Date Posted: 24-Mar-2009 at 10:17am

On the client, when a Login() completes, DevForce will set the Thread.CurrentPrincipal to whatever was returned from the IEntityLoginManager.Login.  On the server, that same principal is used to set the Thread.CurrentPrincipal before a fetch or save.

Are you seeing the problem when the IDataSourceKeyResolver.GetKey is called on the client or on the server?  If on the server, presumably GetKey is called within the context of a fetch or save (I'd have to double check), but if not, maybe it's defaulted to the process current user.

 

Posted By: smi-mark
Date Posted: 24-Mar-2009 at 10:26am
Thanks for the quick response Kim. This is on the client. In my LoginManager I'm setting the principal manually but also returning the principal so that shouldn't cause any issues. It's somewhere in between from when Login is called and before GetKey. I have also checked the DebugLog and it is indeed resolving the correct IEntityLoginManager and IDataSourceKeyResolver interfaces. It seems like it is defaulting back to the default windows user even after the login call. Is there any more info I can get that might help?

Thanks,

mark

Posted By: kimj
Date Posted: 24-Mar-2009 at 10:35am
Is it a multi-threaded application?  The Login will set the principal on only the current thread, so any other threads, even ones where an EntityManager was created via the copy constructor, will not be touched by DevForce.  Also, when DevForce defaults the CurrentPrincipal after an implicit login, it's always a GenericPrincipal/GenericIdentity and never a WindowsPrincipal.
 
 

Posted By: smi-mark
Date Posted: 24-Mar-2009 at 10:52am
No, this is all being done in a single thread. Would using EntityManager.DefaultManager be causing any problems ? 

Posted By: kimj
Date Posted: 24-Mar-2009 at 11:04am
EntityManager.DefaultManager will point to the first EntityManager constructed, or construct a new one.  If the DefaultManager and the EntityManager you've logged in with are not the same, then I suppose it's possibly part of the problem.
 
Are you using a BOS?  Does your custom principal inherit from WindowsPrincipal?  There could be a serialization problem of this data back to the client, with the client receiving the base type instead of your custom type.

Posted By: smi-mark
Date Posted: 24-Mar-2009 at 11:40am
No, this is not using a BOS.

LoginManagerCredential Implements ILoginCredential and UserPrincipal implements IPrincipal. I have tried setting them both to Serializable and implementing IKnownType.

This is interesting though: ( I cut out some parts to improve readability)

username="Mark-Laptop\Mark" >Probed for 'IDataSourceKeyResolver' and found LoginManagerDataSourceKeyResolver
username="Mark-Laptop\Mark" Probed for 'IEntityLoginManager' and found LoginManager
username="sa">Logged in as sa, CurrentPrincipal Type: UserPrincipal
username="Mark-Laptop\Mark" source="DataSourceResolver:FindKey">Resolving key DEFAULT, On Server: False, CurrentPrincipal Type: WindowsPrincipal
username="sa" source="DataSourceResolver:FindKey">Resolving key DEFAULT, On Server: True, CurrentPrincipal Type: UserPrincipal
username="sa" source="DataSourceResolver:GetKeyRelatedInfo">Probed for 'IIdentityIdGenerator' and found StoreGeneratedIdGenerator

Posted By: kimj
Date Posted: 24-Mar-2009 at 11:47am
That is interesting.  I don't have an explanation for the credentials used in the "client-side" FindKey and will need to test it out to see what's going on.  I'll let you know.
 

Posted By: smi-mark
Date Posted: 24-Mar-2009 at 12:13pm
Thanks Kim!

Posted By: kimj
Date Posted: 24-Mar-2009 at 3:49pm

Mark, I can't reproduce this behavior using a simple WinForms or console application.  Is this an ASP.NET or Windows Service application?  Do you have multiple DataSourceKeyResolvers?  Is the LoginManager using (and logging in to) an EntityManager?


Print Page | Close Window