Re: Core services design patern
Re: Core services design patern
- Subject: Re: Core services design patern
- From: "Cheong Hee (Gmail)" <email@hidden>
- Date: Mon, 1 Feb 2010 13:20:29 +0800
Thanks! Do you think secured email S/MIME should follow the same too, e.g.
sha256+rsa? I have this email signing module that is using sha1rsa as
combination. The concern is some platforms are still not SHA-2 ready yet.
Cheers
Cheong Hee
----- Original Message -----
From: "Joe Little" <email@hidden>
To: "Cheong Hee (Gmail)" <email@hidden>
Cc: "WebObjects-Dev Mailing List List" <email@hidden>
Sent: Sunday, January 31, 2010 1:00 AM
Subject: Re: Core services design patern
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