Everything I have tried requires the end user to sign in to yahoo...this won't work because the end user doesn't know the password or the username. This should be automated otherwise flickr wont work
You probably won't get this to work the way you want. OAuth requires the end user to authenticate with the service (Flickr) and physically authorize your application. So at the very least, you're going to have to interact with their server as a user if you want to authorize your application for use.
As a side note, you may want to investigate whether or not you can POST the required variables to Yahoo via some sort of script. Use Firefox and the Live HTTP Headers extension to view the POST information. This may or may not work, as my previous experience with some Yahoo forms require cookies designed to foil robotic submissions.
Related
I don't believe I need OAuth
Then again, what do I know
All I want to do is take someone's credit card information and charge them. I am not accessing other people's QuickBooks accounts (only my own) and I am not trying to access any other personal information other than what they input into my form. For this reason it seems absolutely asinine to think that I'd have to redirect them to intuit.com and force them through an OAuth prompt (what account would they even be authorizing? They probably don't have a QuickBooks account)
I've spent the last hour reading through QuickBook's API documentation and I've run in circles and found the whole thing utterly confusing. Every page which references a particular API endpoint makes no mention of authentication -- only the headers, query parameters, and request body that are expected. The API explorer does not show any form of authentication in their examples:
No basic auth header, nothing in the request body with an API token,.. nothing
Checking the console while hitting submit isn't any more helpful. The request gets sent to their back-end server where it does the real request:
It even includes "apikey", "apisecret", and "oauth" attributes in the body which are all empty -- it acts like the endpoint doesn't even NEED authentication.
Out of dumb curiosity I tried making the request with no authentication to see what would happen:
401 Not Authorized. So some authentication is needed. I continued to scour the docs and turned up nothing but page after page linking me back to OAuth and saying that I need to set up OAuth. Why do I need to set up OAuth to take a credit card number that was given to me and hand it to QuickBooks?
I even tried looking at their sample app. The "take the code for a test drive" (https://developer.intuit.com/v2/ui#/emulator?workflow=ecommerce) was utterly worthless. It only gave me some pseudo-code with zero idea for how to handle authentication:
I even looked at the actual code and don't see anywhere that they provide an API key or secret key.
I'm pretty much ripping my hair out at this point, so I think I need someone with experience to point me in the right direction.
I don't believe I need OAuth
You do.
For this reason it seems absolutely asinine to think that I'd have to redirect them to intuit.com and force them through an OAuth prompt
You misunderstand what OAuth is, and how it's used.
OAuth is used to get YOUR auth tokens so that YOUR COMPANY can authenticate to Intuit and identify itself so you can charge customer credit cards. YOU are redirected to Intuit's website to authenticate ONCE, and ONCE ONLY, and then NEVER AGAIN.
You store the tokens you get back from the one-time OAuth pop-up window process, and use those for all future HTTPS requests.
The end-user (i.e. your customer) is NOT redirected.
If you're familiar/used to something like Authorize.net or other web services, where you open a web browser and go to a website and copy a secret key/API token into your code... this is the exact same process except instead of you logging in and manually copy/pasting an API token/key, you're logging in and the OAuth process automatically gives you the API token/key programatically.
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 want to write a google chrome extension, that should make a request to my website to send and get some data, so, actually I should do an ajax request like it is written here https://developer.chrome.com/extensions/xhr.html
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://api.example.com/data.json", true);
I wanted ask if there is a way to somehow secure the code or prevent others from using my api, because actually the other users can see the source code of the extension when they install it and so use my api without me being aware of it.
EDIT:
If I need to make some sort of authentication, than how can I authenticate the user before making the ajax call ? for authentication I will need to send a request to my server , but for that I should send , e.g. username and password, that should be saved somewhere in the extension's files, which, in fact, can be seen by the users, when they install the extension.
Thanks
Don't trust the browser, take steps to authenticate the user instead. So, in this case, you could require that YOU enter in a password that is used to communicate with your server.
Your Google extension would simple require you to enter in a password before it attempts to use AJAX to communicate with your server.
Be aware that you should build in means of protecting yourself from brute-force attacks. So, do things like lock everything down if there are more than some small number of wrong passwords, etc.
You could also consider using the password to simply decrypt the destination of the XHR, but if you go this route, you should store this very carefully, because this will be brute-forceable offline.
EDIT
Trying to lock down an API so that only a single application can use it is just not practical nor technically possible, so you're only hope of doing this is to authenticate the user using the API, regardless of the accessing software he is using. You could have the user sign an agreement that legally limits them to only your extension, but I suspect this will go largely unenforceable and will consume your time tracking abusers down.
If you don't want unauthorized people even knowing where the API is, you could perform authentication using an out-of-band mechanism: over the telephone, email, SMS, or simply, another API that will grant the user a password or token that requests to your API must be accompanied with.
During this out-of-band process, you could also grant the user, a unique URI (the API access point) that is only valid per authenticated session (https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/, for example). Any requests to your server on OTHER URIs simply won't work. However, this isn't theoretically much different than using the same API access point, and having a good password. It just changes the number of places in your architecture that will be performing authentication and/or authorization checks.
<aside>My vote would be to reduce the number of authorization/authentication points to as few as possible so that you can spend more time on getting that one place correct rather than having multiple places and possibly multiple logic flaws or other things that could lead to vulnerabilities.</aside>
You could also explore using Public Key Infrastructure and/or one-time passwords schemes or device-based token generators, etc., but in the end, you'll be allowing authenticated and authorized users to use your API. And, thanks to the Internet, this will not remain an undisclosed URI for long.
And, more importantly, it will not prevent someone from using the data on their own. Even with all these measures in place, it would be trivial for an authorized user to collect this data as it is being streamed to your extension. Or, if you employ point-to-point encryption, they could screen-scrap or use some form of JS introspection on your very code or even extract the data from their computer's memory.
I know you were looking for a silver bullet here, but it doesn't exist.
I think you are doing it wrong. You should never trust what's going on on internet users PC's. Never!
Move the line of trust one step inward, make your API public and then design the security where you have perfect control - server side.
I could not get correct aspect of your use case
Few Points:
Your extension code is always traceable( Any one who has installed extension can view the code)
If you are looking for security through complicated or obfuscated coding patterns you end up slow down of understanding process not the whole.
If your target is to ensure users who install your extension should be able to access and inert all other users( Who have gained illegal access or downloaded and edited code) have a session shared key per installation.
Please explain further use case so i can help you better.
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/
I'd like to be able to give my users the ability to display their recent tweets on their profile on my website.
I have a PHP twitter wrapper and understand how to make API calls etc, but I'm just wondering how to manage the user information.
What is the best practice here? I want them to be able to enter their credentials once, but I would imagine storing everyones username/password myself isn't the best way to go about it.
Is there a way to make an authenticated call once, and have twitter remember it?
Should I store the usernames/passwords and then just make a call when displaying the tweets?
Any advice here would be great.
Thank you,
Use OAuth, no need to ask users for their passwords:
http://apiwiki.twitter.com/Authentication
I think everyone would/should probably agree that storing the twitter usernames/passwords is bad, I can't believe they ever created a situation where you needed it.
You should never store unencrypted credentials of any kind. If your solution involves holding onto a plaintext password, even for a brief time, you need to rework something.
Absolute best practice would be to hold no information yourself - use cookies or OAuth to handle your authentication. A session token or cookie can be disabled by the user at will, giving them control over the behavior of your site.
Next best thing (although still pretty undesirable) would be to hold non-reversibly encrypted credentials to resend to Twitter whenever you need to display tweets.
You don't need their passwords to pull their latest tweets, unless their profiles are locked, simply pull the feed from http://twitter.com/statuses/user_timeline/username.rss
You should look at Twitter's OAUTH support (although they have disabled it). This enables you to prompt the users once, and then store a response from twitter which will allow you to post
Tweets that you would want up on your web site are generally public anyway.
If you did need to authenticate somewhere (perhaps allow users to send new tweets) on a user's behalf, the best practice is to prompt the user at the time you initially authenticate and then store whatever authentication token is returned by the resource rather than the credentials used to get it.