I am working on a project which downloads files using the google drive api. I am using a service account that has all the drive permissions (https://www.googleapis.com/auth/drive).
I am able to download some files without any problems, but sometimes I get the following error:
{
"error": {
"errors": [
{
"domain": "global",
"reason": "insufficientFilePermissions",
"message": "The user does not have sufficient permissions for this file."
}
],
"code": 403,
"message": "The user does not have sufficient permissions for this file."
}
}
When I attempt to download a file I impersonate the owner of the file. The owner of the file will definitely have access to the file so I am not sure why I am getting this error.
Is anyone able to explain how I could possibly be getting this error?
The problem was that the user I was trying to impersonate was suspended.
Related
I get this error when trying to "restart all dynos" through python heroku3 library (app.restart())
{
"id": "forbidden",
"message": "Restarts are currently disabled. Please try again later."
}
Im attempting to connect my RPi with the following, however it ails, error code 400. Have looked for an obvious cause, checked the google account, as far as I can tell all ok. Other google samples work fine, so audio is good; just the following is an issue.
Thanks
googlesamples-assistant-pushtotalk --project-id GoogleAssistant-PiHAT --device-model-id SPKR_MY
INFO:root:Connecting to embeddedassistant.googleapis.com
WARNING:root:Device config not found: [Errno 2] No such file or directory: '/home/pi/.config/googlesamples-assistant/device_config.json'
INFO:root:Registering device
ERROR:root:Failed to register device: {
"error": {
"code": 400,
"message": "Request contains an invalid argument.",
"status": "INVALID_ARGUMENT"
}
}
I have a K8 cluster on GCP running elasticsearch. Now I need to create a backup.
I've installed the GCS-plugin on my pods in stateful-set and tried setting it up with the following documentation:
https://github.com/elastic/elasticsearch/blob/master/docs/plugins/repository-gcs.asciidoc
When I try to configure a repository to use credentials stored in keystore I get the following response back:
{
"error": {
"root_cause": [
{
"type": "repository_exception",
"reason": "[my_backup] repository type [gcs] does not exist"
}
],
"type": "repository_exception",
"reason": "[my_backup] repository type [gcs] does not exist"
},
"status": 500
}
Any lead would be helpful, thanks!
I think the problem is that I can't install the plugin on the nodes, so I’ve installed it on the pods instead. And that the installation is not persistent after I restart the pods. So to make the installation persist on K8 I needed to build a custom image that installs the plugin. A bit tricky, but the plugin seems to be intended for GCE. So I decided to move from K8 to a managed instance group on GCE instead.
I am following below tutorial
https://hyperledger.github.io/composer/integrating/enabling-rest-authentication.html
I am able to complete the steps till setting up default wallet identity. After this when i try system ping method I get the error.
{
"error": {
"statusCode": 500,
"name": "Error",
"message": "Error trying to ping. Error: Error trying to query chaincode. Error: chaincode error (status: 500, message: Error: The current identity has not been registered:maeid1)",
"stack": "Error: Error trying to ping. Error: Error trying to query chaincode. Error: chaincode error (status: 500, message: Error: The current identity has not been registered:maeid1)\n at _checkRuntimeVersions.then.catch (/home/praval/.nvm/versions/node/v6.11.1/lib/node_modules/composer-rest-server/node_modules/composer-connector-hlfv1/lib/hlfconnection.js:696:34)"
}
}
The same error I get while testing from access token.
curl -v http://localhost:3000/api/system/ping?access_token=xxxxx
Though I can run network ping successfully.
composer network ping -p hlfv1 -n 'digitalproperty-network' -i maeid1 -s NfUhmXtiaSUH
Thanks for help.
The problem you are seeing is described by this issue
https://github.com/hyperledger/composer/issues/1761
Both the CLI and Rest server have enrolled the user but this results in both environments storing certificates for the same identity that differ (for example issue and expiry dates). Whichever environment used their certificate first for that identity and activated that identity/participant in the runtime has their certificate registered. When the other environment presents their certificate it isn't found (because it is different to the first environment) and so reports that the identity is not registered.
The way to address this is if you plan to use the identity in the rest server, don't ping it from the CLI first.
I am getting an error while calling GET /system/ping
{
"error": {
"statusCode": 500,
"name": "Error",
"message": "error trying login and get user Context. Error: error trying to enroll user. Error: Enrollment failed with errors [[{\"code\":400,\"message\":\"Authorization failure\"}]]",
}
}
I have made the participant
Blockchain Participant
{
'$class': 'org.optum.blockchainv5.Participant',
ParticipantId: 'ParticipantId:2',
Name: 'Vipul Bajaj'
}
Then issued an identity to the participant
System Identity
{
userID: 'ParticipantId:2',
userSecret: 'dPJbJBsaOLaf'
}
And then added that identity to default wallet
Wallet Identity
{
enrollmentID: 'ParticipantId:2',
enrollmentSecret: 'dPJbJBsaOLaf',
id: 3
}
And then set this wallet identity default by calling the POST /wallets/1/identities/3/setDefault
Got response code 204
And after calling GET system/ping gave me error.
just following up - if you're still getting this error, could you attach a trace log setting export DEBUG=composer:* ` then re-running the rest server - the log file is in a 'logs' directory (from where you start the composer-rest-server). Then we can see what's going on with the POST.
I had a similar issue.
I was trying to deploy a composer hlfv1 network instance locally. I was running the ./createComposerProfile.sh script. This script has this line cp "${DIR}"/hlfv1/composer/creds/* ~/.hfc-key-store
This copies all the credentials on your creds folder and overrides the ones created by composer identity import on your ~/.hfc-key-store
You could copy the credentials from ~/.hfc-key-store to the creds folder or comment out this line.