Just thinking about the process here. Bruno has certain deliverables with dates that relate to security + CDI, and can help out with API design and implementation. Some of the stuff he needs to deliver is later in the the original plan. So I would suggest that we reorder the plan so that Deltaspike can take advantage of his expertise.
Bruno, can you outline what you need to pull forward to meet your goals? On 18 Apr 2012, at 01:29, Gerhard Petracek wrote: > 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 >>>> >>> >>
