Actually, I do not see a problem in customizing the behavior of
repeated login() method calls:
something like:
identity.setOption(Option.LOGIN_REPEAT);
credential.setCredential(x);
identity.login();
credential.setCredential(y);
identity.login();
If the option is set, then the second call of login() will authenticate
again.
By default, we want to maintain the session behavior. But if Aerogear
wants repeated login() logic, they should be able to set it in the option?
Feedback?
On 01/30/2013 11:47 AM, Bruno Oliveira wrote:
I still don't agree with it, we're giving the benefit of the
doubt to developers. If I have a method which is invoked twice for example via HTTP
request with the following code:
>> > >credential.setCredential(x);
>> > >identity.login();
> >
Login should be validate it again, but if you think that is not a problem, I'm fine.
Anil, could you please provide the final solution for it? Examples of usage?
-- "The measure of a man is what he does with power" - Plato -
@abstractj - Volenti Nihil Difficile On Wednesday, January 30, 2013 at
1:40 PM, Anil Saldhana wrote:
> >On 01/30/2013 09:33 AM, Bruno Oliveira wrote:
>> > >So if I'm a bank where the user account is logged in, this user has
just forgot to 'logout'. Another person using his computer can just bypass the
login, because the session still exists? Banks get over this by frequently being proactive
using Javascript. If the user has been idle for a minute, they give out a warning and if
there is no response, they log out the user.
> >
> >
>> > >Another scenario, I'm at the same network of John, running my
whatever-sniffer, then is just a matter of grab the current session ID and login? Am I
wrong? Because If understood correctly, after user login, even if I invoke this method for
a second time, what really matters is the session ID. https/ssl should be mandatory for
all critical web applications. Just have a HTTP Header agent installed for your browser.
Your passwords are in the clear in the http header agent if you do not use https.
> >
>> > >I'm confused.
>> > >-- "The measure of a man is what he does with power" - Plato -
@abstractj - Volenti Nihil Difficile On Wednesday, January 30, 2013 at 1:17 PM, Anil
Saldhana wrote:
>> > >
>>>> > > > >On 01/29/2013 08:08 PM, 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.
>>> > > >
>>>>>> > > > > > >Your usage: > > User user =
null; > AuthenticationResult result = identity.login(); > if(result ==
AuthenticationResult.SUCCESS){ > user = identity.getUser(); > } else { > throw
new RuntimeException("Authentication Failed"); > } > > //Now identity
has an user > //Irrespective of what you want to put in credential, you are >
authenticated already until you logout > result = identity.login(); > //result is
always SUCCESS. >
>>>>>>>> > > > > > > > >IMO, this is not
only wrong, but I think it can be used as a potential > > attack vector.
>>>>>>> > > > > > > >
>>>>>> > > > > > >
>>>>> > > > > >
>>>> > > > >
>>> > > >
>>> > > >
>>>>>> > > > > > >How?
>>>>>>>> > > > > > > > >-- qmx
>>>>>>> > > > > > > >
>>>>>> > > > > > >
>>>>> > > > > >
>>>> > > > >
>>> > > >
>>> > > >
>>>> > > > >_______________________________________________ >
security-dev mailing list >security-dev(a)lists.jboss.org
(mailto:security-dev@lists.jboss.org) (mailto:security-dev@lists.jboss.org)
>https://lists.jboss.org/mailman/listinfo/security-dev
>>>>