Merge lp:~jtv/gwacl/storage-ssl into lp:gwacl
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | 211 |
Merged at revision: | 211 |
Proposed branch: | lp:~jtv/gwacl/storage-ssl |
Merge into: | lp:gwacl |
Diff against target: |
148 lines (+22/-13) 4 files modified
HACKING.txt (+5/-0) storage_base.go (+5/-1) storage_base_test.go (+10/-10) storage_test.go (+2/-2) |
To merge this branch: | bzr merge lp:~jtv/gwacl/storage-ssl |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Julian Edwards (community) | Approve | ||
Review via email: mp+178513@code.launchpad.net |
Commit message
Access storage API through https, instead of http.
Description of the change
I was getting spurious authentication failures, but only on GetContainerPro
There was another way to fix just the hazard for the Data header: use the x-ms-date header instead. But the signing logic is fairly intricate and exceedingly hard to debug. When my first attempts here failed, I tried https instead.
We didn't expect https to be this easy. It was very difficult on the management-API side, what with Go's standard library not supporting renegotiation and Azure requiring it. And then there was the matter of certificates. But on the storage side, just changing the scheme in the base URL from http to https did the trick. No client-side certificates, no overrides, no renegotiation, and crucially: no more spurious authentication bug!
Jeroen
Long term we need to make this configurable but this is good for now! Please do file a bug about this.
One thing before you land - please write in the comments and perhaps README/HACKING that https is default for now because of your specific problem.
Cheers.