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 Mon, 16 Apr 2012 23:29:02 GMT
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