I work in quick books onlineV3. Registered my application in the developer.intuit account.
Created an application by entering my host name, application URL, Disconnect Landing URL,
Manage Users URL, OpenID URl.
Used the App Tokens, consumer key and consumer secret keys in my application.
Above works fine.
I want to create one more application like the above. Can i use the same URL ?
If used, will there be any problem when using the before application ?
If not, what things i got to take care of ?
Looking forward your earliest reply,
Thanks,
Can i use the same URL ? If used, will there be any problem when using the before application ? If not, what things i got to take care of ?
You could technically use the same URL... but how are you going to tell which app is which if it's the same URL?
You probably want to use a different URL (even if it's just a query string to let you tell the difference between the two apps). Otherwise you won't be able to tell which connection is for which app.
Make sure to check out the QuickBooks PHP DevKit too if you haven't already.
Related
I am looking to display the current song I am listening to on Spotify. There is an endpoint to obtain this here (Spotify Web API Player) which requires authentication through the Spotify web API.
If I have obtained a Client ID and Client Secret from my app settings, which authentication type is suited to my needs?
I've looked here (Spotify Authorization Flows) but from my understanding and confusion, I believe this cannot be done as the request for authentication would be to authenticate the user against my app and display their current song and not mine.
Fundamentally, I'm looking for a way to display my current song without the end user having to request access to my app but instead, the app uses my details.
Thanks in advance.
Arielle from Spotify here.
The Authorization Code Flow is what you're looking for, but you are correct that in a standard implementation users would see their own data (which makes sense - you usually don't want users seeing other users' data)
However, you can set it up such that you're the only one who authenticates and only your data is shown. I actually made an app to show my currently playing track a little while back. Check it out on Glitch here: https://glitch.com/edit/#!/ari-currently-playing
You can simply start editing the project to "remix" it and make your own version!
Hope this helps, let me know if you run into any issues!
I want to practice on Steam login API and i don't have domain so can i use my local host XAMP/WAMP if yes then how to get an API key for it ?
Help will be appreciated
When Steam asks for a domain to obtain an API key, they don't actually verify that requests come from that domain. It's just for their records, likely so they can trace API abuse back to keys.
As long as it looks like a domain to Steam, it ought to work. Just don't use anything legitimate or try to impersonate anyone, as I can't guarantee there won't be repercussions.
You've probably found the page, but if you haven't, you can get an API key here.
I'm using PHP and json to make an API and I would like to limit the access for it.
The most user-friendly way to do this (in my opinion), would be an APIKey for each user.
What I'd like to do is check who's using/requesting the json, and then I could check the site toward the key (I know how to do the last part).
(The key will be appended to site url ?key=KEY)
I have tried
$_SERVER['HTTP_REFERER'];
But apparently this would only show the last site if you're redirected to my site.
I hope this wasn't TOO subjective, and I don't really know how to explain this in any other ways. Hopefully someone could understand what I'm trying to do and maybe got a better solution?
I'm kinda new to making API's atleast limited ones.
Thanks!
The referrer is set by web browsers to give you the last page the user browsed before getting to your site. If you authenticate a site by using an API key, and this site embed the API key in their JS code so that visitors can access your API directly, rate-limiting by using both API keys and referrer will allow attackers to DOS your API until a specific site has been rate-limited (because the attacker know the API key, and the referrer can easily be spoofed).
I am trying to get a list of all Google Apps users of a domain onto a public PHP website (without visitors of the site needing to login or do anything). I have a basic understanding of what needs to happen but can't quite piece it all together. It can't be as hard as it seems to me... could it?
Authentication and Authorization:
I'm pretty sure it needs to use OAuth 2.0 ... but am unsure whether it needs 2 legged or 3 legged. I got another section of the site working with ClientLogin but that won't pull in Google Apps profiles, only user's first and last names (I need the other profile fields). I have set up the API access within the account and have that side of things all set (I believe).
I have found this page, which shows how to construct a URL request to get all Profiles (in every language except PHP of course) but don't understand how to implement this.
http://code.google.com/googleapps/domain/profiles/developers_guide.html
I also tried this example but it just gives me a 401 after I enter the credentials. http://gdatatips.blogspot.com/2008/11/2-legged-oauth-in-php.html
I don't know which frameworks or includes are needed to accomplish this either. I have tried zend, OAuth.php and a whole bunch of other bootstraps... but keep getting lost as to what each is doing.
If someone could help me by outlining:
Which files/framework I need to upload and include as a bootstrap
What variables within those files I need to update with the Google credentials
How I integrate the Google Profiles "Retrieve all Profiles" request with PHP
An ELI5 (explain it like i'm 5) overview would be very much appreciated... I'm sorry for my apparent incompetence, but I have been reading articles for nearly a week and have not gotten anywhere.
Thank you in advance for any help provided.
Good question.
You'll need to implement the Google OAuth 2.0 process as it's described here (experimental?), because someone (you) will need to give your app the initial permissions to access Google Apps API. Steps are:
Register your domain with google (don't remember the link)
Redirect/send browser to an authentication url: https://accounts.google.com/o/oauth2/auth, with the appropriate request params (see the first link). You'll need access_type=offline, your scope would be https://apps-apis.google.com/a/feeds/user/
Get a code back, then exchange for a refresh_token, an access_token, and a value specifying when the access_token will expire. Store these in a database
Whenever you need to make an API call, check if your access_token has expired or not, and refresh when necessary, which is what the refresh_token is for. The refresh_token is valid as long as you don't revoke the access you gave to the app.
OAuth Playground helps a lot. Good luck.
user signs up for a key and secret from my site, then they can send/receive from my REST server.
Where I need help is when a user interacts with the REST, how can I determine if they are authenticated using THEIR key and secret? Basicly this will be for a social network site app area. I have seen that many social networks have an app area and use REST and OAuth and sometimes OpenSocial but I have looked at those and they are a bit complex for my needs I think. As for authenticating with OAuth, I guess I do not really understand exactly how it works, maybe it is what I am looking for though? I don't need to authenticate the user who views the page that is running the API, I need the owner of the app's server to authenticate to send back and forth with my REST?
Any advice on how to do this the best way? I would like to do it the best method for future growth, so if I could do it like the big boys do (Facebook, myspcae, hi5, bebo) that would be the way to go I think.
when a request is sent it should pass the key in the URL to my server but they should have there Secret somewhere in there script, I am not clear how to make that work with each other?
OAuth is almost certainly the best way to go here. Using OAuth, you can provide authorization to almost any kind of web-based API that you would like (REST is fine, but so is plain ol' XML over HTTP).
There are some Stackoverflow articles on how to get started with OAuth.
I also find Google's implementation worth studying, as it's both well documented, and a very good implementation from which to take inspiration. They also have a very helpful "OAuth Playground" that will walk you through an OAuth request step by step.