Google discovery service sending incorrect response for Gmail Discovery - google-api

We're using https://github.com/googleapis/google-api-python-client to connect to Gmail which handles the discovery as well. Today we noticed that APIs are not going through in one of the servers and figured out the discovery cache (cached at google-api-python-client-discovery-doc.cache) is invalid and not JSON parseable.
It looks like the discovery schema is incorrectly built or in transit something is lost(how latter can happen, I have no idea)
I've added the partial JSON here, you can see the invalid JSON at line:7 here.
"quotaUser": {
"type": "string",
"description": "Available to use for quota purposes for server-side applications. Can be any arbitrary string assigned to a user, but should not exceed 40 characters.",
"location": "query"
},
"upload_protocol": {
"description": "Upload protocol for media (e.g. \"raw\", \"eapis.com/auth/gmail.settings.sharing": {
"description": "Manage your sensitive mail settings, including who can manage your mail"
},
"https://www.googleapis.com/auth/gmail.modify": {
"description": "View and modify but not delete your email"
},
"https://www.googleapis.com/auth/gmail.metadata": {
"description": "View your email message metadata such as labels and headers, but not the email body"
},
"https://www.googleapis.com/auth/gmail.labels": {
"description": "Manage mailbox labels"
},
"https://www.googleapis.com/auth/gmail.addons.current.message.metadata": {
"description": "View your email message metadata when the add-on is running"
},
"https://www.googleapis.com/auth/gmail.insert": {
"description": "Insert mail into your mailbox"
}
}
}
I've attached the full discovery doc for valid one and invalid one here: https://drive.google.com/drive/folders/12LWm_EKNeWenJWUeIJA8BRDrXjz27OYO?usp=sharing
Do note that when this cache is invalidated, it works fine and the API is fine. The format is slightly different when this happens, so is it possible that Gmail is experimenting with something and this happens sporadically?

The fact that cache invalidation fixes the issue (meaning Python is directly grabbing a copy of the file, not using your cache) likely indicates the corruption is happening in your cached document. Seems like an issue with how it's stored on the filesystem.
Can you ever reproduce the issue if discovery file caching is completely disabled?

Related

Smart Home Test Suite Not Sending Execute Requests For StartStop Test Case

I am developing a Smart Home Action for Google Home, and I am trying to use the Test Suite to test the handling of EXECUTE intents sent to my fulfilment URI in the backend. I have successfully linked a test account and can populate the test cases with devices and traits (actions.devices.SHOWER devices)
However, when testing the StartStop trait, the Test Suite does not ever send an EXECUTE intent to the fulfilment URI to attempt to Start/Stop the device. The QUERY intent that is triggered after this test case fails is received correctly by my backend: see the test case screen
I have verified that the test case passes if I manually perform the necessary device state update and trigger a report state via Google Homegraph API while this "Start the Office" command is running. But I can see from my Http request logs that I never receive an EXECUTE intent, nor are there any entries in the Cloud Console logs showing an attempt to call the backend.
I have attempted re-linking my account, and using multiple test accounts but this behaviour does not change. The response I am sending to the SYNC is
{
"requestId": "9346220314501836318",
"payload": {
"devices": [
{
"id": "1002",
"type": "action.devices.types.SHOWER",
"traits": [
"action.devices.traits.StartStop",
"action.devices.traits.TemperatureControl"
],
"name": {
"name": "Office"
},
"attributes": {
"temperatureRange": {
"minTemperatureCelcius": 0,
"maxTemperatureCelcius": 60
},
"temperatureUnitForUX": "C",
"commandOnlyTemperatureControl": true,
"temperatureStepCelcius": 1,
"pausable": false
},
"willReportState": true,
"deviceInfo": {
"manufacturer": "REMOVED",
"model": "TestModel",
"hwVersion": null,
"swVersion": null
}
}
],
"agentUserId": "1000"
}
}
Are there any configuration errors that might cause the Test Suite to fail to send the EXECUTE intent? Or is this a bug?
I am not able to control these devices from Google Assistant directly (from my phone) - I get the error "this device has not been set up yet" but see no options to add it as a controllable device from the Home Control screen in the Assistant app settings.
Thank you for highlighting the issue. I can reproduce it on my side. Can you please open a bug in Public issue tracker for further debugging and share the same information there.
I’m going to follow up with the team and update you through the issue tracker.

Not receiving opsgenie created alerts

