Bond userEmail with userId on Dust managed apps in createConversation

[albandum]

Description

• We are preparing to test some dust-managed apps, in which users can create conversations from the public API
• To be able to track MAU and bill accordingly, we need to bond the userId of these messages like we do with slack
• So we use the email in the message context to find the corresponding user

Risk

Not much

Deploy Plan

[github-actions]

	Fails
🚫	Files in **/api/v1/ have been modified. Please add the documentation-ack label to acknowlegde that if anything changes in a public endpoint, you need to edit the JSDoc comment above the handler definition and/or the swagger_schemas.ts file and regenerate the documentation using npm run docs

Generated by 🚫 dangerJS against c00415e

[spolu]

Let's move this to the API endpoint as this is specific to the public API right?

[albandum]

Yup. Sounds good indeed.

[albandum]

Moved - not sure about the location of getUserAuthenticatorFromEmail(), does it sound right?

[albandum]

Put back here after authenticator discussion. Not sure moving it to API endpoint is worth the extra attribute on postUserMessage()

[spolu]

fair.

You likely want to dry it and use it in editUserMessage as well?

[spolu]

Thinking more about it this means that anyone with an API key can impersonate any user on Dust.

They can as an example access vaults they don't have access to.

So that's deifnitely a no go.

What are the problems to solve exactly?

[albandum]

That's just being used to save userId in the message when creating the conversation to track MAU from external apps managed by Dust (like we currently do with Slack).
Previous version in with the code the private conversation API did not use any authenticators but only added the userId when creating the message, so I'd say that was better.

If vaults accesses based on conversation participants (userId in messages from that conversation) then yes, that's an issue indeed. We then have 3 solutions:

• Add a salt to dust-managed external apps (zendesk marketplace, jira marketplace, etc) and only allow this to happen when the salt is checked
• Abort all this and rework a bit MAU calculation in stripe to invoice active users also based on userEmail in messages and not just userId
• Let it go for now, check the usage of external apps using metabase and act accordingly if usage rises and billing becomes an issue

[albandum]

Adding @thib-martin to the discussion, might have an insight

[spolu]

Access to vaults is based on the Authenticator object. Here you crearte a new One based on a user controled string which is not acceptable.

[albandum]

Access to vaults is based on the Authenticator object. Here you crearte a new One based on a user controled string which is not acceptable.

That's what I figured - reverted the last 2 commits.
Imho the best way is to keep that check in the conversations private endpoint, because if I want to move it to the public endpoint, I need to modify postUserMessage() to add a userId argument and that seems quite overkill.
WDYT?

[spolu]

fair.

You likely want to dry it and use it in editUserMessage as well?

[albandum]

You likely want to dry it and use it in editUserMessage as well?
Done

[spolu]

LGTM modulo the last comment 🙏

[albandum]

LGTM modulo the last comment 🙏

Done and merging