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:35:30 +0100
Hello Cheong,
Portability isn't a requirement for us, we just need to ensure we're
using "standard" like if we use an Open Directory it's not a big deal,
we will eventually only have to redo our read/write method to the
ldap, but the attributes will be correct.
We also have more and more related services, some come directly from
OS X Server and some from our apps so being tied to the OS isn't an
issue.
What you explained also tells me I won't have to deal with security
that much if I "forward" this to the ldap;)
I'll probably have to dig a little bit more on this to understand how
security will be handled for exemple in the following case:
-someone trying to log to another user: if the ldap banish it for like
15mn after the 3rd attempt, I have to make sure the ldap get the
correct originated IP and not the one from the core web app
I've got quite a bunch of things to clarify before actually do it...
Thanks for your inputs,
Xavier
Coincidentally, I have completed a small framework on this same
request from customer. It is a pure java framework since it is
aimed to be portable to any application e.g. Broadvision, WO. Quite
similar that it creates new user password, authenticates user/
password and returned error messages. It also has the user
capabilities on the access module level. I used "Sha-1", and I
thought it should be good enough for hash algo. Is it secured
enough? Otherwise, I could change to DES/3DES/ MD4/5 etc.
Just 2c.
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.
_______________________________________________
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