Open ATidmore opened 4 years ago
Follow up: using the ContainerPermissions
(READ, WRITE, LIST attributes) class versus the AccountPermissions
class seems to generate a matching SAS token.
I have confirmed the SAS token it generates is valid for my requirements.
Can the doc string be updated to reflect the necessity to use ContainerPermissions
class?
Hi @ATidmore, thanks for reaching out!
AccountPermissions should work fine. I was able to generate the right SAS token with it:
'se=2019-07-29T20%3A35%3A59Z&sp=rwl&sv=2018-03-28&ss=b&srt=co&sig=9Tdj6D1c6ldSh9R2KUJ/2WZUzKNw4R/mJuddwMUKIOs%3D'
@ATidmore could you please test again with AccountPermissions?
@zezha-msft thank you for following up, per my original post I have used AccountPermissions but did not get the expected results.
Which service(blob, file, queue) does this issue concern?
Requirement is for
blob
onlyWhich version of the SDK was used? Please provide the output of
pip freeze
.azure-storage-blob==1.4.0
What problem was encountered?
When comparing the output of
azure.storage.blob.BlockBlobService.generate_account_shared_access_signature()
with the same parameters, the SAS token generated does not match what the Azure Portal generates.`bbs_acct_token = bbs.generate_account_shared_access_signature( ResourceTypes.CONTAINER + ResourceTypes.OBJECT, AccountPermissions.READ + AccountPermissions.WRITE + AccountPermissions.LIST \
+ AccountPermissions.CREATE,
Generates:
se=2019-07-28T16%3A07%3A27Z&sp=&sv=2017-04-17&ss=b&srt=co&sig=%2BTO1J2/zNIYlvhEonRkFRTZPkNvm...
*There seems to be an issue with the
sp=
value - am expectingrwl
but there is nothing.From the Azure Portal (using the same parameters) the SAS Token looks like:
?sv=2018-03-28&ss=b&srt=co&sp=rwdlac&se=2019-07-28T22:45:47Z&st=2019-07-28T14:45:47Z&spr=https&sig=PMu3KnDRV7VzOig1ewVP2T4TU0qowmEn...
Have you found a mitigation/solution?
No - the requirement is to generate the token thru the storage API