I am designing a twitter iPhone app for my school. I wanted to moderate the users who can access the school account. In simple terms i do not want to use the original twitter server but make it local to only few users. Simply lets say a twitter for class. This will be running on our server and only few people can access it. I am very cofused about this any open sugeestions would help me.
Please help
Simplest way - twitter allows "protected profiles", where only users you are following can see your updates.. This is basically a whitelist of people who can see your statuses..
If you wish to allow multiple users to post from the same account, without hardcoding the twitter account into the application.. you could create your own API, essentially just a proxy for the twitter API..
You could then add your own level of authentication over this, so each user would have their own account (and you don't give out the shared account's login details)
In pseudo code, the application would be something like..
if request['username'] not in ['bob', 'alice']:
raise AuthError
if request['password'] != ['theuserspassword']:
raise AuthError
twitter_api = TwitterLibrary.login("sharedaccount", "secretpassword")
switch request['api_method']:
case "getPublicTimeline":
return twitter_api.getPublicTimeline()
case "postStatus":
return twitter_api.postStatus(request['something'])
Final option I can think of - you could run your own Twitter-like site.. There are plenty of "twitter clones", such as status.net (which is the code that runs identi.ca)
status.net and several other similar projects have Twitter-compatible API's, so you could quite easily take an open-source client (NatsuLiphone for example), and, with permission, rebrand and modify it to use the URL of your own site.
I'm not exactly sure what you mean by "not want to use the original twitter server". If you only want a few people to see the updates from that classes twitter account you could protect the updates and only allow students to follow the account.
However, this should help you create/customize your own twitter iPhone application. This is a link to Stanford's CS-193P course on Cocoa Development. The assignments in the class are creating and customizing a twitter client. All of the project files are available online.
http://www.stanford.edu/class/cs193p/cgi-bin/index.php
I hope this helps.
Create a regular twitter app that requires credentials, don't hard code the credentials in the app. Problem solved. Anybody could get the app on their phone, but only people previously authenticated on twitter would be able to actually use it. If you want to use Oauth you have do this anyway.
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.
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/
We're looking to create an API for our website. One of the major usages for the API (I suspect) will be to allow people to create mobile apps (for the iPhone and hopefully other devices).
What's the best way to handle API authentication for users. As a general rule, I don't like encouraging our users to hand their username/email/password details over to a 3rd party. However, is using oAuth acceptable/mature enough to work with for mobile devices? The only people using oAuth for mobile apps appear to have been Pownce, which seems to have had user issues and in any case is no longer around for me to see how they have dealt with the problem.
(Our user base is very untechnical, so I would expect <1% to have ever dealt with oAuth before)
The choice seems to be:
Ignore the issue with 3rd parties and passwords
Force developers to implement oAuth integration
Try something user unfriendly (such as using a secret key rather than their password)
Am I missing something?
I dont think I completely understand your question, what do you mean by "handle API authentication for user" ? Do you want to make users authenticate themselves before using your API? Or something else?
One thought though, and this is true I think for any mobile platform. If you have an API that will work through a browser, then any mobile app, on first launch after download should be able to launch a browser (all mobile platforms allow this) and do any type of one time authentication.
Hope this helps, further clarifications on your question will help me give a better answer.