[
https://issues.apache.org/jira/browse/CLOUDSTACK-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090922#comment-14090922
]
Marcus Sorensen commented on CLOUDSTACK-5512:
---------------------------------------------
Yes, it might look like this:
https://marcus.storage.dc-extras.com/image.qcow2?AWSAccessKeyId=UU94DAQ7HH03OC4KYPRO&Expires=1407514272&Signature=0tMvemt0XTHowwTDZEz%2FhaDTBMs%3D
The use case for this would be if someone tries to host a VM template on S3, or
perhaps a fancy script-generated template where the URL does not end in the
right file extension. In the past we have tricked this by just adding
"&format=qcow2" to any URL.
In 4.4 we added a 'TemplateUtils' utility that actually looks at the first
megabyte during download and validates that it matches the format selected, so
this check could be removed, probably.
> template format name checking is crude and doesn't work with advanced URLs
> --------------------------------------------------------------------------
>
> Key: CLOUDSTACK-5512
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5512
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Affects Versions: 4.0.0, 4.1.0, 4.2.0
> Reporter: Marcus Sorensen
> Fix For: 4.4.0
>
>
> Template name checking currently just looks at the very end of the url
> string. e.g.:
> private void checkFormat(String format, String url) {
> if((!url.toLowerCase().endsWith("vhd"))
> This breaks functionality such as registering a template via an S3 pre-signed
> URL, or anything where the file extension is not the last part of the URL. We
> should at least attempt to parse the URL for filename vs parameters.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
