I'd like to confirm my reading of the documentation for AggCat:
Real-time API access with categorization requires a user token which expires in one hour
If we want to refresh a customer's data behind the scenes, as an unattended process, we can use the Batch Data APIs?
Mike,
You can refresh the access tokens anytime you want, but they are always only an hour long.
Batch will update the account transactions on a nightly basis and will generate a file that you can consume to capture transactions. To download those files you will make use of the Batch API calls which also utilize the user token. You can at anytime perform a real-time refresh on an account to capture up-to-date transaction information. If you wish to have categorization that information will be available in both the batch file as well as the getTransactions API call.
regards,
Ben
You can refresh the access tokens anytime you want, but they are always only an hour long.
Batch is only if you want to get categorization. Nothing to do with unattended access specifically.
Related
I'd like to create MS Teams meetings from another application.
The Teams application is running on the computer, outlook is not used though.
How would I accomplish this the best / easiest way without (much) user interaction?
As far as I can see, the best option would be to use the REST API to create a meeting using the api-URL https://graph.microsoft.com/v1.0/me/events.
If I can also create a meeting commandline or by COM objects or something else, I could do that, too.
So here would be what I did for research with graph so far:
I can log on to https://developer.microsoft.com/en-us/graph/graph-explorer and use my user to create meetings and get the response. To do that, I modified the permission to read / read-write the calendar. If I copy the access token and use it with a powershell Invoke-RestMethod, it also does what I want. I can do the same with Connect-Graph -Scopes "Calendars.ReadWrite". But it would show this big browser windows about the login as X.
I read about apps, but if I use the apps ID and so on to log in silently, it seems like I am not in the current user scope but in a process scope and that's different. At least I set the API permissions up to also have access to Calendars.ReadWrite via Microsoft Graph, but I get an Access denied error if I try to run the same New-MgUserEvent to create a meeting for the current user (that is running the local powershell).
If use the token with Connect-MgGraph, it displays the client and tenantID and the ContextScope is process, not current user, so that would fit.
If I understand it correctly, I could use the token to get another one for a user... (reference is this: https://learn.microsoft.com/en-us/graph/auth-v2-user )
If I use the Connect-Graph -ForceRefresh parameter (which I guess would do the same, the popup tells me I'm logged in as the current user (not process).
This is a bit odd, so before I try to use the rest api and fumble a bit around:
Can I use the example from the link to refresh the token to get a user token that has the rights that I defined (and be able to access the calendar)?
Or is there some misunderstanding on my part?
Would it be a better idea to just use something like powershell, have the user log in once per day and leave the process in the background and create the new entries from there?
Do you have to refresh a token when you use connect-graph? Or could that be done better by Rest web api, if I can export the token?
The idea of having an app that would have access to all calendars would seem like a bigger security risk and I'd kind of want to avoid that. If I could configure the apps to have access to only one specific calendar, that would be cool, too. But I did not find it when looking around.
Thanks and best regards to all that took their time to read and consider to help.
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!).
We're starting to migrate our Website to a REST Service based system and are in the process of developing the core right now.
In our current setup a user has one or more "accounts" assigned which define what data he can see on the website. Only one account can be active for a given user at any time. Right now we store the selected account in the database and use it to filter all queries.
Now I'm not sure how to handle this properly in a REST environment. Possible solutions I found are:
Sending the requested account with every request
Storing the current account in the auth token. (We're using JWT for that)
Having the current account stored on the server and calling a specific resource to change it
Each of these has its pros and cons for our setup. Currently we're using the 3rd approach in our Website. But what would be the correct way to handle such a thing in a REST environment?
Yea the design you are dealing with is fairly bad, and what you really want to do is remove the state completely out of this system.
For that reason the first option is by far superior:
Sending the requested account with every request
If this is simply an id, there's a very simple way to do this, just prefix all your (relevant) routes / uris with this account id. For example:
http://api.example.org/accounts/{id}/...
This way the 'state' is maintained by virtue of which url you are accessing, and the server can be unaware of the state.
With there being rate limits should I ask for an increase when trying to get all access approval? Since my app asks the driver/ rider to sign in using their uber credentials will this help limit the calls to the API?
Thanks in advance.
Probably not, but it depends entirely on your purpose.
Calls to an API are usually done to get or update data on the home servers, in this case Uber's servers. As such, any Uber specific information you require will likely need to be accessed through their API.
Now, I've not reviewed Uber's API so if you can use the return from the login request to resolve all your needs then great. However, if you need to get data from their servers it would only reduce calls to the API if they require data returned on the login which can only otherwise be retrieved by making another call to their API.
I'm currently trying to make a website that allows users to host files, so I intend on buying a business Dropbox account for this purpose, generate an Access Token so the app don't go through OAuth authentication and internally serve and upload files to this single account.
Could it be done using a single Dropbox account? What are limits on calling from a single account. All access token logic would be hardcoded.
The Dropbox API does have a rate limiting system, but we don't have any specific numbers documented. It is only designed to prevent abuse though, and is accordingly very generous. Further, the limits operate on a per-user basis. That being the case, you generally don't need to worry about hitting it in normal use. The Dropbox API rate limiting system operates the same regardless of account type.
Also note that not all 429s or 503s indicate rate limiting, but in any case that you get a 429 or 503 the best practice is to retry the request, respecting the Retry-After header if given in the response, or using an exponential back-off, if not.
The API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files. However, it is technically possible to connect to just one account. The SDKs don't offer explicit support for it and we don't recommend doing so, for various technical and security reasons. Most of these concerns are allayed for server-side apps though.
So, if you did want to go this route, instead of kicking off the authorization flow, you would manually use an existing access token for your account and app, as you mentioned. (Just be careful not to revoke it, e.g. via https://www.dropbox.com/account/security .)