I’ve posted on other threads and I haven’t gotten a lot of responses because the threads were old, so please forgive the duplicate post. I need to get my apps install ID as well as an access token. I’ve followed every post I can find, but the final result is I get an error when I attempt to get the token:
Oh No! Something Went Wrong!
Error 500: Internal Server Error
Reference Id d5868a32-020b-4097-a204-79953b0fdf09
Date Mon Aug 14 23:40:04 UTC 2017
Any advice or assistance would be fantastic.
What documentation are you using?
If you post your code, it is a lot easier for someone to spot where you may have a glitch…
You can’t “callback” to the SmartThings server.
Your callback must be an internet accessible URL to your own device or server.
I thought I read another post where someone was showing how this was done, but I can’t find the thread now. Oh well…
So basically I need a webapp that goes to a smartThings app so I can make a call to get a device state? I really didn’t want to have to do that since I am not a developer. ( I can hack code like a good linux admin, but my developing skills are poor )
Take a look at this alternate SmartThings method:
That is exactly what I needed! Thank you!
The callback doesn’t have to be internet accessible. It just needs to be something the browser can access. For example, some mobile apps use internal app URIs as callbacks and
localhost is frequently used in development.
Really? That’s great to know, but difficult for me to comprehend.
I assumed SmartThings issued the Access Token asynchronously and thus required a destination (receiving) URL to call.
Now that I think about it, I guess that isn’t necessary the architecture used…? But then, why can’t the callback be NULL?
The diagram from the IETF spec is illustrative on this topic.
The user’s browser (User Agent) acts as a proxy of sorts for getting the Authorization Code to the Client (app/dev server). The redirect happens in the user’s browser and the Authorization Code is passed by the users browser to the Client (app). Then in the next step, the Client (app) makes a call to the Authorization Server (SmartThings) to get the authorization token and the Authorization Server responds with the token.
This means the developer’s server doesn’t need to be externally accessible by the Authorization Server (SmartThings), it just needs to be able to make outbound calls to the Authorization Server.
This means that the Client (app) can sit behind a firewall and only be internally accessible while still being able to make outbound calls to the SmartThings to control your things and get status updates.
In step D/E of the diagram above, the Client app makes a request to get the Authorization Token using the Authorization Code and SmartThings responds (synchronously) with the Authorization Token.
The IETF spec is quite clear on this and expects the Authorization Server to include the Authorization Token in it’s response to the request from Step D, but you’ll find that some diagrams and even some implementations actually send the Authorization Token directly to the redirect_uri rather than responding directly to the Client request.
The spec states that if a redirect_uri is used in step A, then the redirect_uri must be included in step D and must match. It’s a safeguard of sorts.
Well… this is educational, thanks!
I just ran an OAuth based installation and my browser very briefly flashed “uploading” at the very last moment. I wonder if that is related to any of the steps. I should observe that with debugging enabled. We use a server (not the client) for callback, … well… I’m just musing to myself.