Re: Core services design patern
Re: Core services design patern
- Subject: Re: Core services design patern
- From: Mike Schrag <email@hidden>
- Date: Fri, 29 Jan 2010 07:44:02 -0500
> Mike, I'd like to know more about your "sync user info at login", do you store a subset of the user info directly inside your app? I mean you've got also the user (a part of it) in the datastore of your app, you're not using some sort of GUID from the LDAP for the relationships of objects inside your app. Am I understanding correctly?
Yes, I store an "externalID" that represents the source of the user, so a user that originally came from ldap might be "LDAP/mschrag" externalID, where the mschrag would be the id of the user from ldap (or whatever makes sense for your app). And yes, we store a subset of the ldap user info in the EO. We typically pull the obvious things -- first name, last name, username, phone number, email address, etc. After attempting a lot of different approaches with this stuff, i've found that things are much easier if you have a real EO representing the user in your own system. User IDs are used EVERYWHERE -- it's nice to have referential integrity, even if that means you have to deal with sync issues. We typically to "lazy sync," which is that we only update a user when they attempt to login (including if they are no longer allowed to login or if they were deleted). We also sync ldap groups and use those for authorization, so we set a property that defines what the "admin" ldap group id is, and if the user is a member of that group during sync, they are an admin in the app. In our tasking system, for instance, we have ldap groups for admins, employees, and contractors, and depending on your ldap group, you get assigned to different roles in the system.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden