I have created an app of type WEBHOOK_SMART_APP and now I want to add subscription of devices for this app and to call the create subscription API I need authorization token.
When I tried to login using OAuth with this app client Id and client secret. I am not receiving authorization code on the callback/redirect URI.
How can I overcome this. Do I have create some different type of app which can be used for both Oauth and webhok?
If you are using a WEBHOOK_SMART_APP the authToken and refreshToken are included in the request data sent by ST in the INSTALL and UPDATE lifecycles, which are the typical places one might handle subscriptions.
Temporary tokens lasting five minutes are also sent by ST with every EVENT lifecycle so you don’t necessarily need to worry about storing the tokens. If you do need to store the tokens because your app is doing stuff outside of the event cycle you will need to refresh the tokens if they haven’t been used for twenty-four hours (the lifetime of the authToken) and always before thirty days are up (the lifetime of the refreshToken). That’s the only time your app needs to mess around with client IDs and secrets. All the other OAUTH stuff is being done for you.
I don’t really know what you mean by the ‘login process of the user’ in the context of a WEBHOOK_SMART_APP. The INSTALL lifecycle occurs when an installed instance of the app is created in a SmartThings Location.
In more general terms, you after you ‘deploy to test’ the app in the Developer Workspace it appears in the Routines > Discover page in the mobile apps. When a user runs that app from there it will go through configuration and authorisation and if that is successful it will end up listed in the SmartApps section of the Routines page. That is when the INSTALL lifecycle occurs (followed by an UPDATE). If a user runs an instance of the app from that page (there can be more than one) then it goes through the configuration process again and that results in another UPDATE.
Okay, I want to deploy my app to test for that first I need to verify my app using CONFIRMATION lifecycle event. As specified in the docs I just call the confirmation url received in the request using the browser search bar but I received 401 on that and I’m not able to verify my app.
Actually you helped me by reminding me that my own test app (which is all I have as I’ve not found an actual need for an app yet) still automatically confirmed the URL, which isn’t really the best idea without extra checks on what is being confirmed and why.
Anyway I thought I’d try it for myself and I am getting a 403. So if you are doing anything wrong then I am too.
Update: There was a brief spell about 1-2 hours ago when my app registration was confirmed but it has since stopped again.
For you, I shall put myself through the hell of logging into the Developer Workspace to create an app. The walk-through in the CLI only handles API_ONLY and if you try to register an already registered app you get:
AxiosError: Request failed with status code 422: {"requestId":"6303857972782816616","error":{"code":"ConstraintViolationError","message":"The request
is malformed.","details":[{"code":"NotValidValue","target":"targetStatus","message":"CONFIRMED is not a valid value.","details":[]}]}}
Code: ERR_BAD_REQUEST
Right, after a delay as I discovered I’d broken my app this afternoon and just had to fix it, I am still getting a 403.
My app can automatically send an HTTP GET to confirm the URL but when it does I get a 403. However I have also copied the URL out of the CONFIRMATION data and tried it manually (using curl on the windows command line and a browser).
One extra datapoint. If I wait a few minutes for the token to expire and try again I get a 401 Unauthorized.
So it is definitely unhappy with something about the token and/or nonce.
UPDATE: I’ve just returned to this problem after a twenty minute diversion, triggered the registration from the CLI, and it worked (with the horrendous error message mentioned earlier).
Ok, so when you don’t get error 401 or 403, you get the 422 and the app isn’t confirmed either way?
I’ll see if I can replicate it with an API_ONLY app and check the logs of your request to see if there’s further info.
Thank you for taking the time to collect the info!
The 401 seems to mean you’ve not presented an unexpired token. This is either because it has expired (the Developer Workspace suggests that is after two minutes), or you have accidentally corrupted the URL.
The 403 seems to mean that you have presented an unexpired token but for some reason it is being accepted as authorisation.
The 422 is what you see when you use smartthings apps:register and your app registration is successfully confirmed. You also see it if your app was already confirmed before you ran the command (I don’t think it attempts to repeat the confirmation). The bottom line is that the 422 means your app is now successfully registered. The problem seems to be that the API thinks that "targetStatus": "CONFIRMED" isn’t valid.
So in summary:
401 is user error.
403 seems to be an unexpected failure.
422 using the CLI to register is a success but the API is being silly.
There isn’t anything to do wrong really. It’s a straight forward HTTP GET that you can post into a browser address bar if you want. A 403 suggests that the URL is correct and submitted in good time and that you have supplied a valid form of authentication. It just thinks it is the wrong authentication.
I do routinely have issues with authentication with the API, but so far it has only been with the /schema endpoint as that needs to be using a Cloudfront server in the right region, and only on my server because that sometimes considers an Amazon point of presence near Washington DC to be ‘closer’ than the Dublin one, so switching from Europe to the USA. I don’t normally have issues from home.
I can’t really see what there is to do differently. I’m back getting a 403.
Update: And ten minutes later it is working.
I note that currently api.smartthings.com is resolving to eight IP addresses for me. If I had to speculate I would say that not all of those eight are working properly.
I was certainly able to confirm that with one of the eight I got a 403, but about five minutes later a different one worked.