Re: Core services design patern
Re: Core services design patern
- Subject: Re: Core services design patern
- From: Joe Little <email@hidden>
- Date: Sat, 30 Jan 2010 09:00:23 -0800
FYI, SHA-1 is broken. Need to use a SHA-2 variety, such as SHA-256.
Just need to store 56-byte Strings and use "SHA-256" in the digest
instantiation.
On Thu, Jan 28, 2010 at 9:19 PM, Cheong Hee (Gmail) <email@hidden> wrote:
> 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