incubator-deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Oliveira <br...@abstractj.org>
Subject Re: Login module
Date Tue, 17 Apr 2012 13:59:09 GMT
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