6:59 a.m.
Hi,
when looking into HTTP Basic/Digest for iOS, Christos noticed a problem
with that, on the Controller demo (using AG-Security).
I have checked his issues and they are "visible" in cURL "environment"
as
well.
Steps to reproduce
- Clone the AG-Controller
demo<https://github.com/aerogear/aerogear-controller-demo>
- Update the web.xml to use the BASIC Filter
(here<https://github.com/aerogear/aerogear-controller-demo/blob/master/...
and
here<https://github.com/aerogear/aerogear-controller-demo/blob/master/...
).
- Make *SURE* that the Digiest section is commented out :-)
- Deploy the WAR to your JBoss Application Server
Now some tests with BASIC (and the default user john:123):
curl -u "john:123"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
This works, as expected!
curl -u "john:007"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
This does *NOT* work, as expected!
<https://gist.github.com/matzew/6111c42ff5d73f18097e#cookies->Cookies ?
Christos and I noticed the server does return the Set-Cookie: response
header, so the cookie can/will be stored on the client.
Now let's do this:
curl --basic -b cookies.txt -c cookies.txt -u john:123 \
"http://localhost:8080/aerogear-controller-demo/autobots" -v
Perfect, works as well
But now, let's do this:
curl --basic -b cookies.txt -c cookies.txt -u john:007 \
"http://localhost:8080/aerogear-controller-demo/autobots" -v
Unfortunatley, this works as well, since the session is reused, due to the
cookies... So, when the session is stored on the client, it is possible to
switch the credentials "on the fly".
<https://gist.github.com/matzew/6111c42ff5d73f18097e#question--comments>...
/ Comments
-
Not really sure, but for Basic/Digest should the server really send
Set-Cookie: response header back to the client ?
-
Not sure this is something on the controller, AG-Security or even
PicketLink, but perhaps theSet-Cookie: could be removed, when sending
the response for Basic/Digest
Ant thoughts on this ?
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
7:04 a.m.
Isn't this how Basic auth works? Once you log in you get a cookie and you don't
have to authenticate anymore until that cooke expires (usually at the end of a session).
This is my experience in browsers at least and is how I would expect it to work. If I have
a valid cookie, I should not have to log in again.
On Jun 20, 2013, at 6:59 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Hi,
when looking into HTTP Basic/Digest for iOS, Christos noticed a problem with that, on the
Controller demo (using AG-Security).
I have checked his issues and they are "visible" in cURL
"environment" as well.
Steps to reproduce
Clone the AG-Controller demo
Update the web.xml to use the BASIC Filter (here and here).
Make SURE that the Digiest section is commented out :-)
Deploy the WAR to your JBoss Application Server
Now some tests with BASIC (and the default user john:123):
curl -u "john:123"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
This works, as expected!
curl -u "john:007"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
This does NOT work, as expected!
Cookies ?
Christos and I noticed the server does return the Set-Cookie: response header, so the
cookie can/will be stored on the client.
Now let's do this:
curl --basic -b cookies.txt -c cookies.txt -u john:123 \
"http://localhost:8080/aerogear-controller-demo/autobots" -v
Perfect, works as well
But now, let's do this:
curl --basic -b cookies.txt -c cookies.txt -u john:007 \
"http://localhost:8080/aerogear-controller-demo/autobots" -v
Unfortunatley, this works as well, since the session is reused, due to the cookies... So,
when the session is stored on the client, it is possible to switch the credentials
"on the fly".
Question / Comments
Not really sure, but for Basic/Digest should the server really send Set-Cookie: response
header back to the client ?
Not sure this is something on the controller, AG-Security or even PicketLink, but perhaps
theSet-Cookie: could be removed, when sending the response for Basic/Digest
Ant thoughts on this ?
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
7:15 a.m.
I have tried an internal service, tried the similar like about (with
basic/curl)
curl -k --basic -b cookies.txt -c cookies.txt -u goodUser:goodPasswd "
https://something.redhat.com" -v
==> I get the protected page
curl -k --basic -b cookies.txt -c cookies.txt -u badUser:badPasswd "
https://something.redhat.com" -v
==> I am NOT getting the protected page :)
Not sure, but I do like the fact that the second curl is not successful :-)
On Thu, Jun 20, 2013 at 2:04 PM, Kris Borchers <kris(a)redhat.com> wrote:
Isn't this how Basic auth works? Once you log in you get a cookie
and you
don't have to authenticate anymore until that cooke expires (usually at the
end of a session). This is my experience in browsers at least and is how I
would expect it to work. If I have a valid cookie, I should not have to log
in again.
On Jun 20, 2013, at 6:59 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
Hi,
when looking into HTTP Basic/Digest for iOS, Christos noticed a problem
with that, on the Controller demo (using AG-Security).
I have checked his issues and they are "visible" in cURL
"environment" as
well.
Steps to reproduce
- Clone the AG-Controller
demo<https://github.com/aerogear/aerogear-controller-demo>
- Update the web.xml to use the BASIC Filter
(here<https://github.com/aerogear/aerogear-controller-demo/blob/master/...
and
here<https://github.com/aerogear/aerogear-controller-demo/blob/master/...
).
- Make *SURE* that the Digiest section is commented out :-)
- Deploy the WAR to your JBoss Application Server
Now some tests with BASIC (and the default user john:123):
curl -u "john:123"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
This works, as expected!
curl -u "john:007"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
This does *NOT* work, as expected!
<https://gist.github.com/matzew/6111c42ff5d73f18097e#cookies->Cookies ?
Christos and I noticed the server does return the Set-Cookie: response
header, so the cookie can/will be stored on the client.
Now let's do this:
curl --basic -b cookies.txt -c cookies.txt -u john:123 \
"http://localhost:8080/aerogear-controller-demo/autobots" -v
Perfect, works as well
But now, let's do this:
curl --basic -b cookies.txt -c cookies.txt -u john:007 \
"http://localhost:8080/aerogear-controller-demo/autobots" -v
Unfortunatley, this works as well, since the session is reused, due to the
cookies... So, when the session is stored on the client, it is possible to
switch the credentials "on the fly".
<https://gist.github.com/matzew/6111c42ff5d73f18097e#question--comments>...
/ Comments
-
Not really sure, but for Basic/Digest should the server really send
Set-Cookie: response header back to the client ?
-
Not sure this is something on the controller, AG-Security or even
PicketLink, but perhaps theSet-Cookie: could be removed, when sending
the response for Basic/Digest
Ant thoughts on this ?
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
7:28 a.m.
I can agree that sending incorrect credentials should not work. You shouldn't be
sending credentials again if you have a valid cookie but if you do and they are wrong, I
agree that you should not be authenticated. The question then is, should the cookie be
invalidated or if I try again with the cookie but without credentials, should it work. I
would probably lean toward invalidating the cookie and forcing the auth process to start
over, I think.
On Jun 20, 2013, at 7:15 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
I have tried an internal service, tried the similar like about (with
basic/curl)
curl -k --basic -b cookies.txt -c cookies.txt -u goodUser:goodPasswd
"https://something.redhat.com" -v
==> I get the protected page
curl -k --basic -b cookies.txt -c cookies.txt -u badUser:badPasswd
"https://something.redhat.com" -v
==> I am NOT getting the protected page :)
Not sure, but I do like the fact that the second curl is not successful :-)
On Thu, Jun 20, 2013 at 2:04 PM, Kris Borchers <kris(a)redhat.com> wrote:
Isn't this how Basic auth works? Once you log in you get a cookie and you don't
have to authenticate anymore until that cooke expires (usually at the end of a session).
This is my experience in browsers at least and is how I would expect it to work. If I have
a valid cookie, I should not have to log in again.
On Jun 20, 2013, at 6:59 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> Hi,
>
> when looking into HTTP Basic/Digest for iOS, Christos noticed a problem with that, on
the Controller demo (using AG-Security).
>
> I have checked his issues and they are "visible" in cURL
"environment" as well.
>
> Steps to reproduce
>
> Clone the AG-Controller demo
> Update the web.xml to use the BASIC Filter (here and here).
> Make SURE that the Digiest section is commented out :-)
> Deploy the WAR to your JBoss Application Server
> Now some tests with BASIC (and the default user john:123):
>
> curl -u "john:123"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
> This works, as expected!
>
> curl -u "john:007"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
> This does NOT work, as expected!
>
> Cookies ?
>
> Christos and I noticed the server does return the Set-Cookie: response header, so the
cookie can/will be stored on the client.
>
> Now let's do this:
>
> curl --basic -b cookies.txt -c cookies.txt -u john:123 \
> "http://localhost:8080/aerogear-controller-demo/autobots" -v
> Perfect, works as well
>
> But now, let's do this:
>
> curl --basic -b cookies.txt -c cookies.txt -u john:007 \
> "http://localhost:8080/aerogear-controller-demo/autobots" -v
> Unfortunatley, this works as well, since the session is reused, due to the cookies...
So, when the session is stored on the client, it is possible to switch the credentials
"on the fly".
>
> Question / Comments
>
> Not really sure, but for Basic/Digest should the server really send Set-Cookie:
response header back to the client ?
>
> Not sure this is something on the controller, AG-Security or even PicketLink, but
perhaps theSet-Cookie: could be removed, when sending the response for Basic/Digest
>
> Ant thoughts on this ?
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
7:31 a.m.
On Thu, Jun 20, 2013 at 2:28 PM, Kris Borchers <kris(a)redhat.com> wrote:
I can agree that sending incorrect credentials should not work. You
shouldn't be sending credentials again if you have a valid cookie but if
you do and they are wrong, I agree that you should not be authenticated.
The question then is, should the cookie be invalidated or if I try again
with the cookie but without credentials, should it work. I would probably
lean toward invalidating the cookie and forcing the auth process to start
over, I think.
yep, I am with out there :)
On Jun 20, 2013, at 7:15 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
I have tried an internal service, tried the similar like about (with
basic/curl)
curl -k --basic -b cookies.txt -c cookies.txt -u goodUser:goodPasswd "
https://something.redhat.com" -v
==> I get the protected page
curl -k --basic -b cookies.txt -c cookies.txt -u badUser:badPasswd "
https://something.redhat.com" -v
==> I am NOT getting the protected page :)
Not sure, but I do like the fact that the second curl is not successful :-)
On Thu, Jun 20, 2013 at 2:04 PM, Kris Borchers <kris(a)redhat.com> wrote:
> Isn't this how Basic auth works? Once you log in you get a cookie and you
> don't have to authenticate anymore until that cooke expires (usually at the
> end of a session). This is my experience in browsers at least and is how I
> would expect it to work. If I have a valid cookie, I should not have to log
> in again.
>
> On Jun 20, 2013, at 6:59 AM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
> Hi,
>
> when looking into HTTP Basic/Digest for iOS, Christos noticed a problem
> with that, on the Controller demo (using AG-Security).
>
> I have checked his issues and they are "visible" in cURL
"environment" as
> well.
>
> Steps to reproduce
>
> - Clone the AG-Controller
demo<https://github.com/aerogear/aerogear-controller-demo>
> - Update the web.xml to use the BASIC Filter
(here<https://github.com/aerogear/aerogear-controller-demo/blob/master/...
> and
here<https://github.com/aerogear/aerogear-controller-demo/blob/master/...
> ).
> - Make *SURE* that the Digiest section is commented out :-)
> - Deploy the WAR to your JBoss Application Server
>
> Now some tests with BASIC (and the default user john:123):
>
> curl -u "john:123"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
>
> This works, as expected!
>
> curl -u "john:007"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
>
> This does *NOT* work, as expected!
> <https://gist.github.com/matzew/6111c42ff5d73f18097e#cookies->Cookies ?
>
> Christos and I noticed the server does return the Set-Cookie: response
> header, so the cookie can/will be stored on the client.
>
> Now let's do this:
>
> curl --basic -b cookies.txt -c cookies.txt -u john:123 \
> "http://localhost:8080/aerogear-controller-demo/autobots" -v
>
> Perfect, works as well
>
> But now, let's do this:
>
> curl --basic -b cookies.txt -c cookies.txt -u john:007 \
> "http://localhost:8080/aerogear-controller-demo/autobots" -v
>
> Unfortunatley, this works as well, since the session is reused, due to
> the cookies... So, when the session is stored on the client, it is possible
> to switch the credentials "on the fly".
>
<https://gist.github.com/matzew/6111c42ff5d73f18097e#question--comments>...
> / Comments
>
> -
>
> Not really sure, but for Basic/Digest should the server really send
> Set-Cookie: response header back to the client ?
> -
>
> Not sure this is something on the controller, AG-Security or even
> PicketLink, but perhaps theSet-Cookie: could be removed, when sending
> the response for Basic/Digest
>
> Ant thoughts on this ?
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10:03 a.m.
I have to reproduce the issue here. Set-Cookie doesn't belong to AGSec
or Controller.
Matthias Wessendorf wrote:
On Thu, Jun 20, 2013 at 2:28 PM, Kris Borchers <kris(a)redhat.com
<mailto:kris@redhat.com>> wrote:
I can agree that sending incorrect credentials should not work. You
shouldn't be sending credentials again if you have a valid cookie
but if you do and they are wrong, I agree that you should not be
authenticated. The question then is, should the cookie be
invalidated or if I try again with the cookie but without
credentials, should it work. I would probably lean toward
invalidating the cookie and forcing the auth process to start over,
I think.
yep, I am with out there :)
On Jun 20, 2013, at 7:15 AM, Matthias Wessendorf <matzew(a)apache.org
<mailto:matzew@apache.org>> wrote:
> I have tried an internal service, tried the similar like about
> (with basic/curl)
>
> curl -k --basic -b cookies.txt -c cookies.txt -u
> goodUser:goodPasswd "https://something.redhat.com
> <https://something.redhat.com/>" -v
>
> ==> I get the protected page
>
>
> curl -k --basic -b cookies.txt -c cookies.txt -u badUser:badPasswd
> "https://something.redhat.com <https://something.redhat.com/>"
-v
>
> ==> I am NOT getting the protected page :)
>
>
> Not sure, but I do like the fact that the second curl is not
> successful :-)
>
>
>
>
>
> On Thu, Jun 20, 2013 at 2:04 PM, Kris Borchers <kris(a)redhat.com
> <mailto:kris@redhat.com>> wrote:
>
> Isn't this how Basic auth works? Once you log in you get a
> cookie and you don't have to authenticate anymore until that
> cooke expires (usually at the end of a session). This is my
> experience in browsers at least and is how I would expect it
> to work. If I have a valid cookie, I should not have to log in
> again.
>
> On Jun 20, 2013, at 6:59 AM, Matthias Wessendorf
> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>
>> Hi,
>>
>> when looking into HTTP Basic/Digest for iOS, Christos noticed
>> a problem with that, on the Controller demo (using AG-Security).
>>
>> I have checked his issues and they are "visible" in cURL
>> "environment" as well.
>>
>> Steps to reproduce
>>
>> * Clone the AG-Controller demo
>> <https://github.com/aerogear/aerogear-controller-demo>
>> * Update the |web.xml| to use the BASIC Filter (here
>>
<https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main...
and
>> here
>>
<https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main...>).
>> * Make /*SURE*/ that the Digiest section is commented out :-)
>> * Deploy the |WAR| to your JBoss Application Server
>>
>> Now some tests with BASIC (and the default user |john:123|):
>>
>> |curl -u"john:123"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
>> |
>>
>> This works, as expected!
>>
>> |curl -u"john:007"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
>> |
>>
>> This does /*NOT*/ work, as expected!
>>
>>
>>
<https://gist.github.com/matzew/6111c42ff5d73f18097e#cookies->Cookies
>> ?
>>
>> Christos and I noticed the server does return the
>> |Set-Cookie:| response header, so the cookie can/will be
>> stored on the client.
>>
>> Now let's do this:
>>
>> |curl --basic -b cookies.txt -c cookies.txt -u john:123 \
>> "http://localhost:8080/aerogear-controller-demo/autobots" -v
>> |
>>
>> Perfect, works as well
>>
>> But now, let's do this:
>>
>> |curl --basic -b cookies.txt -c cookies.txt -u john:007 \
>> "http://localhost:8080/aerogear-controller-demo/autobots" -v
>> |
>>
>> Unfortunatley, this works as well, since the session is
>> reused, due to the cookies... So, when the session is stored
>> on the client, it is possible to switch the credentials "on
>> the fly".
>>
>>
>>
<https://gist.github.com/matzew/6111c42ff5d73f18097e#question--comments>...
>> / Comments
>>
>> *
>>
>> Not really sure, but for Basic/Digest should the server
>> really send |Set-Cookie:| response header back to the
>> client ?
>>
>> *
>>
>> Not sure this is something on the controller, AG-Security
>> or even PicketLink, but perhaps the|Set-Cookie:| could be
>> removed, when sending the response for Basic/Digest
>>
>> Ant thoughts on this ?
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> <mailto:aerogear-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
11:09 a.m.
On 06/20/2013 08:28 AM, Kris Borchers wrote:
I can agree that sending incorrect credentials should not work. You
shouldn't be sending credentials again if you have a valid cookie but
if you do and they are wrong, I agree that you should not be
authenticated. The question then is, should the cookie be invalidated
or if I try again with the cookie but without credentials, should it
work. I would probably lean toward invalidating the cookie and forcing
the auth process to start over, I think.
That makes the most sense. HTTP Basic
doesn't require a cookie so
whatever we do here is rather arbitrary...
On Jun 20, 2013, at 7:15 AM, Matthias Wessendorf <matzew(a)apache.org
<mailto:matzew@apache.org>> wrote:
> I have tried an internal service, tried the similar like about (with
> basic/curl)
>
> curl -k --basic -b cookies.txt -c cookies.txt -u goodUser:goodPasswd
> "https://something.redhat.com <https://something.redhat.com/>" -v
>
> ==> I get the protected page
>
>
> curl -k --basic -b cookies.txt -c cookies.txt -u badUser:badPasswd
> "https://something.redhat.com <https://something.redhat.com/>" -v
>
> ==> I am NOT getting the protected page :)
>
>
> Not sure, but I do like the fact that the second curl is not
> successful :-)
>
>
>
>
>
> On Thu, Jun 20, 2013 at 2:04 PM, Kris Borchers <kris(a)redhat.com
> <mailto:kris@redhat.com>> wrote:
>
> Isn't this how Basic auth works? Once you log in you get a cookie
> and you don't have to authenticate anymore until that cooke
> expires (usually at the end of a session). This is my experience
> in browsers at least and is how I would expect it to work. If I
> have a valid cookie, I should not have to log in again.
>
> On Jun 20, 2013, at 6:59 AM, Matthias Wessendorf
> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>
>> Hi,
>>
>> when looking into HTTP Basic/Digest for iOS, Christos noticed a
>> problem with that, on the Controller demo (using AG-Security).
>>
>> I have checked his issues and they are "visible" in cURL
>> "environment" as well.
>>
>> Steps to reproduce
>>
>> * Clone the AG-Controller demo
>> <https://github.com/aerogear/aerogear-controller-demo>
>> * Update the |web.xml| to use the BASIC Filter (here
>>
<https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main...
and
>> here
>>
<https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main...>).
>> * Make /*SURE*/ that the Digiest section is commented out :-)
>> * Deploy the |WAR| to your JBoss Application Server
>>
>> Now some tests with BASIC (and the default user |john:123|):
>>
>> |curl -u "john:123"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
>> |
>>
>> This works, as expected!
>>
>> |curl -u "john:007"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
>> |
>>
>> This does /*NOT*/ work, as expected!
>>
>>
>>
<https://gist.github.com/matzew/6111c42ff5d73f18097e#cookies->Cookies
>> ?
>>
>> Christos and I noticed the server does return the
>> |Set-Cookie:| response header, so the cookie can/will be stored
>> on the client.
>>
>> Now let's do this:
>>
>> |curl --basic -b cookies.txt -c cookies.txt -u john:123 \
>> "http://localhost:8080/aerogear-controller-demo/autobots" -v
>> |
>>
>> Perfect, works as well
>>
>> But now, let's do this:
>>
>> |curl --basic -b cookies.txt -c cookies.txt -u john:007 \
>> "http://localhost:8080/aerogear-controller-demo/autobots" -v
>> |
>>
>> Unfortunatley, this works as well, since the session is reused,
>> due to the cookies... So, when the session is stored on the
>> client, it is possible to switch the credentials "on the fly".
>>
>>
>>
<https://gist.github.com/matzew/6111c42ff5d73f18097e#question--comments>...
>> / Comments
>>
>> *
>>
>> Not really sure, but for Basic/Digest should the server
>> really send |Set-Cookie:| response header back to the client ?
>>
>> *
>>
>> Not sure this is something on the controller, AG-Security or
>> even PicketLink, but perhaps the|Set-Cookie:| could be
>> removed, when sending the response for Basic/Digest
>>
>> Ant thoughts on this ?
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:31 a.m.
https://issues.jboss.org/browse/AGSEC-73 created.
Summers Pittman wrote:
On 06/20/2013 08:28 AM, Kris Borchers wrote:
> I can agree that sending incorrect credentials should not work. You
> shouldn't be sending credentials again if you have a valid cookie but
> if you do and they are wrong, I agree that you should not be
> authenticated. The question then is, should the cookie be invalidated
> or if I try again with the cookie but without credentials, should it
> work. I would probably lean toward invalidating the cookie and forcing
> the auth process to start over, I think.
That makes the most sense. HTTP Basic doesn't require a cookie so
whatever we do here is rather arbitrary...
>
> On Jun 20, 2013, at 7:15 AM, Matthias Wessendorf <matzew(a)apache.org
> <mailto:matzew@apache.org>> wrote:
>
>> I have tried an internal service, tried the similar like about (with
>> basic/curl)
>>
>> curl -k --basic -b cookies.txt -c cookies.txt -u goodUser:goodPasswd
>> "https://something.redhat.com <https://something.redhat.com/>"
-v
>>
>> ==> I get the protected page
>>
>>
>> curl -k --basic -b cookies.txt -c cookies.txt -u badUser:badPasswd
>> "https://something.redhat.com <https://something.redhat.com/>"
-v
>>
>> ==> I am NOT getting the protected page :)
>>
>>
>> Not sure, but I do like the fact that the second curl is not
>> successful :-)
>>
>>
>>
>>
>>
>> On Thu, Jun 20, 2013 at 2:04 PM, Kris Borchers <kris(a)redhat.com
>> <mailto:kris@redhat.com>> wrote:
>>
>> Isn't this how Basic auth works? Once you log in you get a cookie
>> and you don't have to authenticate anymore until that cooke
>> expires (usually at the end of a session). This is my experience
>> in browsers at least and is how I would expect it to work. If I
>> have a valid cookie, I should not have to log in again.
>>
>> On Jun 20, 2013, at 6:59 AM, Matthias Wessendorf
>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>>
>>> Hi,
>>>
>>> when looking into HTTP Basic/Digest for iOS, Christos noticed a
>>> problem with that, on the Controller demo (using AG-Security).
>>>
>>> I have checked his issues and they are "visible" in cURL
>>> "environment" as well.
>>>
>>> Steps to reproduce
>>>
>>> * Clone the AG-Controller demo
>>> <https://github.com/aerogear/aerogear-controller-demo>
>>> * Update the |web.xml| to use the BASIC Filter (here
>>>
<https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main...
>>> and here
>>>
<https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main...>).
>>> * Make /*SURE*/ that the Digiest section is commented out :-)
>>> * Deploy the |WAR| to your JBoss Application Server
>>>
>>> Now some tests with BASIC (and the default user |john:123|):
>>>
>>> |curl -u "john:123"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
>>> |
>>>
>>> This works, as expected!
>>>
>>> |curl -u "john:007"
"http://localhost:8080/aerogear-controller-demo/autobots" -v
>>> |
>>>
>>> This does /*NOT*/ work, as expected!
>>>
>>>
>>>
<https://gist.github.com/matzew/6111c42ff5d73f18097e#cookies->Cookies
>>> ?
>>>
>>> Christos and I noticed the server does return the |Set-Cookie:|
>>> response header, so the cookie can/will be stored on the client.
>>>
>>> Now let's do this:
>>>
>>> |curl --basic -b cookies.txt -c cookies.txt -u john:123 \
>>> "http://localhost:8080/aerogear-controller-demo/autobots" -v
>>> |
>>>
>>> Perfect, works as well
>>>
>>> But now, let's do this:
>>>
>>> |curl --basic -b cookies.txt -c cookies.txt -u john:007 \
>>> "http://localhost:8080/aerogear-controller-demo/autobots" -v
>>> |
>>>
>>> Unfortunatley, this works as well, since the session is reused,
>>> due to the cookies... So, when the session is stored on the
>>> client, it is possible to switch the credentials "on the fly".
>>>
>>>
>>>
<https://gist.github.com/matzew/6111c42ff5d73f18097e#question--comments>...
>>> / Comments
>>>
>>> *
>>>
>>> Not really sure, but for Basic/Digest should the server
>>> really send |Set-Cookie:| response header back to the client ?
>>>
>>> *
>>>
>>> Not sure this is something on the controller, AG-Security or
>>> even PicketLink, but perhaps the|Set-Cookie:| could be
>>> removed, when sending the response for Basic/Digest
>>>
>>> Ant thoughts on this ?
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
4207
days inactive
4207
days old
7 comments
4 participants
participants (4)
-
Bruno Oliveira -
Kris Borchers -
Matthias Wessendorf -
Summers Pittman