Is is possible to get latest dalta link for messages and do not iterate through all messages until we reach last page?
/v1.0/me/mailFolders/{folderId}/messages/delta API
From documentation https://learn.microsoft.com/en-us/graph/delta-query-overview "Resources stored in Azure Active Directory (such as users and groups) support "sync from now" scenarios. This allows you to skip steps 1 and 2 (if you're not interested in retrieving the full state of the resource) and ask for the latest deltaLink instead. Append $deltaToken=latest to the delta function and the response will contain a deltaLink and no resource data."
But that does not work for messages how i understood. Is there another way to do this?
Related
I am pretty sure my understanding is correct but since I cannot find any Google documentation that explicitly highlights this I wanted to ask here.
Per https://developers.google.com/apps-script/guides/triggers/installable:
Installable triggers always run under the account of the person who created them.
And we know that when you create a trigger it will ask to authorize for all the scopes the script uses.
Then, that means that anyone with edit access to the script could leverage the Google identity of the user used to create the trigger to access the scopes the trigger is authorized for.
For example:
User 1 creates a Google Apps Script that uses GmailApp to send an e-mail
(i.e. GmailApp.sendEmail("one#example.com", "test subject", "email body");)
User 1 creates a trigger to run said script every hour and authorizes it with the appropriate GmailApp scopes
User 1 gives User 2 edit access to said script
Now, User 2 can go into said script and make changes to the code and access User 1's Gmail account. For example, user 2 could change the code to:
var emails = GmailApp.search("search string to find sensitive emails")
// use GmailApp.sendEmail to forward those details to someone else like User 2
All they would have to do is make changes to the code and save; they wouldn't need to re-create the trigger since it already exists. And the next time the trigger runs it would run the newer/updated code.
I was able to confirm this behavior by creating a test script on one of my accounts and giving another account edit access.
So my question is, what is the official/recommended way to mitigate this risk? The obvious answer is to not give anyone else edit access but what if that is not an option -- what if for support purposes multiple people need to be able to access the script, then what?
As you say, the only official/recommend way is to limit editing access to trusted persons.
In your particular example, User 1 could have chosen MailApp instead of GmailApp. The two seemingly redundant services are available separately because MailApp has very limited privledges exposed compared to GmailApp. (For instance, User 2 cannot search the victims Gmail with the MailApp service.)
You can collaborate while avoiding giving direct access to your script file using clasp and git. Only you push with clasp to the script. Everyone else submits changes through git. You can setup the system to be fully automatic (i.e. a git push triggers a clasp push) or manual (i.e. you review all changes first), bit either way you have good records of who did what, when with git.
There's inherent trust when you provide edit access to the script project. You either trust the person or don't trust them. There's no inbetween.
Some "theoretical" ways you may still protect the data:
Create and use different Google accounts.
Install Triggers at the specific deployment/not at Head:
Possible only if done manually. Installable triggers created programmatically can only be used at Head
When you deploy a web-app/api, You can deploy it a specific version.
This deployment version can then be provided, When you create a new trigger for a project here.
There is no need for a working web-app/api. We're only looking to get a deployment id.
In this way, even if user changes the script, your trigger will only run at the old version deployed.
Deployed versions can be seen at Publish> Deploy from manifest.
As the previous answer states, git would be a better call.
For all practical purposes, any data you share with a malicious entity should be considered compromised.
I am making a timer job in c# which will make a call to office 365 and fetch newly created users. For example, if I run it now it should fetch users since last run till current time (Delta). However I dont see any FILTER or API parameter where I can pass date and get ONLY those users who are updated or created after specific date.
Is there any API available something like this;
https://graph.windows.net/{MYORG}/users?api-version=1.6&[Filter=createdDate
gt 12/12/2016 or modifiedDate gt 12/12/2016]
Azure AD Graph API can't do this as far as I am aware of, the User entity does not contain creation or modification dates to query on.
However, the beta endpoint of the Microsoft Graph API should be able to do this. You can follow the instructions here: https://graph.microsoft.io/en-us/docs/concepts/delta_query_users. Simply put you must:
Call the users endpoint with the delta function
If you got a skip token, it means there are more pages
Fetch the next page until you no longer get a skip token but get a delta token instead
This delta token allows you to call the endpoint anytime later to get only the modified users (created/updated/deleted)
General guidance for delta queries
I found that blog already however its under delta and throwing errors to me. Here is what I got in response of first call;
https://graph.microsoft.com/beta/users/delta?$skiptoken=
when I did a GET to that link, I am getting error saying the resource you are trying to request is either does not exist or has been removed or...
I feel there is a bug as its beta API.
However, good news is I just found another blog which seems to have be fixed my problem using following query;
https://graph.windows.net/XYZ.onmicrosoft.com/directoryObjects?api-version=1.6&deltaLink=
I will anyway mark your answer as accepted assuming Microsoft will fix the issue I am getting from backend.
Everytime we send an image MMS with Twilio, they keep a copy of the image on their server.
Does Twilio have a API function or an account setting to delete image resources older than a certain time (rather than deleting them one by one with the Delete Media Resource API)?
Thanks!
Twilio developer evangelist here.
There is no account setting to delete images automatically, based on time or anything else. As the documentation says (emphasis mine):
Twilio will keep that media around until you issue an HTTP DELETE on that instance.
Every time you send a message you could schedule a job to run in the future to then delete that message's media. That way you are in control of deletion when you want it to happen.
I have an app that
- initiates checkins via the API
- receives checkin data via the push mechanism
The JSON object returned by an API call contains a source parameter denoting the app. [This actually seems unnecessary, since my app is initiating the API call...]
The corresponding real-time push response sent to my app does NOT have the source parameter included. Why is that?
I'm attempting to filter out the push data related to my app's checkins, and the easiest way would be to inspect source parameter. [I could also inspect the checkin ids, and watch for duplicates in the two paths; but that seems unnecessary if the source parameter was always included.]
Unfortunately, that particular field isn't currently passed along in our Push API. What exactly are you trying to do?
If you're looking to get real-time notifications about your own app's check-ins, it seems like you don't really need foursquare's push API? You could just have your app send-up the info you want to your own servers at the same time (or immediately after) you check in the user on foursquare, so that you still get real-time info.
If that doesn't work for you, if the user has authorized your application (which will be the case if you're using the User Push API), you can query our check-in detail endpoint (https://developer.foursquare.com/docs/checkins/checkins) to get that info, and filter away the check-ins you're not interested in.
I have a workerrole which creates a PDF document. I pass the workerRole the needed data trough a queue, the worker role creates a PDF document, stores it in a BLOB, but how can I send the BLOB address back to the website to inform the user where to go to download the PDF?
That's a typical scenario for the Correlation Identifier pattern.
When the worker role is done, it should send back a message over a queue indicating that the document is ready. You can use a Correlation Identifier (such as a document id) to indicate on the DocumentReadyEvent message which original request this event relates to.
You could also go the route of full CQRS and simply update a view-specific table that includes the new document, and let the web site query from that.
You could do it the other way around using a common naming framework. Let the website/user application choose the name and location of the blob based on some standard convention. The site/app can then occasionally check for the blob via an http request.
But, do you want to inform the web user in real time about the ready document?
You can do lot of things, for example you can create a table partitioned by "user id" and store the url of the finished documents there, and set up an ajax call that checks in background the content of that table for that user regularly, and when it founds a new one that has not been "viewed" yet, show a warning with a download link.
Just an idea.