Azure逻辑应用程序在Http查询参数请求中使用SAS令牌

Azure逻辑应用程序在Http查询参数请求中使用SAS令牌,azure,azure-storage,azure-logic-apps,Azure,Azure Storage,Azure Logic Apps,我正在创建一个Azure Logic应用程序,与Abbyy的OCR REST API配合使用 我使用通过路径创建SAS URI操作,该操作返回Web URLWeb URL将FQDN(包括SAS令牌)返回到我的blob Web URL作为查询参数传递给Http操作。在代码视图中,JSON的相关部分如下所示: "method": "GET", "uri": "https://cloud.ocrsdk.com/processRemoteImage?source=@{body('Create_SAS_U

我正在创建一个Azure Logic应用程序,与Abbyy的OCR REST API配合使用

我使用
通过路径创建SAS URI
操作,该操作返回
Web URL
<代码>Web URL将FQDN(包括SAS令牌)返回到我的blob

Web URL
作为查询参数传递给
Http
操作。在代码视图中,JSON的相关部分如下所示:

"method": "GET",
"uri": "https://cloud.ocrsdk.com/processRemoteImage?source=@{body('Create_SAS_Uri_by_path')?['WebUrl']}&language=English&exportformat=pdfSearchable&description=blah&imageSource=scanner"
uri的解析如下:

https://cloud.ocrsdk.com/processRemoteImage?source=https://mysaaccount.blob.core.windows.net/inbox/180730110047_0001.pdf?sv=2017-04-17&sr=b&sig=2IGMt1qDZthaBSyvD3WJ6T1zc36Wr%2FNoiB4Wki5Lf28%3D&se=2018-08-16T11%3A16%3A48Z&sp=r&language=English&exportformat=pdfSearchable&description=blah&imageSource=scanner"
这将导致错误(450):

然而,这没有任何效果。即,结果URI与上面相同。有趣的是,SAS令牌本身似乎使用了“逃逸百分比”

如果有人对如何解决或解决这个问题有任何建议,如果你能分享你的想法,我将不胜感激

有人知道LogicApp操作是否是开源的吗?如果是,GitHub链接是什么。然后我可以提出一个问题。

解决了它

基本上,我是在正确的轨道上,但我使用了
%26
当我应该使用
&
时,所以使用上面的代码,它应该是:

"method": "GET",
"uri": "https://cloud.ocrsdk.com/processRemoteImage?source=@{replace(body('Create_SAS_Uri_by_path')?['WebUrl'],'&','%26' )}&language=English&exportformat=pdfSearchable&description=blah&imageSource=scanner"
因此,URI读取:

https://cloud.ocrsdk.com/processRemoteImage?source=https://mysaaccount.blob.core.windows.net/intray/180730110047_0001.pdf?st=2018-08-17T10%3A55%3A38Z%26se=2018-08-18T10%3A55%3A38Z%26sp=r%26sv=2018-03-28%26sr=b%26sig=FTRoVgV7MRz5d5gTgrEs6D0QSy3268BqscZX1LHbJYQ%3D&language=English&exportformat=pdfSearchable&description=blah&imageSource=scanner
下一步:将XML正文转换为JSON

更新1 我已将替换值从
%2526
更新为
%26
(2018年8月17日)。很明显,我的内裤出了毛病。一定是想双倍逃跑,这是不必要的

虽然Microsoft似乎对SAS令牌进行了部分百分比编码,但我注意到他们使用
%3D
=
进行了百分比编码,但是Abbyy API似乎并不关心
=
。(邮递员的测试)

更新2 不确定更新1为什么起作用。这可能是因为我将访问策略设置为blob(仅针对blob的匿名读取访问),并将其设置回private尚未生效,或者可能是内容类型错误。不管怎么说,它起作用了,然后就没有了。好吧,它用
%26
替换
&
,没有问题,我也尝试跳过
=
,但端点不喜欢它,通过Postman和Logic应用程序进行测试

我的触发器实际上是一个C#
BlobTrigger
*Azure函数应用程序,我已经编写了生成SAS令牌的代码,因此我使用了dotnet的
Uri.EscapeDataString()
方法: 字符串fullUrl=cloudBlobContainer.Uri+“/”+blobName+sasToken

string escapedUri = Uri.EscapeDataString(fullUrl);

log.LogInformation($"Full URL: {fullUrl}");
log.LogInformation($"Escaped URL: {escapedUri}");

return escapedUri;
更新3 刚才看到这行代码,由Logic App designer创建:

"path": "/datasets/@{encodeURIComponent(encodeURIComponent('https://someaccount.sharepoint.com/sites/eps'))}/tables//items//attachments",
看起来
encodeURIComponent()
可能是一个函数,可以执行与
Uri.EscapedDataString
相同的操作,并将替换
replace()
函数。我还没有测试过

*
我之所以在触发器中使用函数应用程序,是因为成本太低。虽然有一个逻辑应用程序触发器在检测到新blob时运行,但它必须按计划运行。我的计划是消费,我读到微软在逻辑应用程序运行时收费,不管它是否做任何事情。嗯,每5秒钟触发一个任务是低效的,因为90%的时间它都没有任何事情可做。功能应用程序更适合我的要求,尽管如果应用程序已进入睡眠状态,显然会有约10分钟的“预热”时间。我可以接受

string escapedUri = Uri.EscapeDataString(fullUrl);

log.LogInformation($"Full URL: {fullUrl}");
log.LogInformation($"Escaped URL: {escapedUri}");

return escapedUri;
"path": "/datasets/@{encodeURIComponent(encodeURIComponent('https://someaccount.sharepoint.com/sites/eps'))}/tables//items//attachments",