deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: Login module
Date Tue, 17 Apr 2012 19:59:32 GMT
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 <bruno@abstractj.org>

> 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 <
> gerhard.petracek@gmail.com> 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 <bruno@abstractj.com>
> >
> > > 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 <lightguard.jp@gmail.com
> > > >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 <bruno@abstractj.org>
> > > 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message