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> 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 http://www.brondsema.net : personal http://www.splike.com : programming <><
