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 < tvansteenbu...@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 <john...@gmail.com(mailto: > john...@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 : d...@brondsema.net (mailto:d...@brondsema.net) > > http://www.brondsema.net : personal > > http://www.splike.com : programming > > <>< > > > > > > >
