I am making a .NET application that will allow potential users to upload invoices they make on my app to their quickbooks account that they have set up and synchronized with their QBD version.
what steps will they/I need to take so that when they use my app, it will upload invoices to their account? Is it:
a) when they set up their account with the Intuit AppCenter, they will pick my app from the app center services (in doing so, it will generate a set of oAuth connection parameters for me to put into my app to push invoices to their account, if so how will I get these)?
b) Will I set up an account via the Intuit Platform Partners, and ask the user to use my account ID and Password by which they will "create new app" under my account for the purposes of generating oAuth connection information for my app to use?
c) Something different from the a) and b)?
Thanks!
The OAuth stuff is specifically designed to allow end-users to push a set of OAuth tokens/credentials from QuickBooks to your app. You then store the OAuth tokens, and use those to communicate with QuickBooks.
This is an accurate description of what happens, yes:
a) when they set up their account with the Intuit AppCenter, they will
pick my app from the app center services (in doing so, it will
generate a set of oAuth connection parameters for me to put into my
app to push invoices to their account, ...
You can read more about that process in the docs:
https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0011_from_the_intuit_app_center
The other scenario is that, if you allow it, the user may choose to connect to QuickBooks from within your app. In this case, they'll click the "Connect to QuickBooks" button (see the docs here: https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0010_from_within_your_app) which forwards them to Intuit's site, generates the OAuth tokens, and then sends them back to your site with the OAuth tokens.
In either case, the OAuth tokens will be sent to you so that you can store them and use them to communicate with the QuickBooks APIs.
This:
... and ask
the user to use my account ID and Password by which they will "create
new app" under my account for the purposes of generating oAuth
connection information for my app to use?
Is absolutely not what you want them to do. The whole point of OAuth is that you don't need to share any usernames/passwords of any time with any one.
Here are some additional answers to your other comments:
The part I am trying to figure out is what my customers will need to
do to be able to benefit from my app and its QuickBooks Integration
functionality.
They will need to log in to their Intuit.com account, and follow the prompts to connect their QuickBooks company to your app (i.e. follow the prompts to forward the OAuth credentials to your app).
Sounds like he/she will need to set up some account with ID and
password.
If they don't already have an Intuit.com account, they will be prompted to create one during the OAuth process. In the case of QuickBooks Online, they will ALWAYS already have an Intuit.com account (it's the same thing they use to log in to QuickBooks Online).
Now it seems to me that there are two ways that the customer can set
up accounts with Intuit.
They can set up an account through AppCenter, or within QuickBooks desktop directly (when you install the software, it prompts you) or if you're using any Intuit service already (e.g. QuickBooks Online) then you use your existing QuickBooks Online account.
Developer.Intuit.com accounts are only for developers (e.g. for YOU). Your end-users will not have a developer.intuit.com account. Nor do they need one.
a) what are the differences between the two?
Developer.Intuit.com accounts are only for developers. Your end-user will never see the developer.intuit.com website, nor will they see the option to "Create an App".
b) which should be used if the customer wants to set up syncing their
QBD? c)Which should be used if the customer wants to use my .net App.
d)Which should the customer use if they want both (b) and (c)? e) If
the customer creates an account the 2nd way, won't they get confused
by all the "developer" lingo?
None of those questions are applicable - end-users will never see or be prompted about any of the developer stuff. The only reason you see that is because you're registered as a developer. Normal end-users will not be, and thus won't have any of these options.
f)What if the customer has already synced their QBD with intuit?
Then they can just log in to their existing account to get connected (i.e. to send the OAuth credentials over to your app).
With regards to your questions:
A developer can choose to get his app listed on the appcenter or not depending on mkting requirements.
To understand the difference in the process- you can create a sample and then on developer.intuit.com, go to My Apps-> manage my app-> select your app. Then test connections.
You can use any of the above to use QBD data. Please see the additional info too that I have provided.
Also go through the link which consolibyte has mentioned.
If you are logging in from appcenter app, then since you are already logged in, then only OAUTH will be required.
In logging from within your app, you do not need to provide your user Id and password. The user needs to register for the first time with Intuit.com and then OAUTH process follows for him. These open id/email details can be saved in your db so that user need to enter them a next time.
The customer is never about the details of the developer except for the app which will access their company data.
The sync manager for QBD
OAUTH authorizes your app to connect to their company files.
Any of the above can be used to access QBD data.
The sync manager runs manually or automatically. So, customer can choose to sync/not sync his data.
---------------Addtional info----------
There are two ways to integrate with QuickBooks, the first is with REST APIs and the second is with the downloadable QBXML SDK v12. The REST APIs and that integration model is for applications that are to be sold to customers via our Appcenter. They are generally Saas applications.
The second model is the QBXML sdk which is available for anyone to use, especially for custom integrations.
The reference for the QBXML SDK is here
http://member.developer.intuit.com/qbSDK-current/Common/newOSR/index.html
Please go through:
https://developer.intuit.com/docs/0025_quickbooksapi/0055_devkits ->QBXML SDK
Lastly through the QBXML SDK you can add a custom field to any entity you want. See the reference above and take a look at DataExt Add Request. and once added Query Request. I believe this will give you what you are looking for.
Keep in mind this is for QuickBooks for Windows not QuickBooks Online.
You can go through FAQ page too-
https://developer.intuit.com/docs/0025_quickbooksapi/0058_faq
I am settled at this point from what Consolibyte has shared and what I have learned also. The whole picture (for me at least) is that both the Developer Account AND the App Center Account is needed. The Developer account provides the consumer key, consumer secret and application token that the .Net app will use to authenticate with Intuit. The App Center Account is needed to allow the user to sync their QuickBooks Desktop data to a location where the app center (and other 3rd party apps) can have access to it (after user authorizes of course), and to give it's user an ID and Password needed to authorize the .net app ( or any app for that matter) to access his/her Intuit data. It is the combination of the Developer Account's tokens and the App center Account's ID and password that allow the generation of an authentication/access token by which the .Net app can instantiate a Dataservices object so it can read/write to the user's instance of QB data in the App Center. Apart from the user creating an account in the App Center and synching their QB Desktop data with it, There should be little or nothing else to do except provide the ID and password, providing the .Net app is coded right. I am not talking about OpenID in this case, but do know that it uses the same ID and password.
...so I'm good. Thx.
Related
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
How smartsheet developer tool account is different from paid account.
Also how developer account can be use for API call as pre-production environment.
Developer Tools can be enabled on any Smartsheet account. Having the Developer Tools enabled allows you to create an app for implementing the OAuth flow.
The purpose behind having a separate Developer account is to ensure you can experiment with the Smartsheet API without worry of making changes to critical items needed for every day work.
Since the Developer account is signed up with a different email address than the one you use for your main Smartsheet account it is a completely separate environment. But, it still acts like any other Smartsheet account. Without sharing the account to items in Smartsheet it won't be able to access them. This way you can create Sheets, Reports, and Dashboards to simulate the data you will be working with. Then as you make API calls to them you know you aren't causing issues for the real items people at your company are working on in Smartsheet.
One approach would be to share the Developer account to a collection of things you will eventually be running your requests against in production from your main Smartsheet account. Then in the Developer account make copies of those items. Once this is done you can un-share the Developer account so that it no longer has access to the real items in Smartsheet. Then you can make requests to the API to test your code and see the results as it would really happen. Once you've proven your code works you can adjust the access tokens and id numbers of Smartsheet items to work for your production stuff.
I want to develop an application(action) on Google Home, which will return some confidential information to user. So, I can't authenticate the user based on account linking as that device can be used by any person in the room. How can I get user's unique identity(may be email id) from voice match profile?
Account Linking is tied to the specific user that says "Ok Google" or "Hey Google" to invoke your Action. If the user that says it does not have a registered voice on the device they use (they are an "anonymous" user), then they cannot do Account Linking. This sounds like the level of security you're aiming for and it isn't clear why you think otherwise.
You can get a user's unique identity (with or without Account Linking) by using app.getUser().userId if you're using the node.js library. However, if the user is "anonymously" on a device (no voice registration has been done, or they do not match a registered voice), this identity will change each session because there is no way to determine who the user is.
You cannot get the user's email ID. (And, even if you could, one would hope that it follows similar rules to handling anonymous users above.)
Update to clarify what I mean by an "anonymous" request:
When a user first sets up a Google Home device, they're prompted to register for Voice Match on that device. Registering their voice requires them to say "Ok Google" and "Hey Google" a few times so a voice pattern can be established. Afterwards, these trigger words spoken by this person will have the rest of the statement associated with their Google Assistant account. If they have done Account Linking to your service, their Google Assistant account (which is matched to their voice for the invocation phrase) is linked to your service.
Other users can be permitted to register for Voice Match for a device. This will associate their voice for the invocation phrases with their Google Assistant account. If that user has done Account Linking with your service, then their voice triggering the invocation phrase will have things associated with their linked account.
But what about someone who uses the Home without having setup Voice Match for that device? The invocation phrases still work. They can still invoke your Action. But what Assistant account is associated with it?
Since the specific Home device doesn't know the person invoking it and making the request, this is an "anonymous" user. Anonymous users can't do Account Linking, since there is no Assistant account that is associated with the request. Although there is a userID provided - this ID will change for every conversation since the device has no way to know that the anonymous person making the request this time was the same anonymous person making it last time.
But what happens if the user has setup a Home device, but has not setup Voice Match on it at all? For security reasons, the system has to assume that this is really a shared device and that all requests have to be handled anonymously.
Additional Update
The "anonymous UserID" that is talked about above has been deprecated and will be removed in May 2019.
It is now possible to get the user's email address, assuming they have registered it as part of their Google profile, by using Account Linking with Google Sign-In.
Conceptually, may other parts of the answer remain valid, although some details may have changed.
You can use Account Linking for that purpose. If your phone is in locked state, then only the person who's voice will be registered in phone will be able to invoke the google assistant using OK Google.
If this type of invocation works for you, then go ahead and read the rest of the post. I've already posted a similar answer here
We have to enable the webhook first and we can see how to enable the webhook in the dialog flow fulfillment docs
If we are going to use Google Assistant, then we have to enable the Google Assistant Integration in the integrations first.
Then follow the steps mentioned below for the Account Linking in actions on google:-
Go to google cloud console -> APIsand Services -> Credentials -> OAuth 2.0 client IDs -> Web client -> Note the client ID, client secret from there
-> Download JSON - from json note down the project id, auth_uri, token_uri
-> Authorised Redirect URIs -> White list our app's URL -> in this URL fixed part is https://oauth-redirect.googleusercontent.com/r/ and append the project id in the URL
-> Save the changes
Actions on Google -> Account linking setup
1. Grant type = Authorisation code
2. Client info
1. Fill up client id,client secrtet, auth_uri, token_uri
2. Enter the auth uri as https://www.googleapis.com/auth and token_uri as https://www.googleapis.com/token
3. Save and run
4. It will show an error while running on the google assistant, but dont worry
5. Come back to the account linking section in the assistant settings and enter auth_uri as https://accounts.google.com/o/oauth2/auth
and token_uri as https://accounts.google.com/o/oauth2/token
6. Put the scopes as https://www.googleapis.com/auth/userinfo.profile and https://www.googleapis.com/auth/userinfo.email
and weare good to go.
7. Save the changes.
In the hosting server logs, we can see the access token value and through access token, we can get the details regarding the email address.
Append the access token to this link "https://www.googleapis.com/oauth2/v1/userinfo?access_token=" and we can get the required details in the resulting json page.
accessToken = req.get("originalRequest").get("data").get("user").get("accessToken")
r = requests.get(link)
print("Email Id= " + r.json()["email"])
print("Name= " + r.json()["name"])
I am working on a multi-user Clio app that can automatically OCR every document stored in Clio. I would like to enable my app so that the OCR settings are configured once for the firm and not individually for each user.
How does Clio recommend implementing firm-wide settings?
I had thought about using the #DomainName.com part of the customer's email address but that feels brittle and seems like a good way to create a security issue.
Clio recommends that applications store their application specific settings in their own data store (ie Firebase or similiar would work). If you need to share settings across users in an account you can gain access to the account id via the users end point. The following request (ensure your application has the User Read scope set) should get you started.
GET "https://app.clio.com/api/v4/users/who_am_i?fields=id,account\{id\}"
This will return something like:
{"data":{"id":344855567,"account":{"id":809455327,"redacted":true}}
The account id will be the same for each user in the account, you can use this as your account key in storing account specific application settings in whatever data store you're using for your settings.
Hi i create application that is common to youtube and i`ve got some questions. I use google login(oAuth), so i keep in my database all things required to use google APIs for every user that wants to log in. The question is if i can use(is it possible and legal) google analytics to get info(like gender of people which shows his/her video or age or region) about every user that is loged in to my application and show it to another users which using my application ?
edit:
I do not know if you understood me well, user log in to my app with his google account, i have in my database his google token, etc. In my application all users have got youtube account and now what i want to do is that if you are log in, you can see user`s statistics from youtube(like the gender of people who watch his/her video and what is thier age) for any user registered in my app. There is a youtube analyse api, which alow you to get your account stats, and if i have access to someone`s google account(i keep toke in my datbase), i couldnt just use it to request that analyse api for every user and in that way get access to their stats. And another question is if i get data in the way that i described(of course if it is possibe), is it legall, if i can display such an info to other users not only to the owner of the account?
Thanks for help
Is it legall, if i can display such an info to other users not only to the owner of the account? Thanks for help
If you are authenticating a user to get access to their Private data. It is your responsibility as a developer to ensure that their data remains private. You should not be sharing data between your users without there express permission.
If the data you are accessing is public then you are allowed to display that data with anyone.
Remember when you created your google developer console account you agreed to this Google APIs Terms of Service
b. Compliance with Law, Third Party Rights, and Other Google Terms of Service
You will comply with all applicable law, regulation, and third party rights (including without limitation laws regarding the import or export of data or software, privacy, and local laws). You will not use the APIs to encourage or promote illegal activity or violation of third party rights. You will not violate any other terms of service with Google (or its affiliates).
d. User Privacy and API Clients
You will comply with all applicable privacy laws and regulations including those applying to PII. You will provide and adhere to a privacy policy for your API Client that clearly and accurately describes to users of your API Client what user information you collect and how you use and share such information (including for advertising) with Google and third parties.
You may also want to read Privacy policy