hi bruno, right now: it's just called "id", because it's the most generic term we found so far (we could change it e.g. to "key" - but that's just a different name). the id of the user is any information you need to look-up an user (in the current context) or at least to create an instance which can be stored side-by-side with other user-instances e.g. in a cache. it can be an external/internal uuid, e-mail address, user-name,... -> it can be anything.
you can even do an indirect look-up e.g. LoginCredential#setUserId receives any information you can use for a look-up of an (internal) key -> this information will be used for the final look-up to identify an user (-> in this case LoginCredential#getUserId would return a different (maybe internal) key). "Credential" is just the "pass-phrase" - again it can be anything. similar to the interface "Credential" we could create an interface "Key" (or "Id"), but for now (part #1), we don't need it. @ link: right now we just have to finish part #1 and do the rest step-by-step -> the current api isn't final at all. if you think that your use-case isn't covered by part #2-#4, you are very welcome to add it to the wiki. regards, gerhard 2012/4/17 Bruno Oliveira <[email protected]> > Hi Jason, was just a suggestion, but I would like to know opinions/concerns > to go ahead with it or not. Currently User doesn't have any abstractions > and only has ID, we can't guarantee that users will always have an ID. I > would like to create some minor abstraction to support another > authentication methods like seam-security does with OAuth. > > Gerhard about the link, I read this e-mail and the use cases too. For some > coincidence I was working on it. I would like to know if this make sense > and suggestions about how to improve it. > > Thanks. > > On Mon, Apr 16, 2012 at 6:36 PM, Jason Porter <[email protected] > >wrote: > > > I thought about posting comments on the commit, but this is probably more > > visible to the whole group. If we're going to call it a credential and go > > with the more common security names, shouldn't it be called a Principal > > then the authentication information would be the Credential? If we don't > > want to go down that way I understand. > > > > On Mon, Apr 16, 2012 at 15:26, Bruno Oliveira <[email protected]> > wrote: > > > > > Hi folks. > > > > > > I was just trying to figure out a flexible way to use DS authentication > > > module and did some refactoring into User and Credential stuff. Just > some > > > suggestions: > > > > > > 1- User class renaming to CredentialAuthInfo, because User has a little > > > bit of ambiguity, > > > 2- We can't guarantee that User will always have id, for this reason > only > > > username/password should be enough, allowing users to decorate your > > classes > > > with another authentication methods like OAuth > > > 3- LoginCredential should receive an object instead > > > of straight username/password > > > > > > These are just suggestions and I would like to pick some jira or create > > > the new one about it. > > > > > > > > > > > > https://github.com/abstractj/incubator-deltaspike/commit/0757366a7b129a053f34a3e0db426b48c73767be > > > > > > What do you think? > > > > > > -- > > > > > > -- > > > "Know the rules well, so you can break them effectively" - Dalai Lama > XIV > > > - > > > @abstractj > > > - > > > Volenti Nihil Difficile > > > > > > > > > > > -- > > Jason Porter > > http://lightguard-jp.blogspot.com > > http://twitter.com/lightguardjp > > > > Software Engineer > > Open Source Advocate > > Author of Seam Catch - Next Generation Java Exception Handling > > > > PGP key id: 926CCFF5 > > PGP key available at: keyserver.net, pgp.mit.edu > > > > > > -- > "Know the rules well, so you can break them effectively" - Dalai Lama XIV > - > @abstractj > - > Volenti Nihil Difficile >
