I have Elevated access to the Twitter API V2, and I am working with the API in Postman to search for recent Tweets containing a keyword. I’d like to be able to add a further query parameter to only return Tweets that have a geolocation associated with them. To do this, I am adding the has:geo parameter, as shown in the below URL call:
https://api.twitter.com/2/tweets/search/recent?query=dogs lang:en -is:retweet has:geo
However, this is returning with the following error:
There were errors processing your request: Reference to invalid operator 'has:geo'. Operator is not available in current product or product packaging. Please refer to complete available operator list at https://developer.twitter.com/en/docs/twitter-api/enterprise/rules-and-filtering/operators-by-product.
From my understanding, of this page in the documentation, the has:geo search operator is only available to accounts with Elevated Access to the V2 API (which I have).
If anyone has any suggestions of how I can get around this issue, that would be much appreciated please.
If you check the detail on that page, it further explains:
Twitter API v2
- **Essential**: Available when using any Project
- **Elevated**: Available when using a Project with *Academic Research access*
I agree that it is not sufficiently clear on that page, unless you re-read it (because "Elevated" and "Academic Research" are technically different access levels for your account).
The answer is that in order to use that search operator, you would need to have Academic Research access, not just Elevated access.
Related
I am trying to collect all active TIs via the Beta Graph API by following this. But it doesn't return anything. Here is what I use in Postman:
https://graph.microsoft.com/beta/security/tiIndicators
Response (200):
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#security/tiIndicators",
"value": []
}
A bit of context for the environment I work in.
The tenant has multiple Sentinel workspaces & resource groups.
The application I use has the correct permissions:
ThreatIndicators.Read.All
ThreatIndicators.ReadWrite.OwnedBy
ThreatSubmission.Read.All
ThreatSubmission.ReadWrite.All
It is my current belief that this might be due to the limitations of the Beta API. My reasoning is that accourding to this documentation you need the ThreatIndicators.ReadWrite.OwnedBy permission to access the API. This would suggest that currently you can only view TI's that the resource itself created.
If more info is needed just ask.
According to the documentation, ThreatIndicators.ReadWrite.OwnedBy permission allow you to manage threat indicators your app creates or owns.
If you want to read all the threat indicators for your organization then your app needs ThreatIndicators.Read.All permission.
Although this is not a solution to the question it is a workaround. By using the Log Analytics API you can get the TI via a KQL.
ThreatIntelligenceIndicator
| where ExpirationDateTime > now() and
NetworkIP matches regex #"^(?:(?:25[0-5]|(?:2[0-4]|1\d|[1-9]|)\d)\.?\b){4}$" and
ConfidenceScore > 25
| summarize by NetworkIP
This is probably better as you can also use a watchlist to exclude specific IP addresses with one request.
One thing I struggled with this was Authorization. You must give your Application permission to use the api.loganalytics.io API, and the application needs the Log Analytics Reader role in the Log Analytic workspace you want to use.
I am trying to use the graph API (v1.0) to search for files and folders within our team's sharepoint/onedrive folders but when using an app-only token I consistently get no results for any /search(...) request I try.
I have an registered and application with https://apps.dev.microsoft.com and have requested and granted consent for the permissions stated in the API Documentation;
User.ReadWrite.All, Group.Read.All, Sites.Read.All, Sites.ReadWrite.All, Group.ReadWrite.All, Sites.Manage.All, Files.ReadWrite.All, User.Read.All, Files.Read.All, Sites.FullControl.All
When I request a token from https://login.microsoftonline.com/ I can see the granted permissions in the payload.
Using this token I can successfully access the drive and retrieve information about its contents using drive/root
I have a small test folder structure that contains a few simple text files.
I can confirm that this token gives me access to my files and folders by calling drives/{driveid}/items/{folderid}/children recursively to build a complete tree structure.
However, when I try to search the drive for filenames or text phrases that I know exist I get no results at all, no matter what combination of paths or search terms I use. I've never seen a search result from an app-only token.
Examples that I've tried;
sites/root/drive/search(q='test')
drive/root/search(q='test')
drives/{driveid}/search(q='test')
drives/{driveid}/root/search(q='test')
The phrase "test" exists both as a filename and also within the text content of some of the files.
I get an HTTP:200 response but the value collection https://graph.microsoft.com/v1.0/$metadata#Collection(driveItem) is always empty.
I'm building http requests in my application (Coldfusion), not using a SDK.
I wondered if I was having encoding problems so have tried various approaches of url-encoding the search part of the url (q='test') etc.
I've also tried running the same requests with Postman and cUrl but the results are the same. Empty.
The only thing that works is when I try the same searches using the Graph Explorer I get the results I would expect to see.
I know that Explorer uses a different type of token so I'm wondering if this is and issues related to my token being app-only.
Does anyone know if .../search() actually work for app-only tokens?
Does anyone know if .../search() actually work for app-only tokens?
The answer is yes, ../search() actually work for app-only tokens
Based on my test, the following search API works well for app-only token
https://graph.microsoft.com/v1.0/drive/root/microsoft.graph.search(q='test')
https://graph.microsoft.com/v1.0/drives/{driveid}/root/microsoft.graph.search(q='test')
https://graph.microsoft.com/v1.0/drives/{driveid}/microsoft.graph.search(q='test')
https://graph.microsoft.com/v1.0/sites/root/drive/search(q='test')
For permission config, just put "Files.Read.All, Files.ReadWrite.All, Sites.Read.All, Sites.ReadWrite.All" into the GraphScopes in the project config file as docs states.
Above answer is based on your description：****register app in http://apps.dev.microsoft.com/. You can ignore the SDK although it is the best choice. If you don't have a project config with GraphScopes, you need to pass the scope to auth request, it is difficult for operation.
If your app-only mean register app in SharePoint online, then the Graph Search API won't work. SharePoint doesn't share AccessToken with Graph directly.
Here is the same question again. The answer has been commented by a microsoft developer. He confirmed, it was a bug.
I've been trying to return the employeeId of a user through the Microsoft Graph API but so far haven't had much luck.
I'm assuming this is probably because it doesn't exist in the metadata for the user in the Graph API so makes sense.
However, the property is populated in Azure AD. If I use the AZ command prompt to query the user I can see the property. Likewise, if I query the old Active Directory Graph API endpoint I can even see it there.
For example, querying
https://graph.windows.net/{tennant}/users/{upn}?api-version=1.6 directly I receive the employeeId as part of the response (using the ActiveDirectoryClient however seems to ignore this property and doesn't store it anywhere).
Is there any reason for this? Wouldn't it make sense to have it returned as an additional property? I've also looked into extensions, but as it's not an extension isn't returned there.
Any help would be appreciated. I can get the information I need by querying the old endpoint directly, but this seems like a complete backwards step and involves multiple queries to get the information I need - including having to use multiple end points (one of which I assume will be deprecated and removed soon).
EmployeeId is currently a beta feature and is only available in the beta endpoint of the Graph API.
So if you want to access the beta endpoint you just have to change the version to beta in your url. For example:
https://graph.microsoft.com/beta/me/
https://graph.microsoft.com/beta/users/{id|upn}/
https://graph.windows.net/{tennant}/users/{id|upn}?api-version=beta
For more information about the user-object in the beta endpoint see: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/user
Going through the documentation for the Sharepoint API (located here: http://msdn.microsoft.com/en-us/library/office/dn605900(v=office.15).aspx) I am trying to figure out how to select chunks of documents. I was expecting $skip to work, as it is implied that most OData functionality should be present, but this doesn't work. I also can't figure out whether or not $skiptoken is a valid query param. It's listed in the documentation near the bottom (without further explanation), but I can't coax the proper result out of it so far.
If somebody knows about $skip or $skiptoken or another method available for getting chunked responses back, help with this problem would be great!
EDIT: to clarify, things like API_URL/files?$orderby=url&$top=5 work, but things like API_URL/files?$orderby=url&$skip=50 do not. However, I have just found a 'next' URL in the response which appears to provide server-side paging support. I'll try to figure out the use of $skiptoken from here.
The OData V4 protocol has specified (referencing 11.2.5.7 Server-Driven Paging) that:
OData services may use the reserved system query option $skiptoken when building next links. Its content is opaque, service-specific, and must only follow the rules for URL query parts.
OData clients MUST NOT use the system query option $skiptoken when constructing requests.
Thus, the implementation of the O365 SharePoint API that it publishes $skiptoken as a query option that the client should use for excluding first few items in the queried collection is a violation of the protocol. The client should use $skip for such scenario. But it seems from the O365 spec you attached that $skip is not implemented.
If you query a entity set of the O365 service and the response payload contains a next link (a #odata.nextLink annotation in the response JSON object), then it indicates that the service has server-side paging for the entity set. Typically the next link would be a URL containing the $skiptoken query option such as http://host/service/entityset?$skiptoken=n that the client can use for getting the next page.
I wish to get tweets with a keyword. But There is no result with any keyword.
http://search.twitter.com/search.json?q=summer
How to get results with Twitter Search API?
Version 1 of the twitter API has been deprecated and is being removed. Not sure how you can miss the giant warnings on the twitter dev site ;) This means simple code like the above will not work any more.
So, you now need to make authenticated requests (OAuth) using the 1.1 API, and it's nowhere near as simple as just doing a (in PHP) file_get_contents(http://search.twitter.com/ ...).
I couldn't see any server-side languages you use from your profile, but I wrote a lengthy post explaining the issue (with pictures) and how to use a php library to perform authenticated requests.