One idea is that the problem has something to do with how the webhook sas token function parses the URL getting the scope needed.
Or could there be any other issue causing the problem?
Also, it would much appreciated if anybody from particle could describe how the Azure SAS token function works, especially related to extracting the scope from the URL.
I did several experiments concerning this and finally ended with the same result: “IOT hub does not correspond to host name”.
What I also metnion is that if I use the pattern https://{IoTHubName}.azure-devices.net/devices/{deviceId}/messages/events?api-version={api-version} (see https://msdn.microsoft.com/en-us/library/azure/mt590784.aspx) with non-existing deviceId, the hook finishes with the result like “device id does not exist in IoTHubName”. Thus it seems IoT Hub is reachable and communicates “somehow”. However, if I use existing deviceId, I end with “IOT hub does not correspond to host name”,
So, lets open a discussion concering this issue, the goal is clear: “prepare easy-to-use solution for publishing/receiving messages to/from Azure IoT Hub via Webhooks and Particle devices”.
Yes it works. However, SAS is fixed - I mean, SAS is comupted somewhere else and is filled in the webhook. My idea is to have support for computing SAS inside Webhook infrastructure based on Policy name and Key.
Setting the SharedAccessSignature statically in the Authorization http header works fine. But that would require a long expiration time in a real world scenario.
I think that one solution might be for particle adding an optional scope parameter to the webhook azure_sas_token function where it would be used instead of getting it by parsing the url.
Unfortunately Azure IoT Hub doesn’t seem to have a nice way to just view errors thrown (that would make this a lot easier). When I setup diagnostics, nothing is being stored from the failed requests. Going to keep digging, but thought I would ask in case someone has seen this.
@jirkakoutny I think I got my part figured out through deep diving into Azure, but SAS token is messing me up. How do you generate your SAS token for the Photon? Do you use the Azure SDK on some other client and then pass the parameter into the url?
Sorry I didn’t see this thread earlier. It was my understanding that Azure IOT Hub expected a unique SAS key per device, and some special registration step. I haven’t had time to add special support for that particular service, and the Event Hubs auth token tends to work for most.
We generate the azure sas token by using Microsoft’s prescribed signed authentication header formula.
Essentially it’s this:
#pseudocode:
1.) create a timestamp sometime in the future (usually about an hour)
2.) URL encode the target url, include the expiration time.
3.) Create a sha256 hmac using the azure sas key as the key. Use the encoded URL + time as the plaintext, grab the signature of that hash.
The auth token is then:
"SharedAccessSignature "
+ "sr=" + url encoded url
+ "&sig=" + url encoded hash signature
+ "&se=" + expiration timestamp
+ "&skn=" + name of azure sas key
I think that the reason this is only working with older Azure EventHubs and not the newer eventhubs in Azure IoT Hub is that the webhooks built in “azure_sas_token” functionality are parsing the destination URL and making assumptions on its structure. See my first post in this thread.
If you have the opportunity please look into this again Thanks.
@vandelay - I’m trying to set up a webhook to Azure also. Not having much luck. Did we find a solution? (i’m very new to all of this so apologies if I’m missing the blindingly-obvious).
As far as i understand it the same still applies. The particle built-in webhook functionality to generate the SAS token on the fly (runtime) only works with Azure Event Hubs and not with the Eventhub in Azure IOT Hub.
To get it working i had to generate the SAS token offline (devtime) and then statically insert it in the http header “Authorization” which is only ok for testing. Se example further up in this thread if you want to try that.
The real solution would probably require Particle to change their “azure_sas_token” function and make it more configurable. @Dave ?