Is it possible to restrict the surveys available to someone with api access to only a single survey? (Without using some kind of middleware server that restricts the access externally to surveymonkey).
This is not possible - having an OAuth token to someone's account is equivalent to having the password to their account. There are currently no limited views or restricted scopes possible with SurveyMonkey's API.
Related
Is it possible to use the grant_type 'password' for SurveyMonkey? Or something similar where no one is actually logging into the system as we are just requesting data and sending it back.
We have a client that wants to use a custom JavaScript-based application on their Intranet that will show users various information and then ask them a series of questions and log their responses for retrieval later.
According to the documentation, users are redirected to the SurveyMonkey website for the OAuth dialog and then can request and send data once they have a valid auth token. But who would this user be? As so far we haven't seen anything in SurveyMonkey regarding users who complete the survey, only admin accounts for who manage them. Unless we have missed it?
So is having a different grant type possible with the API?
We'd be interested to see what options we have available to us, as we're finding the documentation over at https://developer.surveymonkey.com/ a bit vague.
SurveyMonkey only supports the "authorization code" grant type, implicitly stated in the example code. Note that we are in the process of updating this OAuth code to give a much broader and detailed picture of how our OAuth works.
You cannot use SurveyMonkey's API to send in responses btw if this is what you were planning on doing - it is a read only API. You can see the list of supported requests on the left sidebar here.
When you complete OAuth, you are given an access token to the user's account who completed OAuth - i.e. you can access all their surveys and responses.
Respondents to a survey do not have an account on SurveyMonkey - they are represented as objects retrieved via the API method get_respondent_list, which accesses a specific survey's respondents. This survey is one of the surveys belonging to a specific user's account - i.e. the user account that completed OAuth.
I am trying to integrate quickbooks online v3 with c#.
In earlier version I could connect with appid and token.
Current version I would like to bypass the login and use API. Token is generated after logging in to qbsite.
No, this isn't possible (for what should be very, very obvious security reasons - why would anyone want to allow any person access to all of their companies financial data without any sort of login/authentication mechanism what-so-ever?).
The new v3 APIs use OAuth for authentication. The end-user is required to log in once to generate the OAuth tokens and authorize your app to access QuickBooks data.
After that authorization, you can use those tokens to access QuickBooks data any time you want.
This pretty much exactly mirrors the old qbXML connection ticket method that was previously available.
I'm not understanding how OAuth2 works for Google API.
Supposing I've signed in API's console and chosen several API's I would like to use.
My website should offers these API's to its users.
I have a doubt if my website users have to be logged in GOOGLE to can use these APIs.
For example, some users that prefer to login with Facebook couldn't use the APIs?
Depends on the API. Anything where you're accessing a user's data on their behalf (tasks, calendar, etc) then of course the user would need to have a Google account and would need to log in when authorizing your app.
But not all APIs act on user data. APIs like search & translate don't require a user to authorize access, and typically use a simple API key rather than OAuth.
User must be signed in Google to grant authorization to your application.
Your application is required to provide an access token when call Google API. The access token is granted by a Google user so that your application is able to access this user's resource on Google. So it's obvious that the user must be signed in Google.
I am using oauth to access different services provided by google.I am able to generate token per service basis. But I want to generate single token to use multiple services from google.
Can anyone tell me the solution for this?
https://developers.google.com/accounts/docs/OAuth2
As per the Google OAuth2 docs, it is possible to do this by setting multiple scopes, but be warned, it isn't a happy experience.
When making your request, set the scope parameter to multiple scopes, each separated by a single space.
Example: "https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email https://www.google.com/m8/feeds"
You can currently find a list of scopes here: https://developers.google.com/gdata/faq
Unfortunately, API access is not additive, meaning, if you ask for an access token for the Google Contacts API, then later on as the same application ask for an access token for the Google Profile API, you will end up with two access tokens, and neither can be used to access the other API. Facebook at least has the decency to give you back a single access token that grants access to all the permissions granted so far.
Because of this, you are left having to keep track of multiple access tokens (a horrible nightmare, given they expire very quickly), or ask for all of your permissions up-front, which is a user experience disaster.
Fragmented and disparate, the Google APIs are currently setup to fail if you want to do tight, multi-faceted integration.
We want to use Google Doc API to generate Document (In our own business account) when our end users do some actions on our site.
The problem is that we've tried to implement the OAuth 2.0 protocol, as suggested in the v3.0 protocol documentation. The apiClient::authentication method do a redirection. This is a major problem because our users doesn't know the access to our own business account.... and we don't want to give them access anyway ;)
(In other word, we're not creating an application that allow our users to edit their own data, but to interact with our data, like a database.)
I've read that the point of OAuth 2.0 was to avoid that we manage the credential of our users. I'm personally O.K. with the concept, but in our case, we don't want to get authenticated in the google account of our users ...
So, what would be the best approach to get a valid authentication without any interaction from the end user ?
What you describe is not how 3-legged OAuth was designed to be used.
3-legged OAuth is all about delegated authentication where a user (who knows his password) can grant limited and revokable resource access to application. That application never sees the user's password. There is a bunch of work involved to safely allow the application to impersonate the user.
What you probably want is to use the (2-legged) OAuth flow, where the consumer_id/consumer_secret credentials are embedded in your application. Here your application is not impersonating your end user and there would be no browser redirection involved.
Here's some further info on using 2-legged OAuth in Google Apps:
http://googleappsdeveloper.blogspot.com/2011/07/using-2-legged-oauth-with-google-tasks.html
And this is a good description of 3- vs 2- legged OAuth:
http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/
You will need to use a SERVICE ACCOUNT. Basically you are hard coding access to this account into your server application. Then you use sharing to give access to the to account for the content you want. For example you can share a Google Doc or an Analytics profile with the SERVICE ACCOUNT.
Here is a complete example implementation of setting up a service account, logging and and then using it.
Updated 2018-12-12: https://gist.github.com/fulldecent/6728257
Why not get one OAuth authorization for your business account and have all users use that account. Since it sounds like you want everyone accessing the data for one account, the details can be hid from the end user.
The access token would be shared by all users and they would all hit the same account back end without any authorization for each user's own account.