Access Policies Management Window does a forced update on Expiry Dates when Policy has a blank expiry

[euandekock]

Storage Explorer Version: 1.4.3, 1.4.4
Platform/OS Version: Fedora Linux and Windows versions
Architecture: x64
Regression From:

Steps to Reproduce:

1. Create an access policy in code for a specific Container/Folder with no specified expiry date.
2. Open Azure Storage Explorer, Select the same Container/Folder
3. Select "Manage Access Policies..."
4. Note that the Access Policy now has a defaulted Expiry date set to current date and time.
5. Click "Save", even though we have not edited any Policy.
6. The Policy now has an expiry date that has already passed - all SAS keys are invalidated.

Expected Experience:

The Policy with no expiry date should continue to have no expiry date unless I specifically assigned one.

Actual Experience:

The expiry date is forcibly set to the current date and time, invalidating all SAS keys assigned to it.

[bengavin]

This issue (and other issues related to SAS token management) continues to cause issues with our development team accidentally blowing away our SAS tokens on our test environment on numerous occasions. This dialog should support creating Access Policies with no start/expiry time and should retain the 'unset' nature of these properties when hittting 'Save'. The Azure portal does this just fine, and I don't understand why this dialog is any different. It feels like a case of over-validation.

As a related issue, when creating a SAS token from these same 'unset date' policies, we should (must) be allowed to set the start/expiry date, but currently those dialog entries are disabled when selecting a stored access policy.

[MRayermannMSFT]

Yep this is definitely a bug. We'll get this fixed as soon as we can.

[craxal]

We validate expiry times, because SAS tokens based on access policies without an expiry time aren't actually usable when attaching to resources in Storage Explorer (see #1092). With that said, we did not take into account that the SAS tokens themselves can have start/expiry times.

@bengavin, as a workaround, I would expect your "blown away" SAS tokens could be easily fixed by editing the expiry times of your access policies. Does this not work?

[bengavin]

@craxal - Yes, that works, but it must be edited through the azure portal for now (or the azure CLI). We require that the access policy have no start/expiry dates, as our code generates SAS tokens with explicit start/end dates and the Azure tooling can't create SAS tokens with expiry dates if the underlying access policy has expiry date. This is also why the SAS token generation doesn't work within the storage explorer app, as picking a policy ends up with no facility to set the expiration date :)

The 'blown away' aspect is most likely our fault (overzealous troubleshooting), but the underlying problem is that the policy was edited in a tool that doesn't support what we need.

[craxal]

Thank you for the input! It looks like we'll need to do some hefty work to our SAS/access policy dialogs to get this all working. But it's on the radar. Stay tuned.

[MRayermannMSFT]

Fixed merged into master. Will be available in 1.8.0.