You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Cory Johns <jo...@gmail.com> on 2013/12/10 21:01:58 UTC
REST API: Cookie auth?
We (somewhat) recently added bearer tokens to the REST API to make using
the API easier for developers, but I was wondering what the consensus was
regarding allowing auth via the normal browser cookie?
Like bearer tokens and the normal web session, it would require SSL. I
can't think of any issues with it, personally, since it would have the same
security as the normal browser session.
Same-origin policy ought to prevent data leakage on GET requests, and
requiring POST for action end-points ought to prevent any other
shenanigans. Is there anything else I'm missing? Any other reason not to
add the normal session cookie as an API auth option?
Re: REST API: Cookie auth?
Posted by Cory Johns <jo...@gmail.com>.
Ok, I added cookie auth as a fallback if no other auth mechanisms are
provided. It has been merged in with #6831
On Wed, Dec 11, 2013 at 3:36 PM, Tim Van Steenburgh <
tvansteenburgh@gmail.com> wrote:
> I'm +1 on adding cookie auth, with bearer token taking precedence if both
> are provided.
>
>
> On Wednesday, December 11, 2013 at 3:28 PM, Dave Brondsema wrote:
>
> > And it'd be convenient to test non-public APIs in your web browser
> without
> > setting up a bearer token. I can't think of any reason not to do it.
> >
> > One minor item would be to determine if cookie or bearer token takes
> precedence
> > if both are provided.
> >
> >
> >
> > On 12/10/13 3:05 PM, Cory Johns wrote:
> > > The main benefit I see is that we could start using the API to
> implement
> > > some Allura features client-side. This would increase usage (and
> > > dogfooding) of the API and potentially improve performance for the user
> > > (though it would make those features reliant on javascript, and there
> has
> > > already been some push to move in the opposite direction of reducing
> > > dependance on javascript).
> > >
> > >
> > > On Tue, Dec 10, 2013 at 3:01 PM, Cory Johns <johnsca@gmail.com(mailto:
> johnsca@gmail.com)> wrote:
> > >
> > > > We (somewhat) recently added bearer tokens to the REST API to make
> using
> > > > the API easier for developers, but I was wondering what the
> consensus was
> > > > regarding allowing auth via the normal browser cookie?
> > > >
> > > > Like bearer tokens and the normal web session, it would require SSL.
> I
> > > > can't think of any issues with it, personally, since it would have
> the same
> > > > security as the normal browser session.
> > > >
> > > > Same-origin policy ought to prevent data leakage on GET requests, and
> > > > requiring POST for action end-points ought to prevent any other
> > > > shenanigans. Is there anything else I'm missing? Any other reason
> not to
> > > > add the normal session cookie as an API auth option?
> > > >
> > >
> > >
> >
> >
> >
> >
> > --
> > Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> > http://www.brondsema.net : personal
> > http://www.splike.com : programming
> > <><
> >
> >
>
>
>
Re: REST API: Cookie auth?
Posted by Tim Van Steenburgh <tv...@gmail.com>.
I'm +1 on adding cookie auth, with bearer token taking precedence if both are provided.
On Wednesday, December 11, 2013 at 3:28 PM, Dave Brondsema wrote:
> And it'd be convenient to test non-public APIs in your web browser without
> setting up a bearer token. I can't think of any reason not to do it.
>
> One minor item would be to determine if cookie or bearer token takes precedence
> if both are provided.
>
>
>
> On 12/10/13 3:05 PM, Cory Johns wrote:
> > The main benefit I see is that we could start using the API to implement
> > some Allura features client-side. This would increase usage (and
> > dogfooding) of the API and potentially improve performance for the user
> > (though it would make those features reliant on javascript, and there has
> > already been some push to move in the opposite direction of reducing
> > dependance on javascript).
> >
> >
> > On Tue, Dec 10, 2013 at 3:01 PM, Cory Johns <johnsca@gmail.com (mailto:johnsca@gmail.com)> wrote:
> >
> > > We (somewhat) recently added bearer tokens to the REST API to make using
> > > the API easier for developers, but I was wondering what the consensus was
> > > regarding allowing auth via the normal browser cookie?
> > >
> > > Like bearer tokens and the normal web session, it would require SSL. I
> > > can't think of any issues with it, personally, since it would have the same
> > > security as the normal browser session.
> > >
> > > Same-origin policy ought to prevent data leakage on GET requests, and
> > > requiring POST for action end-points ought to prevent any other
> > > shenanigans. Is there anything else I'm missing? Any other reason not to
> > > add the normal session cookie as an API auth option?
> > >
> >
> >
>
>
>
>
> --
> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
>
>
Re: REST API: Cookie auth?
Posted by Dave Brondsema <da...@brondsema.net>.
And it'd be convenient to test non-public APIs in your web browser without
setting up a bearer token. I can't think of any reason not to do it.
One minor item would be to determine if cookie or bearer token takes precedence
if both are provided.
On 12/10/13 3:05 PM, Cory Johns wrote:
> The main benefit I see is that we could start using the API to implement
> some Allura features client-side. This would increase usage (and
> dogfooding) of the API and potentially improve performance for the user
> (though it would make those features reliant on javascript, and there has
> already been some push to move in the opposite direction of reducing
> dependance on javascript).
>
>
> On Tue, Dec 10, 2013 at 3:01 PM, Cory Johns <jo...@gmail.com> wrote:
>
>> We (somewhat) recently added bearer tokens to the REST API to make using
>> the API easier for developers, but I was wondering what the consensus was
>> regarding allowing auth via the normal browser cookie?
>>
>> Like bearer tokens and the normal web session, it would require SSL. I
>> can't think of any issues with it, personally, since it would have the same
>> security as the normal browser session.
>>
>> Same-origin policy ought to prevent data leakage on GET requests, and
>> requiring POST for action end-points ought to prevent any other
>> shenanigans. Is there anything else I'm missing? Any other reason not to
>> add the normal session cookie as an API auth option?
>>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: REST API: Cookie auth?
Posted by Cory Johns <jo...@gmail.com>.
The main benefit I see is that we could start using the API to implement
some Allura features client-side. This would increase usage (and
dogfooding) of the API and potentially improve performance for the user
(though it would make those features reliant on javascript, and there has
already been some push to move in the opposite direction of reducing
dependance on javascript).
On Tue, Dec 10, 2013 at 3:01 PM, Cory Johns <jo...@gmail.com> wrote:
> We (somewhat) recently added bearer tokens to the REST API to make using
> the API easier for developers, but I was wondering what the consensus was
> regarding allowing auth via the normal browser cookie?
>
> Like bearer tokens and the normal web session, it would require SSL. I
> can't think of any issues with it, personally, since it would have the same
> security as the normal browser session.
>
> Same-origin policy ought to prevent data leakage on GET requests, and
> requiring POST for action end-points ought to prevent any other
> shenanigans. Is there anything else I'm missing? Any other reason not to
> add the normal session cookie as an API auth option?
>