API requests via JavaScript with use of bearer token?

[devEngine]

Hello,

I am aware of issues #64, #221, and the like and I understand that reading through these and other threads that a JS approach to querying the Fusion API has been left aside so as not to expose client id and secret, etc. (at least in part for these reasons).

Per suggestions given, I have thus far built out a python back-end by which I store my credentials on the server but can save my bearer token as a cookie. I was thinking it would be more practical to issue API requests directly from the client (using the bearer token saved client-side) but I was just wondering:

a). Is there any way to do this (with my bearer token ready) or is that just going to give me a CORS issue and
b). is the idea to also keep the bearer token secret (or does that get matched with client-specific details on Yelp's end so that it doesn't matter if it gets exposed)?

Any input/suggestions would be appreciated.

Thanks!

[tomelm]

The idea is that you should keep the bearer token secret, that's what gives you access to the API and if that gets leaked someone could make requests that count against your quota.

If you try to make ajax requests using CORS your request will likely fail due to the different origins.

[devEngine]

Thanks - that had occurred to me, but I was hoping perhaps there might have been a work around this - like bearer token + permissioned app of some sort.

[builderLabs]

Just a suggestion here - I have put together some notes on querying Fusion using JavaScript/frontend approach.

Beyond this, however, exposure of the bearer token is something which could be neutralized if an authorized origin + bearer token approach was enforced, like Google does with OAuth 2.0.

I detail this in some notes I just posted:

Yelp-Fusion-Frontend

Hope you find it useful.

[devEngine]

Nice!!! Very handy, indeed.

Maybe that's what might be needed - to check the token along with the requesting origin. Re-opening to call attention to this issue.

[watterso]

Closing as dupe of CORS issue (#64)