I have created a simple express server and added a /slack/receive route to handle webhook requests from the Slack events API:
// routes.js (which is used by my app defined in server.js)
...
let slack = require('./controllers/slack');
router.post('/slack/receive', slack.receive);
...
I then use Botkit to create a simple Slack application:
// controllers/slack.js
'use strict';
const logger = require('../config/winston');
// initialise firebase storage for botkit
const admin = require('firebase-admin');
var serviceAccount = require('../config/firebase.json');
admin.initializeApp({
credential: admin.credential.cert(serviceAccount)
});
var db = admin.firestore();
db.settings({
timestampsInSnapshots: true
})
// initialise botkit for slack
const botkit = require('botkit');
const controller = botkit.slackbot({
storage: require('botkit-storage-firestore')({ database: db }),
clientId: process.env.SLACK_CLIENT_ID,
clientSecret: process.env.SLACK_CLIENT_SECRET,
clientSigningSecret: process.env.SLACK_SIGNING_SECRET,
redirectUri: process.env.SLACK_REDIRECT,
disable_startup_messages: true,
send_via_rtm: false,
debug: true,
scopes: ['bot', 'chat:write:bot'],
})
controller.hears('Hello', 'direct_mention,direct_message', (bot, message) => {
logger.info(message);
bot.reply(message, 'I heard a message!');
})
exports.receive = (req, res, next) => {
res.sendStatus(200);
logger.debug(req.body);
controller.handleWebhookPayload(req, res);
};
The server initialises correctly, but as soon as the slack webhook receives a request the following error happens:
Could not load team while processing webhook: Error: could not find team T5VDRMWKX
at E:\Documents\upper-revolutions\node_modules\botkit\lib\SlackBot.js:169:24
at firebaseRef.doc.get.then.catch.err (E:\Documents\upper-revolutions\node_modules\botkit-storage-firestore\src\index.js:86:13)
at <anonymous>
at process._tickCallback (internal/process/next_tick.js:118:7)
So far I have found that:
Having/not having storage in the botkit slackbot makes no difference
The error happens within the handleWebhookPayload method as code within controller.hears() does not get executed
This error occurs because botkit needs some form of storage where it can store all the teams (channels and users too) and retrive it later on.
So, When your method handleWebhookPayload gets executed it calls another method called
findAppropriateTeam that will query for the specified team record in the storage provided by you (It might be mongoDB or a JSON file or other). The error is saying that you do not have any record in the storage with the id provided.
So this might implicate two things:
You did not provide a storage for botkit to work
You did not save the team id in the storage
The solution to the first problem is quite simple. You just need to install mongodb in your machine and then pass to botkit the MONGO_URL.
NOTE: I see that you are using the botkit simple storage and this might be the problem since I also have experieced some troubles with this kind of storage not saving records.
const controller = botkit.slackbot({
storage: 'mongodb//localhost:27017:/yourdb',
})
//OR
const controller = botkit.slackbot({
storage: process.env.MONGO_URL,
})
The possible solution to the second problem:
I will assume you are using botkit locally, so you must be using some tunneling like ngrok or localtunnel. In that case make sure:
You provided the redirect URL to Slack (Ex, https://your_url/oauth)
You accessed the https://your_url/login page
Botkit saves your team id on the provided storage when you access the /login route and authorizes the app. So if you skipped that part then botkit won't save your team id and therfore will throw an error when you receive events later on.
Check this like [https://github.com/howdyai/botkit/issues/938] for discutions on the topic
I hope this helps!
Related
The shopifyApi reference does not have a private app permanent access token property. I have a custom private app that is installed on only one store and I have the permanent access token so I don't need to oAuth every time I'm calling the REST API. Would be great to have a documented straight forward example of how to do this. The docs are hairy, IMO.
#shopify/shopify-api version: 6.1.0
Is the following close? I'm looking at the Session object and trying to understand how to load an offline session and set the Session with correct SessionParams.
import '#shopify/shopify-api/adapters/node'
import { shopifyApi, LATEST_API_VERSION, Session } from '#shopify/shopify-api'
const shopify = shopifyApi({
apiKey: 'myprivateappkey',
apiSecretKey: 'myprivateappsecret',
apiVersion: LATEST_API_VERSION,
isPrivateApp: true,
scopes: ['read_products'],
isEmbeddedApp: false,
hostName: 'shop.myshopify.com',
})
const sessionId = shopify.session.getOfflineId('shop.myshopify.com')
const session = new Session({
id: sessionId,
shop: 'shop.myshopify.com',
state: 'state',
isOnline: false,
accessToken: 'permanentAccessToken',
})
const client = new shopify.clients.Rest({ session: session })
On older v5 version of shopify-api, with two lines I could access any REST API, but I see this is now deprecated, So I'm trying to unravel offline sessions, but it doesn't make sense to provide the api key and api secret and then create a session using the permanent access token.
import Shopify from '#shopify/shopify-api'
const client = new Shopify.Clients.Rest(
'mystore.myshopify.com',
'permanentAccessTokenString',
)
See answer from Shopify here.
When creating the client in a private app, a dummy session can be created like so
const session = new Session({
id: 'not-a-real-session-id',
shop: 'shop.myshopify.com,
state: 'state',
isOnline: false,
});
const client = new shopify.clients.Rest({ session: session })
When config.isPrivateApp is set to true only the shop property is used by the client - the other three (id, state, isOnline) properties are ignored (but are required when creating a Session object).
config.apiSecretKey is used as the access token, and is read directly from the config (no need to set the accessToken property of the dummy session as it will be ignored).
Essentially, config.apiSecretKey is the permanent access token for a private app.
The scopes can be omitted, as it defaults to an empty scopes array internally anyway and (from a quick search through the library code) is only used when doing OAuth, validating sessions, etc., which won't apply to private apps.
As for the apiKey, while it's mostly used as part of the OAuth process, it is also used in a few other places (e.g., shopify.auth.getEmbeddedAppUrl()), so I'd recommend setting the apiKey to be that of your private app.
However, in my testing, scopes, even when isPrivateApp, are currently required. If you leave the array empty for scopes it will have a config error.
Also, my shopifyApi config mounts rest resources so that when you're in Shopify REST docs on the nodejs tab, you can easily use the REST resources examples on the nodejs to make calls, rather than creating a REST client and use standard post, etc.
Complete code to setup a private app connection to Shopify:
import '#shopify/shopify-api/adapters/node'
import { shopifyApi, LATEST_API_VERSION, Session } from '#shopify/shopify-api'
import { restResources } from '#shopify/shopify-api/rest/admin/2023-01'
const debug = process.env.FUNCTIONS_EMULATOR === 'true'
const shopify = shopifyApi({
apiKey: 'myprivateAppApiKey',
apiSecretKey: 'myPermanentAccessToken',
apiVersion: LATEST_API_VERSION,
isPrivateApp: true,
scopes: [
'read_customers',
'write_customers',
'read_fulfillments',
'write_fulfillments',
'read_inventory',
'write_inventory',
'write_order_edits',
'read_order_edits',
'write_orders',
'read_orders',
'write_products',
'read_products',
],
isEmbeddedApp: false,
hostName: debug ? '127.0.0.1:5001' : 'shop.myshopify.com',
// Mount REST resources.
restResources,
})
// Create a sanitized "fake" sessionId. E.g.
// "offline_my.myshopify.com".
const sessionId = shopify.session.getOfflineId('shop.myshopify.com')
const session = new Session({
id: sessionId,
shop: 'shop.myshopify.com,
state: 'state',
isOnline: false,
})
// Use mounted REST resources to make calls.
const transactions = await shopify.rest.Transaction.all({
session,
order_id: 123456789,
})
// Alternatively, if not using mounted REST resources
// you could create a standard REST client.
const client = new shopify.clients.Rest({ session })
As far as I know one best practice on Google Cloud is to not use Service Account keys as much as possible.
Here I have a Google Cloud function (nodejs) accessing Drive via Drive API (googleapis package v95.0.0), using a service account key (generated file via console).
What works:
const settings = require('./config/driveSA.json');
const options = {
googleKey: settings,
user: 'test#test.com' //user impersonification
}
const auth = gdriveUtils.prepareJwt(google, options);
const drive = google.drive({ version: 'v3', auth: auth });
const file = await drive.files.get({
fileId: fileId,
alt: 'media',
supportsTeamDrives: true,
});
What I want to achieve:
I want to improve this function, making it directly use the default service account inherited by the Cloud Function itself (which is the same referred by the key).
This approach always works when using '#google-cloud' related packages. Like for Storage we can simply:
const storage = new Storage();
const bucket = storage.bucket(bucketName);
What I tried:
Without specifying any auth obj:
const drive = google.drive({ version: 'v3' });
const file = await drive.files.get({
fileId: fileId,
alt: 'media',
supportsTeamDrives: true,
});
Using a not-really-documented method: getApplicationDefault
import { GoogleApis, Auth } from 'googleapis';
const adcResponse = await google.auth.getApplicationDefault();
const auth: Auth.GoogleAuth = new google.auth.GoogleAuth(adcResponse);
const drive = google.drive({ version: 'v3', auth: auth });
const file = await drive.files.get({
fileId: fileId,
alt: 'media',
supportsTeamDrives: true,
});
Unfortunately the package's documentation is always vague about the authentication part and always use keys in the examples. Is this something viable? Or am I forced to use a key in this case?
Thanks!
As user #DalmTo mentions, you are most likely mixing the accounts. Please keep in mind the fact that there are 2 service accounts involved when using the GCP services and the Google API services:
The GCP service account: Which Cloud Functions is using (most likely the App Engine default service account) when you invoke the function.
The Google API service account: Which has the privileges on your drive to perform all sort of actions.
If you would like to be able to perform all those activities in your drive, ensure you are using the Google API service account in your function, this is most easily done through the account key as you mention.
I am currently developing a dapp and I am integrating walletconnect.
I use this code for connecting:
const chainId = ContractService.getPreferredChainId();
const rpc = ContractService.getRpcAddress();
provider = new WalletConnectProvider({
infuraId: undefined,
rpc: {
[chainId]: rpc,
},
});
await provider.enable();
chainId is dynamically chosen based on if the app is in development mode or not. while in development it runs on chain id 97.
RPC is the same story, it just gets the binance smart chain RPC JSON provider.
Connecting works well, but I get the following error:
Any idea on how I can fix this without making an infura account? Or is that required..
I found out what the problem was.
make sure to add a chainId to the object like this:
new WalletConnectProvider({
infuraId: undefined,
rpc: {
1: "https://RPC_URL",
},
chainId: 1
});
Then it should work without issues, you can even omit the infuraId field
I am trying to make API (Lambda and API gateway) for sign in and verify auth using OTP for password-less authentication. The target is to make front end using angular and mobile application using Flutter but there is no support of AWS Amplify for flutter. So going through to create those API to serve my purpose. The frontend code(Auth.signIn and Auth.sendCustomChallengeAnswer) works great but using same code the verify auth API is not working. Sharing my code.
Sign In API:
await Auth.signIn(phone);
Verify Auth API: (Returned c['Session'] from DynamoDB which is stored in during signIn)
let otp = body['otp'];
const poolData = {
UserPoolId: '------ pool id -------',
ClientId: '------ client id -------'
};
const userPool = new CognitoUserPool(poolData);
const userData = {
Username: '+12014222656',
Pool: userPool
};
this.cognitoUser1 = new CognitoUser(userData);
this.cognitoUser1['Session'] = c['Session'];
await Auth.sendCustomChallengeAnswer(this.cognitoUser1, otp);
const tokenDetails = await Auth.currentSession()
response = {
'statusCode': 201,
'body': JSON.stringify({
message: 'Verification successful',
body:tokenDetails
})
}
After debugging frontend Auth.signIn response and Lambda API Auth.signIn response i investigated that an extra "storage" object returned when signing in from frontend and appended on this.cognitoUser1 before sending through Auth.sendCustomChallengeAnswer . See the attached screenshot below:
Is this the reason for successful verifying OTP from frontend? If so, what about making API (using Lambda and API gateway) and where it stores this storage object. Stuck here. Any suggestion and help will be appreciated.
You can set your own storage: https://docs.amplify.aws/lib/auth/manageusers/q/platform/js#managing-security-tokens
I have created an app using Feathers. I've been using this app for a while. It successfully hosts a blog and some other web pages. However, I've now reached a point where I need to protect some of my routes. For example, I want to have a route for my administrative activitivies (/admin), but I only want specific users to have access.
I know that I need to use the authentication and authorization components. However, at this time, I'm stuck on the authorization. My goal is to authenticate using OAuth via Google. However, to get past my authentication challenge, I'd be happy with just using a hard-coded username / password just to get the /admin route locked down (no, it's not deployed).
At the moment, I have
const app = feathers();
const routes = require('./routes');
app.configure(configuration(path.join(__dirname, '..')));
app.use(compress())
.options('*', cors())
.use(cors())
.use(favicon( path.join(app.get('public'), 'favicon.ico') ))
.use('/public', serveStatic(app.get('public'), staticFileSettings ))
.use(bodyParser.json())
.use(bodyParser.urlencoded({ extended: true }))
.configure(routes)
.configure(hooks())
.configure(rest())
.configure(socketio())
.configure(services)
.configure(middleware)
.configure(authentication())
;
// Setup the authentication strategy.
app.authenticate({
type: 'local',
'email': 'admin#feathersjs.com',
'password': 'admin'
}).then(function(result){
console.log('Authenticated!', result);
}).catch(function(error){
console.error('Error authenticating!', error);
});
My problem is, as soon as I add the block of code with the app.authenticate stuff, I get an error when I start my app. The error says:
TypeError: app.authenticate is not a function
If I remove app.authenticate(...); My app starts fine, but nothing is locked down. In my ./routes/index.js file, I have:
app.use('/admin', function(req, res) {
res.render('admin/index.html', {});
});
Which, renders just fine. It's just not restricted to an authenticated and authorized user. What am I missing? At a bare minimize I'm trying to understand how to get past the app.authenticate error.
In order to protect a route from unauthorized access you need to follow the documented usage of express middleware provided by the feathers-authentication package that is installed when you do feathers generate authentication.
Here's an example of authenticating the /admin route.
const auth = require('feathers-authentication');
app.use(
'/admin',
auth.express.authenticate('jwt'), // <-- this is a strategy, can local/jwt... etc
(req, res, next) => {
console.log("Request for '/admin'...");
res.render('admin');
}
);