hi bruno, i updated the wiki -> it's easier to see the open topics of part #1 (the next step is to suggest and discuss a concrete api/spi for those topics).
regards, gerhard 2012/4/17 Bruno Oliveira <[email protected]> > Thanks Gerhard, I got it. Is there something that I can do to help with > phase #2 & #4? Jira, pull request...patches to be evaluated? > > On Mon, Apr 16, 2012 at 8:29 PM, Gerhard Petracek < > [email protected]> wrote: > > > 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 > > > > > >
