We recently signed up for the tool Oribi. For some reason the Oribi platform is returning the following error and can't connect to our Analytics accounts via the API.
Forbidden: status 403 reading GoogleClient#getWebPropertyProfiles
We've been trying to solve this for weeks now and got the following message from them today - any advice or possible solutions to explore?
While the error we receive from Google indicates that there are insufficient permissions to access the Properties, when looking at your account, everything seems to be properly set.
The next step would be reaching out to Google to inquire about this.
While we won't be able to do this on your behalf, I'll be happy to assist with providing all the relevant information to make sure everything is clear so they can take a look into it.
The situation is as follows: When sending Google the API request to connect the Web Property, the following error is thrown back: Forbidden: status 403 reading GoogleClient#getWebPropertyProfiles.
The user connected to Google has Admin permissions on the account.
Related
We are occasionally seeing an issue with some projects where, when we try to do a GetPublishJob on a BIM360 model, we get back a 403 error, like this:
{"jsonapi":{"version":"1.0"},"errors":[{"id":"ad23cbc6-dc82-4dfd-83f9-6acd14bac6d2","status":"403","code":"C4R","detail":"Failed to get publish model job"}]}
In the docs, it says it could be whitelisting or permissions. We know our app is whitelisted, because we would not have made it this far if it wasn't. We're using 3-legged OAuth, and we believe that the user is able to manually perform the Publish. Can you tell us what specific other permissions might need to be investigated?
I am not typing answer, while I want to check some information with you:
if what you are using is this endpoint, it is public, so it does not need whitelisted. https://forge.autodesk.com/en/docs/data/v2/reference/http/GetPublishModelJob/ .
Since you are using 3 legged token, I doubt it may due to the expired token, while normally it should be 401 error.
With the same token, can your code perform Publish Model?
https://forge.autodesk.com/en/docs/data/v2/reference/http/PublishModel/
was this workflow working well in the past? or just failed recently?
To use this endpoint, the logged user (for 3 legged token) should have access with the folder.
When trying to getting response from https://developer.api.autodesk.com/bim360/admin/v1/projects/:projectId/activities it rises 403 error with details - Route not enabled for account. But, for example, request https://developer.api.autodesk.com/bim360/admin/v1/projects/:projectId/users has successfully responsed. User has all admin permissions.
Can every one help with that? :) Are there another ways to get project activities?
Unfortunately, activity API is not released yet, so you cannot use it currently. Please stay tuned with our official announcement in the further. Apologies for the inconvenience!
I am using ExactOnline API to fetch the transactions, my API is working fine, but suddenly the Error 403: Forbidden - The division is blocked error occurs and API return the empty result.
Please help.
Thanks.
An HTTP 403 with reason "The division is blocked" typically means the administration is temporarily blocked by a process that needs exclusive access to the administration. Examples are:
One of the company's users is creating or restoring a backup of the administration.
Exact is moving the administration to a different database. (After office hours; users are notified in advance through Exact Online's workflow system.)
API clients should be able to handle this situation. The typical solution is to try again at a later time.
You can find a full list of response codes here:
https://support.exactonline.com/community/s/knowledge-base#All-All-DNO-Content-respcodeserrorhandling
Since last friday, without having changed any code on my website or Google API Console, we started getting the following message:
"This site has exceeded its daily quota for maps. If you are the creator of this site, please visit the documentation to learn more".
What we can't explain is the following:
The Google API Console reports we are well under the maps daily quota
Users get this messages intermittently. If you get the message, for example, and reload the page, you probably wont get the message again.
We started getting an unrelated issue saying that the current site wasn't authorized to use the API. But the whole domain was authorized via the API console, has been authorized for over a year, we haven't touched that setting, this issue is also intermittent.
Any clue as to why is this happening and/or how to fix it?
I'm seeing a 403 "Access to the webpage was denied" error on one specific file being accessed via the Drive SDK. It was working earlier, the app permissions are set correctly, and we're having success with other files using different tokens against the same app.
We're getting the downloadUrl from the SDK successfully, then seeing the error message only after users are redirected to the downloadUrl. Because of that it's hard to track, but we've confirmed that it's working for some, but not for others — it hasn't fully stopped.
The full error text is:
Access to the webpage was denied
You are not authorized to access the webpage at [...] You may need to sign in.
HTTP Error 403 (Forbidden): The server refused to fulfill the request.
We're including the GET download and (valid) access_token parameters, all that.
My question is this: could this be related to the reported Google Drive outage that's currently happening, or is there some sort of throttle/limit to access of a single file over the drive API? I've never seen this behavior before, and this response isn't listed among the standard 403 responses.
I have just seen something similar. I was using a freshly acquired access token, so I don't think it's oauth related. My working theory is that the downloadUrl link was stale. When I got fresh meta data, which had a different value in downloadUrl, it worked using the same access token that had previously failed.
This is only a theory since it isn't documented anywhere, and I would actually expect 410 (or even 301) as a much more appropriate status than 403.