I'm using googleapis npm package ("apis/drive/v3.js") for Google Drive service. On backend I'm using NodeJS and ngrok for local testing. My problem is that I can't get notifications.
The following code:
drive.changes.watch({
pageToken: startPageToken,
resource: {
id: uuid.v1(),
type: 'web_hook',
address: 'https://7def94f6.ngrok.io/notifications'
}
}, function(err, result) {
console.log(result)
});
returns some like:
{
kind: 'api#channel',
id: '8c9d74f0-fe7b-11e5-a764-fd0d7465593e',
resourceId: '9amJTbMCYabCkFvn8ssPrtzWvAM',
resourceUri: 'https://www.googleapis.com/drive/v3/changes?includeRemoved=true&pageSize=100&pageToken=6051&restrictToMyDrive=false&spaces=drive&alt=json',
expiration: '1460227829000'
}
When I try to change any files in Google Drive, the notifications do not comes. Dear colleges, what is wrong?
This should be a comment but i do not have enough (50points) experience to post one. Sorry if this is not a real answer but might help.
I learned this today. I'm doing practically the same thing like you - only not with Drive but Gmail api.
I see you have this error:
"push.webhookUrlUnauthorized", "message": "Unauthorized WebHook etc..."
I think this is because one of the 2 reasons:
you didn't give the Drive-api publisher permissions to your topic.
Second if you want to receive notifications, the authorized webHooks Url must be set both on the server( your project) and in your pub/sub service(Google Cloud).
See below - for me this setup works:
1. Create a topic
2. Give the Drive publish permissions to your topic. This is done by adding the Drive scope in the box and following steps 2 and 3.
3. Configure authorized WebHooks. Form the Create Topic page - click on add subscriptions. Not rely vizible here but once you are there you can manage.
Related
I'm trying to use Google's Search Console API via their Node package, and my code looks like the following:
const auth = new GoogleAuth({
scopes: 'https://www.googleapis.com/auth/webmasters.readonly',
});
const webmasters = google.webmasters('v3');
const params = {
auth,
siteUrl: 'example.com',
resource: {
startDate: '2015-08-25',
endDate: '2015-08-25',
dimensions: ['query', 'page'],
rowLimit: 10,
},
aggregationType: 'byPage',
};
const res = await webmasters.searchanalytics.query(params);
console.log(res.data);
... except that in my version example.com has been replaced with my actual domain.
I'm invoking it at the command line with:
GOOGLE_APPLICATION_CREDENTIALS="/path/to/service_key.json" node index.js
I have a service account created, and the service key JSON file is from it. That service account has access to my Search Console account. When I look at https://search.google.com/search-console/users I see the service user there, and in the Permission column it has "Full".
Can anyone help me understand why I'm getting the following error when I run my code?
{
message: "User does not have sufficient permission for site 'http://example.com'. See also: https://support.google.com/webmasters/answer/2451999.",
domain: 'global',
reason: 'forbidden'
}
The URL mentioned, https://support.google.com/webmasters/answer/2451999, simply links me to the search console users page ... which (again) says the service user has full permissions.
After rooting in google forums and rest of internet I have figured out why it happen.
Need to copy Service account email, long weird format(example: whiskey-tango-foxtrot#certain-something-0123456.iam.gserviceaccount.com) from Google Cloud: https://console.cloud.google.com/apis/credentials to Search Console https://search.google.com/u/1/search-console/users, as a "Full site" user.
Make sure you have added that site(as from on Search Console) via your API or with this tool: https://developers.google.com/webmaster-tools/v1/sites/add
Then, when you perform "list_sites" request, your site should be listed ere and permission_level is "siteFullUser"(according to step 1)
When you add_site or perform query API requests, make sure to set siteUrl according to steps above, eg: http://www.example.com/ (for a URL-prefix property) or sc-domain:example.com (for a Domain property)
Happy coding
I am trying to run the sample AWS-Lex-Web-UI from the https://github.com/awslabs/aws-lex-web-ui#sample-site
As per the directions i am able to create the cognito pool id and also saved in the chatbot-ui-loader-config.json and tried with npm start. Server started at localhost:8000 but i am not able to run any one of the bot command.
Does anybody already implemented in the WEB-UI part using the sample example. I want to export my bot from AWS-LEX to any one of the local server.
chatbot-ui-loader-config.json:
{
"cognito": {
"poolId": "us-east-1:b3bxxxx-xxxx-45c7-xxxx-9xxxxxxxx"
},
"lex": {
"botName": "DataBot",
"initialText": "You can ask me for help rendering a file. Just type \"Render File\" or click on the mic and say it.",
"initialSpeechInstruction": "Say 'Render a file' to get started."
},
"polly": {
"voiceId": "Salli"
},
"ui": {
"parentOrigin": "",
"toolbarTitle": "File Processor"
},
"recorder": {
"preset": "speech_recognition"
}
}
Checkout the browser console for any errors. It helped me while I was trying this one out.
Here are some of the things that I experienced before I was able to try this out locally:
IAM permissions should be properly set such as cognito pools should have access to the Lex or that Polly should be able to access Lex.
Federated identities versus User Pools - I had to use Federated Identity pool.
I had the same issue. I followed this guide to solve my problem.
This issue is more related to setting proper permission for Amazon Cognito Pools. It can be checked from browser console as pointed out in the above answer.
The above link provide step by step guide.
I am trying to setup push notifications with PubNub on a react-native project. However calling the push.addChannels() method gives me the error 403 with "PNAccessDeniedCategory".
I have tried turning off the access manager but still get the same result. Not to sure if I am passing the correct params though.
I have setup push notifications with apple and uploaded the cert.pem file to PubNub.
pubnub.push.addChannels({
channels: ['ch.staff'],
device: 'ECID-OF-DEVICE-HERE',
pushGateway: 'apns' // apns, gcm, mpns
}, function(status) {
if (status.error) {
console.log("operation failed w/ error:", status);
} else {
console.log("operation done!")
}
});
I can send and receive standard messages without issue, it is just this which doesn't work.
I am following the docs here:
https://www.pubnub.com/docs/javascript/mobile-gateway-sdk-v4#Provisioning_devices_with_channel_names_per_lang_Examples
My main questions are.
Do I need to grant access to use this method and how do I do that?
Is the device field supposed to be the ECID?
PubNub Mobile Push + Access Manager
Access Manager is denying access because the client device's auth-key does not have read permissions (or it doesn't have an auth-key at all).
Either disable Access Manager until you are ready to implement permission granting to auth-keys for your clients by your server, or grant read permission for the client's auth-key for the channels it needs to register for push on (and optionally subscribe to).
For full details see the PubNub Nub operations/permissions mapping in the PubNub JavaScript SDK docs Access Manager tutorial.
The grant permissions would look something like this:
pubnub.grant(
{
channels: ['ch.staff'],
authKeys: ['clientAuthKey'],
read: true, // false to disallow
write: true, // false to disallow
},
function (status) {
// handle state setting response
console.log('Status', status)
}
);
I have a website that I'm getting back up after a year+ of being down. I haven't made any code changes, and I've got the site back up and everything is working as before except for the site/app sending email.
It's an ubuntu node.js server. It's hosted on Amazon and I had to create another instance and repoint the dns, etc. An example code snippet that used to work but now doesn't:
var emailServer = email.server.connect({user:"<my gmail>",password:"<mypw>",host:"smtp.gmail.com",ssl:true});
emailServer.send({
text: "Your username is: " + userName + ".",
to: emailAddress,
subject: "Activate Your a2zCribbage Account",
attachment: [...]
}, function(err, message) { if (err) console.log(err); });
When I first tried to send email the gmail account I use got a message "sign-in attempt prevented" Someone just tried to sign in to your Google Account <account> from an app that doesn't meet modern security standards.
I followed what Google said and changed the security to allow apps, but still nothing gets sent.
What am I missing? What other things can I try? Do ec2 severs not just allow email to be sent by default?
Gmail is not a platform for sending automated email. Just because you can doesn't mean it's designed for doing so.
AWS EC2 instances are also problematic for sending email; the ports may be blocked or throttled, you are certainly getting higher spam scores for doing so.
The canonical solution is to use AWS SES. Here's sample code and here's the documentation. There's also a simple third-party library.
I'm writing a simple SNS client that is meant to subscribe itself to an SNS topic and then listen for notifications. I can successfully submit a sns.subscribe request, but when I pick up the SubscriptionConfirmation POST message from AWS and try and respond using sns.confirmSubscription I get an AuthorizationError returned:
[AuthorizationError: User: arn:aws:iam::xxx:user/mv-user is not authorized to perform: SNS:ConfirmSubscription on resource: arn:aws:sns:us-east-1:xxx:*]
If I use exactly the same Token and TopicArn in a GET query to the server the subscription confirmation works fine, with no authentication.
Any ideas why it's not working? My SNS topic is wide open with publish/subscribe permissions set to 'Everyone'.
For reference, my code is something like this:
var params = {
TopicArn: topicArn, // e.g. arn:aws:sns:us-east-1:xxx:yyy
Token: token // long token extracted from POST body
};
sns.confirmSubscription(params, function (err, data) {
if (err) {
// BOOOM - keep getting here with AuthorizationError
} else {
// Yay. Worked, but never seem to get here :(
}
});
However, if I navigate to the URL similar to this in a browser (i.e. completely unauthenticated), it works perfectly:
http://sns.us-east-1.amazonaws.com/?Action=ConfirmSubscription&Token=<token>&TopicArn=arn%3Aaws%3Asns%3Aus-east-1%3Axxx%3Ayyy&Version=2010-03-31
The only differences seem to be the inclusion of 'Authorization' and 'Signature' headers in the programmatic version (checked using Wireshark).
Any ideas? Thanks in advance!
Update
In my code, if I just programatically do a simple GET request to the SubscribeURL in the SubscriptionConfirmation message this works fine. Just seems odd that the confirmSubscription API call doesn't work. Will probably stick to this workaround for now.
Update 2
Also get the same error when calling sns.unsubscribe although, again, calling the UnsubscribeURL in each notification works. Seems other people have run into that issue too but can't find any solutions.
I faced a similar issue while developing my application.
The way I ended up solving it is the following:
go to IAM and click on your user
go to the permissions tab and click on "Attach Policy"
use the filter to filter for "AmazonSNSFullAccess"
Attach the above policy to your user.
The above should take care of it.
If you wanna be fancy you can create a custom policy that is based on "AmazonSNSFullAccess" and apply it to you user instead.
The custom policy would be something similar to the following:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sns:ConfirmSubscription"
],
"Effect": "Allow",
"Resource": "YOUR_RESOURCE_ARN_SHOULD_BE_HERE"
}
]
}
The error says it all:
[AuthorizationError: User: arn:aws:iam::xxx:user/mv-user is not authorized to perform: SNS:ConfirmSubscription on resource: arn:aws:sns:us-east-1:xxx:*]
is basically telling you that the IAM user you're using to call ConfirmSubscription doesn't have the proper permissions to do so. Best bet is to update the permissions for that IAM user, specifically adding ConfirmSubscription permissions.
(Based on your comments, even though the documentation says otherwise, the error is pretty specific... might be worth following up directly with AWS about this issue, since either the error message or documentation is incorrect).