Can I set document owner from node.js code?

[CodingFu]

Hi @peterpeterparker.

I have an identity that is satellite controller. Let's say principal id is aaa-aaa-aaa I have a user in juno, their principal is bbb-bbb-bbb

I want to setDoc on behalve of the user from node.js using controller identity.

When I do

await setDoc({
  collection: "receipts",
  satellite: {
    identity: myControllerIdentity,
  },
  key: nanoid(),
  owner: "bbb-bbb-bbb",
  doc: {
    date: '2024-04-04',
    ...
  }
})

I expect resulting doc to be owned by the user (bbb-bbb-bbb), but it still belongs to the controller principal(aaa-aaa-aaa).

Do I miss something? Is this possible with rust juno client? Is it possible at all?

[peterpeterparker]

Hi @CodingFu,

I’ve thought about this a few times, but it’s actually not possible at the moment. The owner is the caller, and my reasoning is that allowing this could introduce potential security risks. Additionally, I’m unsure if a controller should have the ability to impersonate a user.

That said, if the community believes it’s beneficial for a controller to create a document (that doesn’t yet exist) on behalf of a user, I’m open to discussing the idea.

Since the entire permissions mechanism is based on ownership, we’d need to be especially cautious if we were to modify anything. Does that make sense?

[CodingFu]

I was under impression that controller principals should have "root" access for "managed" collections. Controllers can really read and write any data to/from the collections.

Also, it seems that I am able to write data on behalve of the user from juno hooks ( on user insert to collection A, I am able insert into collection B with the user as an owner)

Can you please tell me a little bit more about this security issue? Or maybe point me into where those checks are enforced, we might want to fork the code for our sattelite.

[peterpeterparker]

Can you please tell me a little bit more about this security issue?

Generally speaking, on the IC, I consider it bad practice, or at least something that requires particular caution, to expose a principal as a parameter in a function that can assign ownership of data. If this approach is taken, it becomes the developer's responsibility to ensure the endpoint cannot be misused.

That's why I believe adding such an option poses a potential security risk. While it's technically feasible, when implementing it, we must be absolutely certain there is no chance of misuse.

Beyond the technical concerns, this could also open the door to potential attacks. For instance, someone might impersonate another person and approach a controller, requesting that data be added for Principal X, when in reality, they are Principal Y.

So, while this isn't an immediate security flaw, it's more about being aware of potential risks and taking extra precautions. Does that make sense?

it seems that I am able to write data on behalve of the user from juno hooks

Yes, but that’s possible because a Satellite is itself a controller and can only be deployed by a controller. Additionally, a hook cannot be triggered directly from the outside; it can only be activated through other endpoints, which, in turn, only accept requests based on the caller of the functions.