[core] Use Netlify function for feedback management

[alexfauquette]

To be able to delete a message, we need to be the author. So to let the bot delete messages it has to write them himself

So instead of using webhook, this PR uses a call to the serverless function that send the message to slack using the API

Then it's feasible to delete messages. To do so I support to action:

• Delete which removes the message
• Save which send the message content to a spreadsheet and notify the user when done

[mui-bot]

Netlify deploy preview

https://deploy-preview-36472--material-ui.netlify.app/

Bundle size report

No bundle size changes

Generated by 🚫 dangerJS against b5ce5c9

[oliviertassinari]

Regarding the security, there are the current public env tokens, are these safe to be public?

• SLACK_SIGNING_SECRET
• SLACK_FEEDBACKS_TOKEN is this a dead token to remove?
• SLACK_BOT_TOKEN
• G_SHEET_TOKEN this one looks OK-ish, all the saved feedbacks are effectivement public, but it sounds fair. It works because the Google account has a very limited access to Google Drive.

[Janpot]

They are defined in netlify, I don't believe we're leaking these anywhere where a user of the docs can access them. These ones are not safe to be public.

[oliviertassinari]

We need to include all the env variables with https://app.netlify.com/sites/material-ui/settings/env so the contributors from the community can run the build:

https://docs.netlify.com/environment-variables/get-started/#sensitive-variable-policy

So they are accessible to anyone who opens a PR to log them.

[Janpot]

Ah yes, I see now, that's a problem indeed, great catch. They seem to suggest we can exclude certain variables from untrusted builds but it's not 100% clear to me yet how to do that exactly. We should definitely do that if we can for the SLACK_SIGNING_SECRET and the G_SHEET_TOKEN.

According to the docs it seems we need to enable "Deploy without sensitive variables" then. But how do you mark variables as public/private then? Just erase the value for "Deploy Previews" context?

[alexfauquette]

About what can be done with those tokens

• SLACK_FEEDBACKS_TOKEN is needed for the mui-x v5 docs. It allows sending messages to #docs-feedback channel. That's all. So getting it could allow to spam us
• SLACK_SIGNING_SECRET or SLACK_BOT_TOKEN would allows to fake requests from slack interaction, or directly use API calls from our bot. So they could read/write/delete messages. But bots are limited to the channels where they are invited
  https://api.slack.com/authentication/basics#public

---

So they are accessible to anyone who opens a PR to log them.

A solution is to restrict those tokens to production. And if needed for tests, we can still add them for the specific branch. Such as to log them, attackers should have their log in production

[oliviertassinari]

But bots are limited to the channels where they are invited https://api.slack.com/authentication/basics#public

Ok, then I think that we are good