Hi Shane, thanks in advance. If you want to take a look at this, the app is available
under
https://github.com/picketlink/TODO
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 30, 2013 at 12:21 AM, Shane Bryzak wrote:
Can you confirm that it's actually logging in with the new
credentials,
or merely just returning a "successful" result while leaving the state
of the currently logged in user unchanged?
On 30/01/13 12:08, Douglas Campos wrote:
> On Tue, Jan 29, 2013 at 05:19:23PM -0600, Anil Saldhana wrote:
> > Shane,
> > this is not a bug rather a feature request.
>
>
> it's a bug
> > Aerogear has the following sequence:
> >
> > credential.setCredential(x);
> > identity.login();
> > credential.setCredential(y);
> > identity.login();
> >
> > Aerogear wants PicketLink to reauthenticate during the second login()
> > call. Currently
> > it will not because the first login() established a User instance and
> > subsequent login()
> > calls will just bypass the auth process.
>
>
> If my API doesn't do the login process on the login() call, am I not
> failing with the "least surprise principle"? If it doesn't do all the
> login procedure when called, better rename it then: mayLogin(),
> loginWithCaching() or anything like this.
>
> IMO, this is not only wrong, but I think it can be used as a potential
> attack vector.
>
> -- qmx
> _______________________________________________
> security-dev mailing list
> security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org)
>
https://lists.jboss.org/mailman/listinfo/security-dev
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/security-dev