Hi Guys

Has something changed recently in the security of files? Issue has only appeared sometime in last couple weeks. Was previously working.

Collection of files - all set to public.

User 1 can query all files (as the creator of the files)

User 2 can only query files that they have been explicitly given permission to via a security group or _acl gr:true

Up until a week or two ago user 2 was able query any file that public:true. 

Has something changed recently? 

Should the public tag be enough to grant access to a user to query and stream the file?

What is the difference with the gr:true acl and public:true (couldn't find gr:true in the guildes sorry)

Cheers

Phil

Hi Pranav

I was only doing a query such as role=picture_type and not all the images were being returned. 

When I tried streaming by _id (where file has public = true) I am getting a 401

baas.kinvey.com/blob/kid_rywxSOz7g/9e701972-6aba-4ad5-9285-f6682c917d24?tls=false:1 GET https://baas.kinvey.com/blob/kid_rywxSOz7g/9e701972-6aba-4ad5-9285-f6682c917d24?tls=false 401 (Unauthorized)

tcode:401debug:""kinveyRequestId:undefinedmessage:"The credentials used to authenticate this request are not authorized to run this operation. Please retry your request with appropriate credentials"name:"InsufficientCredentials"stack:"Error: The credentials used to authenticate this request are not authorized to run this operation. Please retry your request with appropriate credentials↵ at t (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.5.min.js:13:2615)↵ at new t (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.5.min.js:13:7354)↵ at t.get (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.5.min.js:21:12328)↵ at https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.5.min.js:25:27315↵ at C (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.5.min.js:21:2507)↵ at R (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.5.min.js:21:2621)↵ at P (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.5.min.js:21:2410)↵ at MutationObserver.p (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.5.min.js:21:678)"__proto__:t

using 3.3.5. 

Reverted to 3.3.2 to make sure was not created by upgrading. Have replicated issue with 3.3.2

error message with 3.3.2

InsufficientCredentialsErrorcode:401debug:""message:"The credentials used to authenticate this request are not authorized to run this operation. Please retry your request with appropriate credentials"name:"InsufficientCredentialsError"stack:"Error: The credentials used to authenticate this request are not authorized to run this operation. Please retry your request with appropriate credentials↵ at InsufficientCredentialsError.KinveyError (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.2.js:2457:20)↵ at new InsufficientCredentialsError (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.2.js:2663:142)↵ at KinveyResponse.get (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.2.js:3410:17)↵ at https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.2.js:21708:26↵ at tryCatch (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.2.js:6226:13)↵ at invokeCallback (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.2.js:6241:14)↵ at publish (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.2.js:6209:8)↵ at MutationObserver.flush (https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.3.2.js:5937:6)"__proto__:KinveyError

User two used to be able to view this file. Strange 

Hope this helps.

Cheers Phil

Just been doing some more testing. The biggest issue this creates is that implicit users cannot access any files. In the case above most files are created with a group _acl so shouldn't be a problem (albeit should work). Where I have implicit users accessing files with public=true there is no other way to give them access (that I know of). 

Use Case: Authenticated user creates a report with text and images. Report is shared via url. Implicit user follows url, app collects and displays data and images based on id in unique ulr. Data is being returned but getting 401 for images. 

Cheers 

Phil :)

Hi Phil,

First, let me say that we have not made any recent changes to how files or permissions work. Second, I'd like to point out that as the devcenter mentions, downloading a file from Kinvey is a two-step process -- you first make a request to Kinvey to fetch the file's metadata, and then inspect the response to find the download URL, since the file itself is hosted on Google Cloud Storage.

Setting a file's _public attribute to true will result in the download URL being unsigned -- that means that the URL you get from Kinvey will not expire, and will be accessible by anyone on the internet. However, in order to fetch the file metadata and generate that URL, you still have to make an authenticated request to Kinvey, and the requesting user must have sufficient access to fetch the file's metadata. By default, files uploaded to Kinvey have ACLs that only allow the creator of the file access to read it. If you wish to allow other users access to this file, you can set its ACL just as you would any other entity (http://devcenter.kinvey.com/guides/security#Entitylevelpermissions).

So as you can see, the answer to your question about the difference between _acl.gr and _public is that the former controls access to the file metadata stored in Kinvey, and the latter allows public/unauthenticated access to the file's URL on Google Cloud Storage.

One way to solve the issue of implicit users accessing files is to set the file's _acl.gr property to true, allowing all users of the app to access it. If that does not fit your use case, another way could be to add all implicit users of the app to a certain user group, and allow the person uploading the file to specify whether this user group should be able to access the file -- if so, the file's _acl property can include this group. There are other ways, of course, and it all depends on your use case. I hope that with the information above you'll be able to find one that works for you.

Awesome reply, thank you. Now understand how file permissions work much better. 

The reason I thought something might have changed... The file that user 2 can not access is their profile image (it was uploaded by user 1 as they are test accounts). User 2 used to be able to retrieve the file meta data and access the _downloadURL. Their profile image stopped loading but hadn't even been in the code, that is how I noticed. Not sure what happened. 

I collect the file metadata every time as I was not sure how perpetual the ULR's were i.e. if you changed storage providers etc. Figured it was bad practice to store URL against the related entity in case there was ever a reason it changed. Am I wrong there and is it ok to be storing the downloadURL for public files against entities?

Looks like _acl.gr is the answer regardless. Thank you. Good post to have on the forums. 

Cheers