I'm using plaid-ruby, try to add user with webhook:
Plaid.add_user 'connect',
params['username'],
params['password'],
params['bank_type'],
params['pin'],
{
list: params['list'],
login_only: true,
webhook: 'http://requestb.in/rrd6zbrr'
}
But with no luck, don't get any requests to requestbin.
Does Plaid support webhooks in development mode? Or maybe requestb.in is blocked ?
Plaid test environment does support webhooks. I reached out to Plaid support to ask specifically about Plaid Link since that is what I am using in my iOS app. Here is the response I received from Plaid:
Plaid Link does support webooks. Below is some sample code to illustrate:
<button id='linkButton'>Open Plaid Link</button>
<script src="https://cdn.plaid.com/link/stable/link-initialize.js"></script>
<script>
var linkHandler = Plaid.create({
env: 'tartan',
clientName: 'Test',
key: 'test_key',
product: 'connect',
webhook: '[WEBHOOK URL]',
onSuccess: function(public_token, metadata) {
// Send your public_token to your app server here.
},
});
// Trigger the Link UI
document.getElementById('linkButton').onclick = function() {
linkHandler.open();
};
</script>
Note that the product must be “connect” and that you must provide a webhook URL.
I was able to get webhooks working in my own environment (iOS client app, with Parse/Heroku backend), but I didn't use the test credentials - I used a real account. FYI, it took about 10 minutes between when I added the user and received a webhook back.
Related
I'm trying to use the Enhanced Direct Line Authentication Features so I can get rid of the Magic Number.
I just enabled this option and added the trusted origin (https://mychatbot.azurewebsites.net/ <- Not the real one, but is stored on Azure) to the DirectLine.
Then on the code of the website I request the token:
const options = {
method: 'POST',
uri: 'https://directline.botframework.com/v3/directline/tokens/generate',
headers: {
"Authorization": "Bearer MyDirectLineSecret"
},
json: {
User: {
id: "dl_" + uuid.v4(),
name: "UserTest"
},
trustedOrigins: ["https://mychatbot.azurewebsites.net/"]
}
Then I make the request for the token:
const response = await rp(options);
const token = response.token;
Like that I have the token and when I go to my bot website (https://mychatbot.azurewebsites.net/) I don't send the updateActivity request and can't send the user the welcome message.
I don't know if I'm doing something wrong about the DirectLine configuration.
Is there anything I should change? I'm using an app service for the bot framework and inserting directly the webchat uri in the trusted origins. I don't know if I am wrong in the request of the token.
You aren't doing anything wrong. This is a known issue in the DirectLine Connector Service, and the development team is currently working to resolve the issue. Essentially, the second conversation update is not being sent because the user id in the token is causing an error. For more details, checkout this issue on Github. I'll be sure to let you know when it is resolved as well.
In the meantime, I would recommend taking a look at the Web Chat Backchannel Welcome Event sample.
I am trying to build a discord bot and was wonderig if i can use AWS lambda for it. So far i haven't seen someone did it already so was confuse if its possible or not. Specially when lambda's aren't active all the time.
ancient question, but this is now possible, since discord starting providing outgoing webhooks a few weeks ago
(shameless self plug) i wrote a bit of a guide here
This is now possible but following an integration approach rather than the traditional bot approach. This differs as detailed below.
The slash commands official documentation gives us this info:
Slash Commands and Interactions bring something entirely new to the table: the ability to interact with an application without needing a bot user in the guild.
You are now able to receive interaction events via your preferred URL endpoint such as an AWS Lamba function, Firebase Cloud function, Azure Cloud function, etc.
This official receiving an interaction section tells us:
In your application in the Developer Portal, there is a field on the main page called "Interactions Endpoint URL". If you want to receive Interactions via outgoing webhook, you can set your URL in this field.
It is important to remember, though, that the data sent to the endpoint URL for interactions is not the same as running a bot client, in fact they make comment on that here:
In many cases, you may still need a bot user. If you need to receive gateway events, or need to interact with other parts of our API...
In my opinion, although We can post messages by AWS Lambda using Webhook, But we can not receive and process messages using AWS Lambda.
This is because discord does not provide message posting events.
here's a minimal implementation in nodejs that will give you an acceptable Interactions Endpoint URL:
serverless.yml
service: discord
variablesResolutionMode: 20210326
frameworkVersion: '2'
provider:
name: aws
runtime: nodejs14.x
stage: whatever
region: us-east-1
lambdaHashingVersion: 20201221
iam:
role:
name: discord
# https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-access.html
statements:
-
Effect: Allow
Action:
- 'ssm:DescribeParameters'
Resource: '*'
-
Effect: Allow
Action:
- 'ssm:GetParameter'
Resource:
- 'arn:aws:ssm:us-east-1::parameter/discord_token'
- 'arn:aws:ssm:us-east-1::parameter/discord_application_id'
- 'arn:aws:ssm:us-east-1::parameter/discord_public_key'
functions:
interactions:
handler: handler.interactions
environment:
DISCORD_TOKEN: ${ssm:/discord_token}
DISCORD_APPLICATION_ID: ${ssm:/discord_application_id}
DISCORD_PUBLIC_KEY: ${ssm:/discord_public_key}
events:
-
http:
path: interactions
method: post
cors: true
handler.js
'use strict';
const nacl = require('tweetnacl');
module.exports.interactions = async (event) => {
const verified = nacl.sign.detached.verify(
Buffer.from(event.headers['x-signature-timestamp'] + event.body),
Buffer.from(event.headers['x-signature-ed25519'], 'hex'),
Buffer.from(process.env.DISCORD_PUBLIC_KEY, 'hex')
);
const body = JSON.parse(event.body);
const response = {
body: JSON.stringify(
verified
? { type: body.type }
: { error: 'invalid request signature' },
null,
2
),
statusCode: verified
? 200
: 401
};
console.log(JSON.stringify({ event, response }, null, 2));
return response;
};
I'm using webchat to make make a simple web interface for my bot. My bot has authentication using BotAuth to connect to an Azure Active Directory.
When I log in it works fine but when I start a new converstation on another device it contiues my conversation when it should be a new clean conversation.
I used this https://github.com/Microsoft/BotFramework-WebChat but I doesn't work
$.ajax({
type: "POST",
headers: {
"Authorization": "Bearer " + "yupOGxl-odA.cwA.USk.zul_EXUwk54fWqKT_N8hmsWyXSWo5DHMYj0r7DQjaZI"
},
url: "https://directline.botframework.com/v3/directline/tokens/generate",
}).done(function (response) {
console.log(response)
BotChat.App({
directLine: {
token: response.token
},
user: { id: 'userid' },
bot: { id: 'botid' },
resize: 'detect'
}, document.getElementById("bot"));
});
when I start a new converstation on another device it contiues my conversation when it should be a new clean conversation.
It seems that you’d like to generate and pass a Direct Line Token to initiate BotChat. In this section: “Secrets and tokens”, you can find "A Direct Line token is a key that can be used to access a single conversation".
If you generate a new token via Ajax request and use it to initiate BotChat every time when new user logged in, a new conversation should be started with that token, you can use browser network tool to check the conversationId in response of starting a conversation.
On the other hand, if you use same Direct Line Token on another device/browser client(or tab), it will access the same conversation.
I have 2 users in my bot and somehow when I use it I'm logged in as the other person
As JasonSowers mentioned in his comment, you are specifying same userid when you initiate BotChat, you had better to get current logged-in user’s id and dynamically pass it to BotChat user property.
Note: In your code, you make ajax request for generating token based on your Direct Line Secret on JavaScript client side, which still expose the Direct Line Secret. Others can easily get your Direct Line Secret by checking your JavaScript code then put your bot on their website. If possible, you can create a backend service and put the code logic for generating token on server-side, which would help hide your secret from client side.
I have one website in pure HTML where I want to show YouTube live broadcast from my channel when I am live on YouTube.
$.ajax({
url: "https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2C+snippet%2C+contentDetails&broadcastType=all&mine=true&key={my-key}",
type: "GET",
success: function (result) {
console.log(result);
}
});
when I am using above code it's showing me login required.
Is there any way I can show my channel live video without login?
$.ajax({
type: "GET",
url: "https://www.googleapis.com/youtube/v3/search?part=id,snippet&eventType=completed&channelId={YOUR-CHANNEL-ID}&type=video&key={YOUR-API-KEY}",
async:true,
crossDomain:true,
dataType : 'JSON',
success: function(data){
$.each(data.items,
function(i,item)
{
var app =
'<div>\
<iframe src="https://www.youtube.com/embed/'+item.id.videoId+'" width="100%" height="auto" allowfullscreen></iframe>\
</div>';
$('.container').append(app);
});
}
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<div class="container">
</div>
i found a work around without OAUTH2.0 using API KEY and channel-ID using search API of YT DATA API.
you can change the eventType to live and completed.
items.snippet.id.videoId for video id and items.snippet.title for title of video.
Read documentation https://developers.google.com/youtube/v3/docs/search/list
You will need to use Oauth2 authentication for that API it appears.
https://developers.google.com/youtube/v3/live/registering_an_application
The page allows you to create two different types of credentials. However, all of the methods for the YouTube Live Streaming API require OAuth 2.0 authorization. Follow the instructions below to generate OAuth 2.0 credentials.
OAuth 2.0: Your application must send an OAuth 2.0 token with any request that accesses private user data. Your application sends a client ID and, possibly, a client secret to obtain a token. You can generate OAuth 2.0 credentials for web applications, service accounts, or installed applications.
See the Creating OAuth 2.0 credentials section for more information.
API keys: You have the option of including an API key with a request. The key identifies your project and provides API access, quota, and reports.
Note that all of the methods for the YouTube Live Streaming API require OAuth 2.0 authorization. For that reason, you need to follow the instructions above for generating OAuth 2.0 credentials. If you want, you can also send an API key, but it is not necessary.
Where I work we use Google Apps for Work. For the last 9 months we've been using the Gmail API (~2,000 requests per day) to pull in new emails for our support email accounts.
This is how we originally set it up:
Go to https://console.developers.google.com/project/
Click on the project (or create a new one)
Click on API's & Auth
Click on Credentials
Click on Create new Client ID
Click on Service account
Download a JWT (json) for the account.
Follow the node.js quickstart guide with an installed/native type token for the same account, and authorize it through the console. The JWT tokens did not work unless we did this step, once for each account.
We did this for each of our individual support email accounts to avoid having to turn on domain wide delegation for any of them in the admin console. We were then able to authenticate with the tokens using the officially supported npm library googleapis, similar to this:
var google = require('googleapis');
var jwtClient = new google.auth.JWT(
token.client_email,
null,
token.private_key,
['https://www.googleapis.com/auth/gmail.readonly'],
'supportemail#mycompany.com'
);
jwtClient.authorize(function(err, tokens) {
if (err) {
return cb(err);
}
var gmail = google.gmail('v1');
var requestOptions = {
auth: jwtClient,
userId: 'me',
id: messageId,
format: 'raw'
};
gmail.users.messages.get(requestOptions, function(err, response) {
if (err) {
return cb(err);
}
// do stuff with the response
});
});
Like I said, we used this for a long time and never had any issues. Yesterday around 10am MST every one of the accounts stopped being able to authenticate at the same time, with jwtClient.authorize() suddenly returning the error [Error: unauthorized_client].
I tried doing the same thing with a new token on a new service account (the web interface to get the token has changed quite a bit in the last 9 months), and it returns the same error.
The version of googleapis that we were using was 0.9.7, but we can't get JWT authentication to work on the newest version either.
We opened a ticket with the Google APIs support team, but the support person we spoke with had never read the Gmail API specs before and was ultimately unable to help us, so he redirected us here in order to get in touch with the API engineering support team.
We have noticed that authentication works if we enable the scope for domain wide delegation in the admin console, but we would prefer not to do that. We don't need to impersonate the accounts and would prefer to use an individual JWT for each account.
It turns out that the auth flow we were using was never supported, and probably was broken due to a bugfix on Google's part.
In the question comments #Brandon Jewett-Hall and #Steve Bazyl recommended that we use the installed app auth flow instead, as it allows for indefinite refreshing of access tokens and is supported.
More information about the different auth flows can be found in the Google API docs.