requestAccessWithPassphrase vs parseAccess

Developer Discussions troubleshooting
1

In the Storj WEB portal, I created:

  1. An Access Grant → long string
  2. An API Key → pair of “satellite address” and “restricted key”

both are created for the same bucket and with the same permissions (“read” and “list”).

Then, in NodeJS I call:

let access1 = await libUplink.requestAccessWithPassphrase(STORJSATURL, STORJKEY, STORJPASSPHRASE);
   
let access2 = await libUplink.parseAccess(STORJACCESSGRANT);

both return an access object like:

AccessResultStruct { access: { _handle: 1 } }

Now, when I list the objects in the bucket, access1 returns the list and access2 returns empty.

According to the documentation in the documentation , access2 should be the way to do it, but it is not working for me.

In case it is important, I am using:

  • Ubuntu 22.04.1
  • gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
  • go version go1.18.1 linux/amd64
  • NodeJS v18.12.1
2

Can you check the access grant with uplink access inspect <access2>. That will print out all restrictions that are set for this access grant.

It is possible to add 2 restrictions that basically contradict each other. The API key was already restricted to a specific bucket. Adding another bucket restriction could create an access grant that can’t be used for any bucket.

Now I don’t believe you have added contradicting bucket restrictions. What might have tricked you are the defaults. At least that is my common mistake.

1 Like
3

Thanks a lot for the support. What I get with the command above is:

{   
   "satellite_addr": "..............", 
    "encryption_access": {
        "store_entries": [  
            {  
                "bucket": "mydocs",
                "key": ".....................",
                "path_cipher": "ENC_AESGCM"
            }
         ], 
         "default_path_cipher": "ENC_AESGCM" 
    },
    "api_key": "...........................",
    "macaroon": {
        "head": "...................", 
        "caveats": [
            { 
                "disallow_writes": true,
                "disallow_deletes": true,
                "allowed_paths": [ 
                    {
                         "bucket": "mydocs" 
                    }
                ],
                "nonce": "H8ehiQ=="
            }
        ],  
        "tail": ".................................."
    }
}

where the “…” contain actual values.

4

Another common problem is the passphrase not matching. Sorry to ask this, but have you double checked that the passphrase you used in both cases is identical?

1 Like
5

That was it. Thank you!
If I understand correctly, the passphrase is used to derive the encryption key for the bucket. So the same passphrase must be used to create access grants or API keys for this bucket, correct?
In that case, I do not understand why Storj is giving the option to generate a new passphrase for an access grant to a existing bucket. It should inform that we must enter there the same passphrase that we used to create the bucket (?)

6

You can use different encryption keys. It is not required to use a single key for all files in a bucket. With a wrong key you just can’t decrypt the other files in that bucket. You could upload additional files.

One use case for that would be to build trust domains. Let’s say I want to give my wife a folder for her important files but don’t want to give her access to my files. Well, my wife is a bad example here. She knows where to find my encryption key. Anyway, I hope this example still explains it.

1 Like
7

OK. Understood. Thanks.
I guess that the passphrase for the bucket (the one required to create the bucket) is a sort of “default”.

8

I don’t think it’s “default” passphrase, as in it is in no way special, and in vast number of cases, discardable. You are going to create an access grant anyway to access the storage, and that’s where you are going to specify passphrase.

The UI today combines creating a bucket and “opening” it for web access with a specified passphrase. I think these two need to separated and the UI should not be asking for a passphrase when creating a bucket altogether.

I believe there is UX redesign in the works, discussed in another thread.

1 Like