Currently I have configured Quickbooks online API functionality for single user. which gets customers/bill information from quickbooks online using OAuth. It is working perfect.
I want to do the same functionality for multiple users.
Now there are many user's of quickbooks who have their own quickbooks online accounts and all these users are present in my custom application.
Is it possible to setup API functionality using keithe palmar's dev kit for different users to have API access? which things needs to be configured to make it run?
Is it possible to setup API functionality using keithe palmar's dev kit for different users to have API access?
Yes.
which things needs to be configured to make it run?
There is a variable $the_tenant that needs to be unique to each separate QuickBooks Online company you want to connect.
If you're building a multi-tenant type SaaS app, then you probably have a unique identifier for each of YOUR tenants already. So, set $the_tenant to your unique tenant ID value.
Done. That's all you have to do.
Relevant code:
// The tenant that user is accessing within your own app
$the_tenant = 12345;
https://github.com/consolibyte/quickbooks-php/blob/master/docs/partner_platform/example_app_ipp_v3/config.php#L57
All of the OAuth stuff is stored/based on that $the_tenant variable, so just make sure it's set to your unique tenant ID, and you're good to go. Note that you'll have to connect each individual QuickBooks company separately.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
I want to develop and publish a bot for Teams, to interface with my SaaS (I already have a Slackbot that I'm porting). I'm creating a Bot Channel Registration as per this guide and came across the choice of whether to auto-generate a new App Id and password, or manually registering one (described here). I already have an Azure AD app for my SaaS that is published to the AppSource marketplace (the integration currently mainly allows logging in with your M365 account and syncing users from AD). Is it possible, and would it make sense to use the same App ID for the bot I'm developing for the same SaaS? Or is it somehow not advisable? And relatedly, can I expand my existing listing on AppSource to also contain the new bot, or should this be a separate listing?
I noticed in the documentation for manual registration of a bot, that it says that bots only work with "Accounts in any organizational directory and personal Microsoft accounts (e.g. Xbox, Outlook.com)" - my existing app only works with organization accounts, not personal accounts (since it's a B2B app) - does that change things?
Perhaps consider the question the other way - is there any good reason TO re-use the app ? It's very easy and basically free to create an additional app, and that way you don't run the risk of possibly ending up with settings needed for one scenario that conflict with another scenario's requirements, now or in the future. Here are some other possible considerations though:
new apps require Publisher verification, since 9 Nov 2020. This won't affect you for an internal app, which can be consented to by a global admin.
If you need the user (or admin) consent for some set of privileges (e.g. delegated Graph access), then using the same app might make sense. An example, in a Teams context, might be a bot and a tab that both need to access something from the Graph on the user's behalf. You could get consent in one context, and use it to access the resources from both contexts.
In a nutshell, and especially without a really really good idea of both of your current and planned use cases, it's hard to give a really solid 'yes' or 'no'. My gut says go with a separate app for a separate, unrelated scenario though.
Reusing the same appid against any other B2B won't create any problem. Being said that you can't use the above app if you're planning to implement/use BOT framework with it, as it's registered for organization only.
If you plan to create BOT related app registration then i would
suggest you to create new app registration with Organization +
personal for you scenario.
Please see the documentation and it's disclaimer:
In the above document it's pretty clear if you create any other app registration (other than Organization + personal), then the BOT will be unusable.
I am making a web application that will automate some actions on Google AdWords. The web application can be used by anyone that has an AdWords account.
I am a bit puzzled by the AdWords API, as it is a different from other Google APIs, in terms that it needs two additional config parameters: developerToken and clientCustomerId, a per their documentation:
https://developers.google.com/adwords/api/docs/guides/first-api-call
When constructing the AdWordsClient object, I need to provide the developerToken and clientCustomerId, in order to push data to AdWords.
My question is whether these two parameters (developerToken, clientCustomerId) need to be different for each user that will use my web application?
It seems that I am able to post data to different accounts with an unrelated developerToken, which does not make sense.
Can I get the clientCustomerId from an API endpoint, so I don't require my users to manually input tokens and ids to the web app, and do the complete authentication with oAuth?
My code is working, I am asking more of the philosophy why I need these two parameters, and if I can avoid asking the user to manually copy them from the AdWords dashboard into my application?
The developer token identifies a given Adwords API developer and is used for RMF enforcement, rate limiting and the like. As you mentioned, this is different from other Google APIs, which I think has to do with the fact that it's not a publicly available API. You always have to use the developer token that was given to you as part of your API sign-up process and are not allowed to use another developer's one (thus there's no possibility to have a user of your application enter it on their own).
The clientCustomerId parameter refers to the specific Google Ads account that you want to interact with. As a given user (identified by the OAuth2 access token that you include in your request) might have access to a whole lot of different accounts, this always needs to be included.
As for how to obtain a list of accessible account given a user's credentials, you can use the CustomerService.getCustomers endpoint for that purpose. Quoting the docs, it will "return details of all the customers directly accessible by the user authenticating the call."
I'm developing an application on Microsoft Graph that runs as a daemon, and needs access to many accounts. As a result, I'm using a service account, also known as client credentials (using this method).
I can request the proper scope (calendars.readwrite) however as far as I can see, I cannot restrict to which calendars I have access. In my case, I only need access to the meetingroom calendars, and I'm afraid that organisations will not allow my application if I can also read and write from/to the CEO's calendar.
Is there any way (either while creating the app, or during/after giving admin consent) to restrict my app to only a subset of calendars? Or should I approach this problem differently and (e.g.) not use a service account in the first place?
We are developing a web application using Microsoft Graph, where the signed in user can, Export all the calendar events to a third party calendar Application. After this initial export, we need to keep the exported data in sync with calendar changes via service app (a scheduled task running on server). This need to be a multi tenant application, as people from different organizations should be able to use this service.
Right now we did the authentication using OAuth 2.0 and OpenID Connect as described in this sample. Later we understood that the access token we get using this method cannot be used in the service app without user interaction. Considering our scenario what is the best way to achieve this?
I have read about App-only authorization method to do this. If we use this authentication method, the app need to be consented by a tenant administrator and the these applications are quite powerful in terms of what data they can access in the Office 365 organization. Considering we are developing a product used by different organizations, will it be feasible to use this method?
To use the client credentials OAuth2.0 flow (aka "App-only" or service account access depending on who's documentation you're reading) the admin for each tenancy will need to specify which scopes your daemon process can have for users in their tenancy. The end users can't give these scoping rights to your code themselves (as far as I know at least).
One thing to watch out for is that currently Graph API doesn't allow you to mess about with calendars that are attached to Office 365 Groups if you're using the client credentials flow. This is a pain for us, so we've raised it as an issue that needs fixing in the Office 365 feedback system. if that's an issue for you or anyone else, please throw a few votes at it so that it gets more attention at Microsoft. :-)