|
Login Principal |
Post Reply 
|
| Author |
 Share Topic Printable Version Delicious Digg Facebook Furl Google Boomarks Google Buzz MySpace Newsvine reddit StumbleUpon Translate Twitter Windows Live Yahoo Bookmarks Topic Search  Topic Options
|
kimj 
IdeaBlade 
Joined: 09-May-2007 Posts: 1391 |
 Post Options
 Quote Reply
 Topic: Login PrincipalPosted: 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? |
|
 |
|
|
smi-mark
DevForce MVP 
Joined: 24-Feb-2009 Location: Dallas, Texas Posts: 343 |
Post Options
Quote Reply
Posted: 24-Mar-2009 at 12:13pm |
|
Thanks Kim!
|
|
|
|
|
kimj
IdeaBlade
Joined: 09-May-2007 Posts: 1391 |
Post Options
Quote Reply
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.
|
|
|
|
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009 Location: Dallas, Texas Posts: 343 |
Post Options
Quote Reply
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 |
|
|
|
|
kimj
IdeaBlade
Joined: 09-May-2007 Posts: 1391 |
Post Options
Quote Reply
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.
|
|
|
|
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009 Location: Dallas, Texas Posts: 343 |
Post Options
Quote Reply
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 ?
|
|
|
|
|
kimj
IdeaBlade
Joined: 09-May-2007 Posts: 1391 |
Post Options
Quote Reply
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.
|
|
|
|
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009 Location: Dallas, Texas Posts: 343 |
Post Options
Quote Reply
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 |
|
|
|
|
kimj
IdeaBlade
Joined: 09-May-2007 Posts: 1391 |
Post Options
Quote Reply
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.
|
|
|
|
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009 Location: Dallas, Texas Posts: 343 |
Post Options
Quote Reply
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 |
|
|
|
|
Post Reply
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |