gt;>>>>user
>> >>>>> >>>to
>> >>>>> >>> > > >> download a template from S3, just like how Amazon
>>provided
>> >>>>>user
>> >>>>> >>>a way to
>> >>&
Sanjeev,
Thanks for the confirmation.
Jessica
-Original Message-
From: Sanjeev Neelarapu
Sent: Thursday, July 18, 2013 11:05 PM
To: dev@cloudstack.apache.org; Jessica Wang
Cc: Edison Su; Thomas O'Dowd
Subject: RE: Query String Request Authentication(QSRA) support by S3 provider
> >extractIso API.
> >
> >Jessica
> >
> >
> >-Original Message-
> >From: Min Chen
> >Sent: Wednesday, July 03, 2013 5:53 PM
> >To: dev@cloudstack.apache.org; Thomas O'Dowd
> >Cc: Jessica Wang
> >Subject: Re: Query Strin
t: Re: Query String Request Authentication(QSRA) support by S3 providers
Thanks Jessica. Tom, did you still see the issue?
-min
On 7/8/13 1:20 PM, "Jessica Wang" wrote:
>Min,
>
>> would you please take a look at this to see if UI can disable
>>decoding in disp
;I just changed UI to not decode the URL returned in extractTemplate,
>extractIso API.
>
>Jessica
>
>
>-Original Message-
>From: Min Chen
>Sent: Wednesday, July 03, 2013 5:53 PM
>To: dev@cloudstack.apache.org; Thomas O'Dowd
>Cc: Jessica Wang
>Subject: Re:
hen
Sent: Wednesday, July 03, 2013 5:53 PM
To: dev@cloudstack.apache.org; Thomas O'Dowd
Cc: Jessica Wang
Subject: Re: Query String Request Authentication(QSRA) support by S3 providers
Jessica, would you please take a look at this to see if UI can disable
decoding in displaying this download templat
my "corrected" understanding is
>>>>correct,
>>>>I
>>>> >>>would
>>>> >>> > > >>like
>>>> >>> > > >> >to amend my thoughts. Namely, I would like to see the
>>>>driver
>>&
far as I can see, the objects in
>>>the
>>> >>S3 stores (AWS or Cloudian) are complete and from my perspective
>>>"ready"
>>> >>to download/use. It sounds like a bug when registering the template.
>>> >>
>>> >>Tom.
>>> &
a Wang
> Subject: Re: Query String Request Authentication(QSRA) support by S3
> providers
>
> Hi Tom,
>
> I can reproduce this issue using Cloudian, after investigation, I
> realized that this is a bug in Amazon SDK we have used, based on this
> thread:
> http:/
t simply both sides of the
>> >>>operation
>> >>> > > >>by
>> >>> > > >> >allowing the DataStore information to be treated opaquely
>>until
>> >>>it is
>> >>>
The reason that the 2 templates("MyTiny", "AnotherTiny") have no
> >>>download button is because they are not ready
> >>> (i.e. their "isready" property is false).
> >>>
> >>> Download button is only available when "isready&
that case, how do we keep backward compatibility of
>>> > > >>extractTemplate
>>> > > >> >> api, which requires a URL in the response?
>>> > > >> >>
>>> > > >> >> Thanks
>>> > > >
n "isready" property is true.
>>
>> Jessica
>>
>> -Original Message-----
>> From: Thomas O'Dowd [mailto:tpod...@cloudian.com]
>> Sent: Thursday, June 27, 2013 8:04 PM
>> To: Min Chen
>> Cc: dev@cloudstack.apache.org; Jessica W
riginal Message-
> From: Thomas O'Dowd [mailto:tpod...@cloudian.com]
> Sent: Thursday, June 27, 2013 8:04 PM
> To: Min Chen
> Cc: dev@cloudstack.apache.org; Jessica Wang
> Subject: Re: Query String Request Authentication(QSRA) support by S3 providers
>
> Hi Min/Jessi
is true.
Jessica
-Original Message-
From: Thomas O'Dowd [mailto:tpod...@cloudian.com]
Sent: Thursday, June 27, 2013 8:04 PM
To: Min Chen
Cc: dev@cloudstack.apache.org; Jessica Wang
Subject: Re: Query String Request Authentication(QSRA) support by S3 providers
Hi Min/Jessica,
I atta
omponents with actual
> > >>resources
> > >> >>> rather String references. Second, the current interface seems to
> > >> >>>appears
> > >> >>> to assume that an http/https URL will be returned. With I/O
> > >>stream
nderlying client
> libraries
> > > >> >>> provide. I/O streams provide a higher-level abstraction that
> allows
> > > >> >>> drivers to provide the orchestration components with actual
> > > >>resources
> > > >>
with actual
> > >>resources
> > >> >>> rather String references. Second, the current interface seems to
> > >> >>>appears
> > >> >>> to assume that an http/https URL will be returned. With I/O
> > >>streams,
> > >> &
gt;> >>> to assume that an http/https URL will be returned. With I/O
> >>streams,
> >> >>>we
> >> >>> can support any client library capable of using the standard I/O
> >> >>> framework -- enabling us to support other pr
us to support other protocols for downloading
>> >>> templates in the future (e.g. RBD, local filesystem, NBD, etc).
>> >>>
>> >>> Thanks,
>> >>> -John
>> >>>
>> >>> On Jun 18, 2013, at 1:11 PM, Min Chen
gt;> -min
> >>>>
> >>>> On 6/18/13 8:29 AM, "Min Chen" wrote:
> >>>>
> >>>>> Yes, current code is in
> >>>>>S3ImageStoreDriverImpl.createEntityExtractUrl,
> >>>>> which has a security issue
wrote:
>>>>
>>>>> Yes, current code is in
>>>>>S3ImageStoreDriverImpl.createEntityExtractUrl,
>>>>> which has a security issue mentioned in CLOUDSTACK-3030. I am going
>>>>>to
>>>>> change it to use generatePre
am going to
>>>> change it to use generatePresignedUrl api from AWS S3 api.
>>>>
>>>> Thanks
>>>> -min
>>>>
>>>> From: John Burwell mailto:jburw...@basho.com>>
>>>> Date: Tuesday, June 18, 2013 8:07 AM
&g
t;
>>> Date: Tuesday, June 18, 2013 8:07 AM
>>> To: Min Chen mailto:min.c...@citrix.com>>
>>> Cc: Thomas O'Dowd mailto:tpod...@cloudian.com>>,
>>> "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
>>> mailto:d
>> To: Min Chen mailto:min.c...@citrix.com>>
>> Cc: Thomas O'Dowd mailto:tpod...@cloudian.com>>,
>> "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
>> mailto:dev@cloudstack.apache.org>>
>> Subject: R
od...@cloudian.com>>,
>"dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
>mailto:dev@cloudstack.apache.org>>
>Subject: Re: Query String Request Authentication(QSRA) support by S3
>providers
>
>Min,
>
>Is the code checked into the object_st
3 8:07 AM
To: Min Chen mailto:min.c...@citrix.com>>
Cc: Thomas O'Dowd mailto:tpod...@cloudian.com>>,
"dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
mailto:dev@cloudstack.apache.org>>
Subject: Re: Query String Request Authentication(QSRA) suppo
t for easy consumption. By using this method, I think that I
> don't need to change ACL of S3 object to open a security hole.
>
> Thanks
> -min
>
> From: John Burwell
> Date: Monday, June 17, 2013 7:38 PM
> To: Min Chen
> Cc: Thomas O'Dowd , "dev@cloud
RA mentioned by Tom, by wrapped in
> AmazonS3Client for easy consumption. By using this method, I think
> that I don't need to change ACL of S3 object to open a security hole.
>
>
> Thanks
> -min
>
>
> From: John Burwell
> Date: Monday, June 17, 2013 7:38 PM
&g
Date: Monday, June 17, 2013 7:38 PM
To: Min Chen mailto:min.c...@citrix.com>>
Cc: Thomas O'Dowd mailto:tpod...@cloudian.com>>,
"dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
mailto:dev@cloudstack.apache.org>>
Subject: Re: Query String Reque
Min,
Why are we mucking with ACLs at all? The best security practice would be
to create a bucket for CloudStack's use and assign it a dedicated access
key and secret key pair with read/write access only to that bucket.
Requiring an administrative account to an object store opens an
unnecessarily
Hi Min,
RiakCS seems to support QSRA according to:
http://docs.basho.com/riakcs/latest/cookbooks/Authentication/#Query-String-Authentication
I'm not sure about other S3 AWS compatible providers. Perhaps others on
the list can give feedback? I had a quick look at Ceph for example and
they don't ex
Tom filed a very good bug for ACL setting change on S3 object when users issue
extractTemplate API (https://issues.apache.org/jira/browse/CLOUDSTACK-3030),
and his recommendation of using Query String Request Authentication (QSRA)
alternative sounds like a right approach to fix this bug. Before
33 matches
Mail list logo
