Re: Core services design patern
Re: Core services design patern
- Subject: Re: Core services design patern
- From: Xavier Destombes <email@hidden>
- Date: Fri, 29 Jan 2010 13:23:39 +0100
Thanks Mike and Chuck you are right about the LDAP stuff.
I didn't consider it before as I was thinking about "permanent
connection" to the LDAP, but I clearly don't need a permanent
connection so it is no more an issue.
Going deeper into this, would you extend the ldap schema with your own
parameters or would you do that inside the wo app instead?
To illustrate this, assuming I have some preferences attached to the
user for the various web apps, I could store it either inside an ladp
custom key or put it in the core web app.
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?
Xavier
I have a person entity that I use as a base class in all our apps.
We auth against Kerberos (gssapi) and sync user info at login from
ldap (open dir) into the person eo.
Sent from my iPhone
On Jan 28, 2010, at 5:43 PM, "Chuck Hill"<email@hidden>
wrote:
On Jan 28, 2010, at 2:25 PM, Xavier Destombes wrote:
Hi list,
This isn't a bug:)
It's really sharing my point of view to see if I'm going in the
right direction.
I've got multiple web applications that share some common users.
I was thinking about creating a core user application to provide
the authentication service. Basically I'd like my "client"
applications to forward the login and password to this core user
app and get either "succeed" or "fail" (maybe a broader range of
fail messages).
I don't really need the entire user to be stored directly in the
"client" apps, but I would sometimes need some attributes from the
user object.
My though was:
-to create a framework to store an abstract class for the user
-to extend this class within the core user app (basically just
make them non-abstract)
-to use the abstract class in the client apps (and eventually make
only a couple attributes non-abstract at that level)
That way I could make sure my object is really the same throughout
the apps, at least they share a commun set of attributes.
A client app could request a login for a user and store only a
subset of the user.
Am I reinventing the wheel?
Probably. Have you considered Open/Active Directory and using that
to store and authenticate the users?
Is it a good direction?
Hard to say so far.
Is there a better way?
LDAP, maybe.
Am I going crazy:)
Probably. :-P
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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
_______________________________________________
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