I'm working on implementing opsgenie for the first time, with a new airflow instance. I have been unable to receive alerts so far, even though everything seems to be correctly set up.
I already have my account/team and integrations (slack and api) set. I already configured the opsgenie conection in airflow (using the slack api key as password). An I already added the opsgenie hook to my code.
It all seems to work ok. According to the airflow logs, the opsgenie genie request is correctly sent. I even get responses like this:
Sending 'POST' to url: https://api.opsgenie.com/v2/alerts
<Response [202]>
{'result': 'Request will be processed', 'took': 0.007, 'requestId': '65f2a665-40ea-4173-967e-xxxxxxxxxx'}
If I search for the request id, I get this response:
{
"data": {
"success": true,
"action": "Create",
"processedAt": "2023-01-03T16:40:03.08Z",
"integrationId": "xxx",
"isSuccess": true,
"status": "Created alert",
"alertId": "xxx",
"alias": "ECO_OPSGENIE_ALERTS-send_opsgenie_alerts-20230103"
},
"took": 0.004,
"requestId": "65f2a665-40ea-4173-967e-xxxxxxxxxx"
}
However, NO alerts are ever sent, and I can't see them anywhere in the opsgenie alerts section. And of course I also get bothing on slack or on the opsgenie app.
If I create a "manual" alert using the opsgenie app, I do get slack and app alerts... but nothing using the API.
I also tried directly from postman, but same thing: no alerts are sent, even though the response says they were correctly created.
Any idea what could be causing this and how to solve it?
Not sure if anyone will need this, but I solved it. I had to add this parameter to the request's body:
"responders": [
{
"name": team_name,
"type": "team"
}
]
team_name is the name of my configured team in opsgenie. That's it. Now it's all working.

Tag Manager Client API: Unable to access Tag Manager content with API key

I would like to connect to the Tag Manager Client API to access some content in a container without having to log in.
This page mentions at the top that it "Requires authorization". However, I am using the contents of a container to store ad urls and the users of the website I'm working on shouldn't be asked to log in to Google for this.
What also makes me confused is that the "Try this API" UI let's me choose Credentials using:
Google OAuth 2.0
or API key
However, when I select "API key", I get a 401 error with the message: "Login Required".
{
"error": {
"errors": [
{
"domain": "global",
"reason": "required",
"message": "Login Required",
"locationType": "header",
"location": "Authorization"
}
],
"code": 401,
"message": "Login Required"
}
}
Thanks
The "test this API" interface presents you with a choice that is not actually applicable.
The API documentation for the GTM API is quite unambiguous:
Your application must use OAuth 2.0 to authorize requests. No other
authorization protocols are supported. If your application uses Google
Sign-In, some aspects of authorization are handled for you.
So the problem seems to be that the "try this API" has a generic UI that gives you options that are not actually valid for each of the APIs where it shows up.

Http POST from card in Microsoft Teams

