LabVIEW Cloud Toolkits

cancel
Showing results for 
Search instead for 
Did you mean: 

Is It Possible to Make an AWS S3 Object Public?

Solved!
Go to solution

I'm using AWS S3 to host my NI Package feeds and until now I've done everything manually. i.e. Upload the package files, make the object public, etc.

 

Now I've started using the AWS Toolkit and I can upload objects just fine, but I can't find a way to make them public. The way I would do it manually is shown below:

CaseyM_0-1650654425221.png

 

This point of making these feeds public is so that they can be seen by NI Package Manager and its API.

 

As far as I can tell, the "Set Object ACL" doesn't allow me to make things public and I don't see any other VI that would do what I want, but hopefully I'm mistaken. Can anyone offer any suggestions?

 

Disclaimer: I'm relatively inexperience in dealing with AWS services so if there's a better solution to make things play nicely with NIPM, I'm all ears.

 

CLA CLED AF Guild
0 Kudos
Message 1 of 8
(3,410 Views)

I'm not AWS expert either, so take that as you will...

 

However from my understanding the toolkit, the Set Object ACL is implementing the PutObjAcl REST API function but only directly exposing the portion that allows you to specify a list of users to set their Permission for. I think what you are looking for is to used AWS's Canned ACL on your object to be public-read, and this is done by using the x-amz-acl header on the http PUT request. It's my best guess that the GUI option you've been using is one of the Canned ACL permissions. See this example from the documentation of how it works for the REST API, your goal is to do the same but in LabVIEW.



 

Sample Request: Access permissions specified using headers

The following request sets the ACL on the specified version of the object.

 

 
 


PUT ExampleObject.txt?acl HTTP/1.1
Host: examplebucket.s3.<Region>.amazonaws.com
x-amz-acl: public-read
Accept: */*
Authorization: authorization string
Host: s3.amazonaws.com
Connection: Keep-Alive 

 

 

My LabVIEW skills are a bit rusty, but I think this the spot where you would end up adding the headers if you modify the Set Object ACL.vi. If it works and you find an elegant way to expose this feel free to contribute your change to the toolkit on github 🙂

Danny_Funk_0-1650659073848.png

 

Danny Funk -- Senior Group Manager -- Software R&D -- NI
0 Kudos
Message 2 of 8
(3,393 Views)
Solution
Accepted by CaseyM

Couple of observations that may help.

Buckets can be Private or Public. Any object placed in a Public bucket should be Public and an object placed in a Private bucket should be Private.

The AWS Console can be used to look at the Bucket permissions, this show if Buckets can be set to Public. Object Permissions also show if objects can be set to Public. Object permissions are often inherited  from the Bucket.

In the Toolkit there is an example "Create New Bucket.vi" that has an unused input called "access control list" to set the Bucket Public or Private., The default is Private. There is another example "Upload File to Bucket.vi" that creates an object in the Bucket. This vi has a control called Public which should set the object to be Public or Private.

How are you intending to upload your objects ? Are you going to use the example vi's as a starting point or are you going to use the CLI (Command Line Interface) ?

 

 

Message 3 of 8
(3,366 Views)

I had totally missed the option to upload objects as public. That maybe exactly what I need - let me give it a shot.

CLA CLED AF Guild
0 Kudos
Message 4 of 8
(3,357 Views)

OK, this seems to have done the trick as far as uploading, but now there's a new problem.

 

The files I upload (NI Packages) seem to be failing their signature validation when I load them through NIPM.

 

Expected MD5 checksum '8bfff5293cdd6fff9262a65ec6f5c3ad' is different from actual checksum '314f8f389d362b199a24ec2f1c9d8544'. The package may be corrupted.

Before when I was uploading files manually, I didn't see this issue. Any clue as to why? Maybe some other option I'm not aware of that needs to be set?

CLA CLED AF Guild
0 Kudos
Message 5 of 8
(3,354 Views)

Actually, I can see that the file after being upload is, in fact, different. The number of bytes isn't quite right. I'll start another topic about this with more details.

CLA CLED AF Guild
0 Kudos
Message 6 of 8
(3,349 Views)

Please post link to new thread. I think I have already encountered this problem, the file upload is trimming CRLF's (0x0d, 0x0a) from the start and or end of file. Investigate with a hex editor. Solution is to use CLI to upload files.

0 Kudos
Message 7 of 8
(3,341 Views)