Forbidden - failed verifySignature

Developer Programs Support
1

I have set up some smart apps on both AWS Lambda and Webhook (Glitch) successfully. Now, I want to run my smart app on Webhook using my localhost. So, I have used Hookdeck to create a URL to receive events from the SmartThings platform and then send them to my smart app on localhost. I can successfully verify my app in the developer work space with the link that it sends to my smart app. The problem is that I can receive data from the platform, but when I want to send requests from my smart app to the platform using the API, it gives me the following error:

2022-05-28T21:43:39.145Z error: Forbidden - failed verifySignature
2022-05-28T21:43:39.147Z error: Unauthorized

I think it is because of the authorization token. The platform is sending request to the URL which has been generated by Hookdeck, but I am sending requests to the platform from my smart app not in the same way (i.e., through Hookdeck). How can I solve this issue?

2

Please, check if the workaround I included in this post works for you:

3

Thank you very much for your response. I have solved my problem by buying a personal DNS and making a tunnel from my localhsot to the DNS server. However, I have also tested your solution and still have the same problem. I share the first block of my code that may help you more.

const express = require('express');
const SmartApp = require('@smartthings/smartapp');
const server = module.exports = express();
server.use(express.json());

const app = new SmartApp();

server.get('/', (req, res) => {
  res.send('Turns on and off a light when something opens and closes');
});

/* Handles lifecycle events from SmartThings */
server.post('/', async (req, res) => {
    app.handleHttpCallback(req, res);
});

I have changed my post method to yours but nothing changed and still the same error:

server.post('/', (req, res, next) => {
    req.url = req.originalUrl;
    app.handleHttpCallback(req, res);
});
4

Mmm maybe the URL is modified somewhere else, have you checked the content of those variables to see if they are correct?

If you already solved the issue, then you can leave it as it is.

5

I checked both values, including req.url and req.originalUrl, before applying any modification, and both of them were:

/

6

Oh, I just checked and the team applied a change directly to the SmartApp SDK to avoid this issue, just make sure you have the latest version of the SDK:

So that workaround isnā€™t necessary anymore, you mentioned you solved it here:

So, thatā€™s the way to go.
Sorry for the confusion, I just remembered the case which was reported a long time ago and thought the workaround was still necessary but I was wrong.

7

Thank you very much for your help. Yes, the problem may rooted in the the SDK version because I have used one of the available simple examples, which is about controlling the smart light.

1 Like
8

Hello,

Iā€™m running into this exact same issue ā€¦ and it might not be the host name in my case. I am using these latest SDK that is mentioned above, and still failing.

What parameters exactly are used to create the signature? Iā€™m using Apache mod_proxy to provide my HTTPS endpoint, passing through to node.js / Node-RED (specifically this awesome project: GitHub - otaviojr/node-red-contrib-smartthings: Allows you to control your devices and get their status using NodeRed)

In doing my proxy I am passing through from:

https://myhost.com/nodered/smartthings/smartapp

to

http://myotherhost.com:1880/smartthings/smartapp

Now the URL is being passed through using the ProxyPreserveHost parameter, however I wonder if the port number is being used in the signature?

How can I see to better understand exactly what is being used in the signature that might be causing this?

9

This is the library used to check the HTTP signature in the SmartApp SDK: http-signature - npm
It would be useful to check that library separately in another project to see how it reacts.

10

Yes, Iā€™ve been Googling extensively to see how it is used by various projects. Iā€™m now building a way to trace the request payloads before and after the proxy to see how it is being modified to fail the verification.

Itā€™s funny how many issues customers are having with this, and how little has been done to rectify the issue or better support a work around. :-/

This is a pretty standard configuration to front-end a set of servers in a more commercial setting, but I guess that the APIs and webhooks werenā€™t originally designed to support business customers very well. :frowning:

Iā€™ll continue to update this thread as I continue to dig into this, and would have hoped that someone at Samsung in engineering could have provided a little more information to assist in resolving this.