This question is specific to the Strava API: https://strava.github.io/api/
I've been working on an app concept app for a while, and have a few hundred users registered with an application that pulls their activity data from the Strava API, however due to reasons beyond my control I'm probably going to have to migrate the app to a new domain.
As a result, I'll need to change the Authorisation Callback Domain setting for my application in Strava, and I'm concerned that this may affect the authorisations which I have linked to the current domain - but I dont see anything regarding this in the API docs.
Is anyone aware of whether this would affect existing authorisations?
For anyone else with this question, I can confirm that existing authorisations are retained.
Thanks go to the helpful team on the Strava developers forum:
https://groups.google.com/forum/#!topic/strava-api/XyNWmRK1A4Q
Related
I'm trying to figure out how Likeboost or LikeHero work, 'cause I believe Instagram doesn't allow you to use Like endpoint to add a like to an image and they require you to submit the app for review as they stated here:
To request access to this endpoint, please complete this form.
But these apps just ask for your username and password (Surprisingly you don't get transferred to Safari for authentication process) and then you could like an image from that particular app. How do they do that? Isn't this against the following paragraph?
The ability to POST and DELETE likes, follows and comments is restricted to applications that offer business services and not consumer facing apps.
That applications that you are mentioning are using a fake native login page in order to avoid you leave from the application (like #Matthew Antolovich said). Once they get the access_token, there are no more dificulties and they can use the API calls.
As you can see in the Authentication documentation they might be using the Client-Side (Implicit) that is less secure but it works for they purposes.
They are giving permissions only to trusty applications in order to avoid that fake applications (bot apps, fake users, ...) use some API functionalities.
If you want to use these calls, you should fulfill the form that they are giving to you once your application is finished. If you are still developing the application you have to trust the Like documentation without the capability of test if it works.
There are other ways to restrict apps to use some calls (limit of requests per day, ...) but this is how they are doing it so, we must adapt.
Like #Matthew Antolovich said in his comment, if those apps are asking you for your user and password, they can log-in using the same requests present on the web. They could (and probably are) make their own API by reverse engineering the http requests.
On a side note, I would personally never trust those kind of apps.
I have this question in mind and I wanted to get other developer's opinion on this issue.
For creating a user (like in Facebook or creating an account in Gmail), some people suggested to have an public/private (means we don't tell developers how to use it) action in API for it. I, however, think it is a security risk as even if it is not documented, a hacker can simple see the calls and http requests when our front-end app is using that api action to create a new user (using a web debugger like fiddler) and can find the url to that action so simple ! like this POST ~/api/user/create
and then he/she can send thousands of requests to create user, users needs to be verified but still he/she is adding a lot of junk users in our database and puts a lot of pressure on our servers.
So the question is how do we handle this? Allow this only on our website or what?
Thanks
You can use CAPTCHA to verify that's a real user.
I'm practicing my Symfony 2 skills and would like to set up a simple REST API for a tiny application of mine.
I've set up REST Api with FOSRestBundle in few minutes. Perfectly. After setting it up, I've decided to secure it with OAuth. I've decided to go with FOSOAuthServerBundle. The stuff is working perfectly.
I've readed tons of materials and I'm wondering if I understand all of the stuff correctly. I understand how OAuth works, I'm just not sure if it was a good choice for my problem.
In fact, there will be many consumers available: users will be able to create their own apps based on the data fetched from API, there might be CMS plugin.
I suppose I misunderstood OAuth protocol in few ways: does OAuth always require end user action (giving a client app a permission)? Does users always have to re-authorize an app after access_token has expired?
Let's say an user want to fetch his content within my API - just to fetch some non-sensitive data. Does it require authorizing an app by the end user? I think I'm a bit lost here.
To avoid questions, yes I've read this few times and reading it all the time ;) I just think it's better to ask instead of copying terrible solutions, practices and false knowledge.
We have a large high traffic site with a lot of data on it (similar to Kickstarter), and we want to provide to our content/project creators a means of pulling their data from our site via an API.
Someone suggested I use OAuth, however my experience with OAuth is limited to setting up a twitter datasource.
What I want to do
Provide a user an Application ID and a 'secret'
Allow this user to connect to our application via an api endpoint, authorizing themselves using the api ID and secret
Once verified, allow this user to pull only their data from the application
The data that a user can pull: votes they have cast, pledges they have made, purchases they have made, projects/ideas they have launched, data about those projects/ideas (votes/purchases/orders/cancellations etc)
My question is:
Is OAuth overkill?
Is there a better way to handle a user/users website to connect to our API and pull/verify certain data by using the API we make available, while requiring each incoming request to be authorized for the user/site initiating that request.
Ideally, we will have an endpoint that is accessed as:
https://api.oursite.com/request/params
We want this to be as simple as possible for our users that wish to implement this interface. Thanks for your help!
Generally it's OAuth, in combination with SSL. That's the standard and is likely to stay. Before we saw also logins: username + password to access an API but that's becoming less and less.
So the suggested way is OAuth. There are no serious other solutions yet. To make it easier to adopt your API you could release some classes in some development languages so developers can have a quick start. You could start releasing those classes at for example GitHub to raise adoption of your API and get a quick access to developers. They might, if you do well, even start improving it.
I was reading through the windows live developers doc here. In that I saw they are having an authentication method something like this.
GET https://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&
response_type=RESPONSE_TYPE&redirect_uri=REDIRECT_URL
I understood everything except for where do I give the username and password of the user?
I am planning to create an app(first one in my life) to learn the working.
I also have never used or coded something over REST.
When using OAuth, your application never receives the user's username or password. Rather, the user logs in to Windows Live on the Windows Live servers and authorizes your application for access to their information. After they have authorized your application, you receive an access token from Windows Live on behalf of the user. You then use that access token with the Live API to retrieve user information.
Coding something using REST protocols isn't anything too terribly complicated. It has been my experience that you're just specifying parameters to the API using GET or POST as your request method. Adding OAuth on to your requests is a matter of specifying additional parameters.
You're task is to learn two things here since you've never done REST or OAUTH before. Spend time looking at both.
Oauth is hard to get and hard to implement.
You should choose an off-the-shelf Oauth library they exists for most languages.
(Then you do not have to worry about the details. OTOH: You should know how it works to know how to set up and fix if something goes wrong.)
http://oauth.net/code/