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 > <>< > >
