I'm using the userless access to the Foursquare API using client_id and client_secret:
https://api.foursquare.com/v2/venues/search?ll=37.789565,-122.395487&v=20120608&client_secret=XXX&client_id=YYY
And get a response, but no results:
{"meta":{"code":200},"response":{"venues":[]}}
The latitude and longitude are in SOMA in San Francisco, and there should be plenty of venues around it. And, in fact, when asking for the very same coordinates using an OAuth token from the API Explorer instead of client_id and client_secret, I get plenty of results.
https://api.foursquare.com/v2/venues/search?ll=37.789565,-122.395487&v=20120608&oauth_token=XXX
However fact, when I change the location by a few blocks to ll=37.779129,-122.393333 I get the same results for both queries, so there's nothing wrong with my client_id and secret. This is totally beyond my comprehension. Is there anything I'm missing?
Okay, after a lot of experimentation there seems to be a bug in the Foursquare API (#akdotcom if you can read this please confirm). So, basically asking for
37.789565,-122.395487
didn't return any venues, but
37.7895651,-122.395487
does. Trailing zeros do not help, however appending 0000001 to both latitude and longitude seemed to fix it for my test cases. I suppose it's some weird weird problem with their URL parsing, but maybe someone from foursquare could illuminate me.
Related
I'm currently trying to figure out what the difference between gapi oauth access tokens and access tokens created via the googleapis package is. There apparently is a difference, since when I try to use the access token generated by gapis to authenticate to google picker using setOAuthToken() only the gapi access token works. This is unfortunate, since I need to refresh tokens on the backed and I therefore cannot use gapi. When I try to use the googleapis token, I get prompted to sign in, which is also not very ideal.
The scopes for both are exactly the same and the client_id is the same. The only idea I have is, that it might have to do with the googleapis one being an offline token, but that shouldn't matter right?
The code for the picker is pretty much straight from their docs:
picker = new google.picker.PickerBuilder()
.setCallback(pickerCallback)
.setDeveloperKey(apiKey)
.addView(google.picker.ViewId.SPREADSHEETS)
.setOAuthToken(access_token)
.build();
Anyone know what's going on here?
I have also seen a couple other people ask similar questions, but either their answers didn't fix anything (probably because some of the problems date back to 2012 and earlier).
EDIT: Nevermind. Somehow it resolved itself. I really have no idea why....
For text-mining project , I want to get all comments of specific media (image or video) from public account on Instagram and based on developers documentation any get action needs Access Token for security issues.
According to similar questions on internet, it is not possible to access comments endpoint without access token , But I don't know and can't understand the reason of using this limitation for public accounts.
I checked the ajax response with firebug for comments but I think this is not the good solution . is there any better solution ?
most likely your answer would be: no, there shouldn't be any better solution
the access token is a measure to protect against DoS and DDoS https://en.wikipedia.org/wiki/DoS#Distributed_DoS
so there is a strong rationale behind it, and measures should be in place to avoid you to work around it
I need some clarification on how Sharepoint uses Oauth and what I can/can't do with bearer tokens.
What I would like to be able to do is to either retrieve a bearer token from Sharepoint, cross domain via javascript and/or set up Sharepoint to use the same machine key as my current Oauth server.
I've read most of this article and several others but it has me bouncing around without a clear example. :
https://msdn.microsoft.com/en-us/magazine/dn198245.aspx
Recap:
I need a code snippet for retrieving a bearer token from Sharepoint using Javascript, cross-domain and...
I need a walk through of sharing the same machine key for claims based bearer tokens with Oauth 2.0
And to clarify what I'm trying to do:
I will need to read/write to Sharepoint lists from different platforms and I want a standard way to do it. REST seems like the way to go. Our apps are being developed using RESTful services and Oauth. We've got all of that covered with html and javascript. I'd like to understand how to continue to use our current Oauth and REST patterns to create secure Sharepoint interfaces on our html apps as well as Java and C# using claims based bearer tokens. If I'm on the right track, please confirm and provide some clear examples/resources. If there's a better way to do this, I'm all ears.
Bearer tokens work similar to money, whoever has the token is the rightful owner. That is why the terminology "bearer" (who ever bears the token) comes in. The tokens mainly rely on only SSL/TLS for security. Whoever "bears" an access token will be allowed to come in.
To answer your first question, I did research and found what your are trying to do. If you want to write it in Java Script and use the cross-domain library, you won't need to provide the access token.
var executor = new SP.RequestExecutor(appweburl);
executor.executeAsync(
{
url:
appweburl +
"/_api/SP.AppContextSite(#target)/web/lists?#target='" +
hostweburl + "'",
method: "GET",
success: successHandler,
error: errorHandler
}
);
I got that answer from here: https://msdn.microsoft.com/en-us/library/jj164022.aspx
For your second question I think it is possible,but uncommon to do. Unfortunately I am not to fond with using the same machine key as your current Oauth server, sorry! If I ever come across that in the near by future I will be sure to answer that question.
To clarify what you are doing, yes it does look like you are on the right track. If your apps are all using RESTful services it looks like REST is the way to go for sure. REST is probably easier in the same sense, because it uses HTTP requests which are easier than doing say COBRA, RPC, or SOAP. If you are looking to be more secure more than anything, use something like SOAP. Though it is debatable.
Some good resources may be to look at the Microsoft Libraries. They have pretty good tutorials though some are not too clear. Microsoft has documentation about the difference between SOAP and RESTfound here:https://msdn.microsoft.com/en-us/magazine/dd942839.aspx This is the link to Microsoft's Library: https://msdn.microsoft.com/en-us/library/ms310241 OAuth,REST,and etc. can be rough and hard to understand. Documentation is out there, but for certain things like using the same machine key as your OAuth 2.0 is hard.
Sorry, if I wasn't too clear, but if you need more help just reply to this answer. I hope this helped you some-what and enjoy your day!
I am trying to get the latest photos with the tag "mullet". The instagram documentation says that to do that I should type https://api.instagram.com/v1/tags/snow/media/recent? and then either client_id=CLIENT-ID or access_token=ACCESS-TOKEN
In my experience, using a client ID does not provide quick results, while using a client ID does. Does anybody know why this is?
Your question repeats client ID, so not sure which one actually works faster for you. But my stab at explaining it is as follows:
Client ID returns only public photos with the tag
Access token is user specific, so it will return all public photos as well as private photos that the user has access to (ie photos of private users that the user is following)
Since there's a little extra processing involved, it stands to reason that using access token would be a little slower, is that what you're seeing?
I am creating a simple web api that returns json.
It will perform simple crud operations.
What is the best way to authenticate users, OAuth seems to be the main recommendation here but I'm looking for something I can implement myself simply, token based or and API key??
Any ideas suggestions tips would be great, thanks
UPDATE: Forgot to mention, this API wont be for general comsumption, its just for my own use but I want to make sure someone cant get in too easily if they stumble on it.
First of all in order to build a good API you should use other people's API to see how they work. To be RESTful an API key is used, which is just a really big random number or "cryptographic nonce". But really this is just like immortal session id to look up a users authentication information, which isn't that great. OAuth is great, if you want your own system kerberos is very secure.
It is possible to hijack json responses, which is a pitfall against json. If the API key is required for each request, then the attacker can't use this method.