We are trying to create an approval workflow using Teams, Flow, and Assembla and are running into a bit of trouble.
We have a few of the pieces successfully setup however we are unable to initiate a POST action from a card in Teams.
In teams we can successfully create a card using the incoming webhook connector with this result.
This is created with the following JSON body from a POST action in Flow
{
"##type": "MessageCard",
"##context": "http://schema.org/extensions",
"summary": "This is the summary property",
"themeColor": "f46b42",
"sections": [
{
"startGroup": true,
"title": "**Pending Review**",
"activityTitle": "Ticket Title",
"activitySubtitle": "Requested by: ",
"facts": [
{ "name": "Date submitted:", "value": "06/27/2017, 2:44 PM" },
{ "name": "Details:",
"value": "This ticket is ready for review." }
]
},
{
"potentialAction": [
{
"##type": "HttpPOST",
"name": "Approve",
"target": "ANOTHER-POST-URL-IS-HERE"
},
{
"##type": "HttpPOST",
"name": "Deny",
"target": "ANOTHER-POST-URL-IS-HERE"
}
]
}
]
}
We have another Flow url as the target for both buttons on the card. To test this url we are able to successfully post via POSTMAN and continue the approval workflow.
When clicking the button on the Team card the Flow at the post url is in no way notified at all. No run on Flow is triggered. In teams a very generic "There was a problem submitting your changes. Try again in a minute." error is displayed.
After researching I ran across the connectors.md file on the Microsoft Teams github page and noticed this lovely part of the documentation
It seems odd to me that right below them mentioning that POST actions may not be supported the documentation goes on in length to show examples of using POST and ActionCard actions in a card on teams.
So my question is this, is there any way to get an HttpPOST action to work from a custom card in Teams to a Microsoft Flow POST URL?
Thanks!
Update:
Upon further testing we have determined that HttpPOST actions
work with just about any post url we can come up with except
Microsoft Flow Request URLs. They are exceptionally long urls so maybe
that has something to do with it?
Here's an example Flow request url.
https://prod-43.westus.logic.azure.com:443/workflows/f86b928acd3d4ecab849f677974f7816/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=ZBxr5GFKQhMp4JXWGmec_L6aqgcaqvCOKUWOf2li-xQ
When running teams in a web browser we are able to see the request
first posts to a api.teams.skype.com url and returns a generic
"ProviderError". Other non-flow urls also do the same but return
success.
This was a head-scratcher for us - as you surmised, this should have worked. The Teams, Flow, and Outlook teams troubleshooted this today and found out what was going on.
The URL you are posting to, https://prod-43.westus.logic.azure.com[...] has an embedded bearer token (the value of the sig parameter in the URL). When you POST to that URL via CURL, Fiddler, Postman, etc. it works because that token is present.
However, when you click on a HttpPOST button in an actionable message, Outlook adds its own JWT token in the HTTP header, meaning that the HTTP POST has both a sig= bearer token in the URL and a JWT token in the HTTP header. Flow detects this and rejects the HTTP POST as invalid (while we don't currently support JWT tokens, we plan to, and treat this case as invalid to maintain forward compatibility).
This use case will work in the future. In the meantime, one workaround to try would be to have the actionable message buttons POST to your endpoints, e.g. https://yoursite.com/accept and https://yoursite.com/deny (validating the JWT as much as you like) and have these endpoints POST to Flow directly without the JWT.
Please let us know if that works.
BTW, the text you found is a documentation bug that has since been fixed:
Sorry for the confusion.

Google Verification API 503

The google verification api is giving me a 503 error "An unexpected error occurred. Please try your request again." whenever I try to verify a domain using the TAG_MANAGER method.
This occurs when I try to use the API via the PHP client library and also when I use Google's API explorer. However, if I log in to Google Webmaster Tools and add the site, using Tag Manager as the verification method, I am able to successfully verify myself.
I've attached debugging information from the API explorer below, but it's very light on detail. My support request in the webmaster central forum has been met with deafening silence, but I'm not sure where else to ask.
Request
POST https://www.googleapis.com/siteVerification/v1/webResource?verificationMethod=TAG_MANAGER&key={YOUR_API_KEY}
Content-Type: application/json
Authorization: Bearer ya29.iAC-QBa-7nzvS2lpFFmfcej2Y0suhiWHgS8SivKN9jpYWffljsRV7rbL
X-JavaScript-User-Agent: Google APIs Explorer
{
"site": {
"identifier": "http://unit1-28leanyerdriveleanyer.com",
"type": "SITE"
},
"owners": [
"loboyle#raywhite.com"
]
}
Response
503 Service Unavailable
- Show headers -
{
"error": {
"errors": [
{
"domain": "global",
"reason": "backendError",
"message": "An unexpected error occurred. Please try your request again."
}
],
"code": 503,
"message": "An unexpected error occurred. Please try your request again."
}
}
https://www.googleapis.com/siteVerification/v1/webResource?verificationMethod=TAG_MANAGER&key={YOUR_API_KEY}
may need to be
https://www.googleapis.com/siteverification/v1/webResource?verificationMethod=TAG_MANAGER&key={YOUR_API_KEY}
also, a few additional notes
For Google to use your Google Tag Manager container snippet code for Webmaster Tools verification, the code must be placed immediately after the opening tag of your page.
The method you provided is used for verifying a site or domain, be sure you intend to verify a site, because this is what your request currently contains.
This method requires you to be authenticated (OAuth 2.0)
http://code.google.com/apis/accounts/docs/OAuth2.html
Ensure you have visited the following link
http://www.google.com/tagmanager/features.html
I finally stumbled across the fix for this today. The problem was that the service account running the requests needs to have "View and Manage" permissions on the applicable Tag Manager account, not just on the container that is actually being used. Only view access is required to the actual container.
While this isn't exactly desirable (we have 20+ containers for different sites/applications within the one account), it does resolve the problem and allow the Tag Manager site verification to work as intended.
I'm not sure whether the documentation has been changed since I originally had this problem or whether I just missed it. The required permissions are unexpected and the response code is misleading (a 403 would make more sense).
Check if you've enabled "Maintenance Mode" on your domain you're trying to verify using Google. Disable it and you're done.

Resources