AccessDenied error when trying to write raw bytes to a FilesContainer I own

[Shane]

The following flow:

let context = new Safe();
let authToken = context.auth_app("test", "test", "test"); // $~/: safe auth allow ...
context.connect("test", authToken);
context.files_container_add_from_raw(new Uint8Array([104, 101, 108, 108, 111]), "hnyynyi95mmtqr9pcwnoft9xwo61w3iu7qmhd415yngihakc1ajrgkiq4ebnc/test", true, false, false);

- Uncaught Error: internal error in Neon module: Failed to add file form raw bytes to FilesContainer: NetDataError("Failed to UPDATE Sequenced Append Only Data: Error(CoreError(Access denied - CoreError::DataError -> AccessDenied))")
    at <anonymous>:1:3

// hnyynyi95mmtqr9pcwnoft9xwo61w3iu7qmhd415yngihakc1ajrgkiq4ebnc is the FilesContainer for safe://phantom, I definitely own it and can push files to it through the CLI

Make the assumption that all of the calls above are performed asynchronously, I’ve just simplified it for here, but I can confirm that all of the calls are working (I’m able to, for instance, create a new NRS totally fine.)

I get this error: AccessDenied, despite my current safe auth login user being the same as the one who owns this NRS:

$~/Sites/safe/phantom/www.phantom/: safe files sync dist/ phantom --recursive --update-nrs
FilesContainer synced up (version 3): "phantom"
+  ../dist/css/app.07ae894a.css          safe://hbhyyyd9fr6k7gurqnyactmmf4kz4u7w5ciby1goe4nd6gwpue8fjea4co
+  ../dist/font/opensans-bold.woff2      safe://hb1ybonrnp1fi9eb8i5kapthrkmbmsg6emkizo7aidrhdr86i1hreybjuk
+  ../dist/font/opensans-regular.woff2   safe://hb1ybon4qenewitcf1wwromng8t5ef1iu997mugpn6qppp39uqssbcadd1
+  ../dist/js/app.a743f172.js            safe://hbkygyd7tdgafzfa9rufrjih3mchxj83zejo6tdwgfs5qppnojtehijqjq
+  ../dist/js/chunk-vendors.3db546be.js  safe://hbkygyn4p8o5ewj87rgodbc4sj8yufgokyodkb49q7mrcobm6ji5ntyci7

As such, the error seems exclusively to exist within the nodeJS / browser context. Here is the dog output, you’ll notice the XorURLs all match up.:

$~/: safe dog safe://phantom
Native data type: PublishedSeqAppendOnlyData
Version: 3
Type tag: 1100
XOR name: 0x7fb5ae2e27daca0a058fdf487a54cd67d72f83d4b6011abcc2992c2486555da4
XOR-URL: safe://hnyynyi95mmtqr9pcwnoft9xwo61w3iu7qmhd415yngihakc1ajrgkiq4ebnc?v=3

Resolved using NRS Map:
PublicName: "phantom"
Container XOR-URL: safe://hnyydyzu45p8z38qcr5k9dc41u7adkkasrwpyzt1cw7ehhxrm9b8bfpnscbqh
Native data type: PublishedSeqAppendOnlyData
Type tag: 1500
XOR name: 0xe7adb4f7c9dcc26d5f1b3529f70352b16251a0bc64ca751ce3c8bf84e12b4566
Version: 2
+------------------+----------------------+----------------------+--------------------------------------------------------------------------+
| NRS name/subname | Created              | Modified             | Link                                                                     |
+------------------+----------------------+----------------------+--------------------------------------------------------------------------+
| phantom          | 2020-02-13T12:17:17Z | 2020-02-13T12:17:17Z | safe://hnyynyi95mmtqr9pcwnoft9xwo61w3iu7qmhd415yngihakc1ajrgkiq4ebnc?v=3 |
+------------------+----------------------+----------------------+--------------------------------------------------------------------------+

[joshuef]

@shane was the original data PUT from the CLI?

At the moment, there’s a known issue with ownership being tied to the app specifically (so created in CLI === cannot edit in browser and vica versa).

This is something we’ll hopefully be resolving in the non-too distant future with tokens etc, but right now (as i understand), the app is the owner

---

(if that’s not the situation, then we’re in bugtown )

[Shane]

Yeah, the NRS / FilesContainer for safe://phantom was originally created via the CLI.

It’s fine if it’s a known issue, I’m doing most of my development in Chrome via a mocked version of the safe library anyway, so I can just mock the call up - I just wanted to report it in case it was a more serious issue.

I’ll mark your response as a solution, but obviously that’s just in the context of this topic, not in the context of the feature as a whole.

[bochaco]

As a workaround, if you are interested, you can impersonate CLI app from your webapp using the same CLI app info when authorising it, and that will probably work @Shane

[Shane]

Awesome, I have an appointment now, so I’ll test out out later today and report back.