Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Password protection of shared dashboards #9978

Open
EBoisseauSierra opened this issue May 15, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@EBoisseauSierra
Copy link

commented May 15, 2019

Context

Metabase is great. On our instance, we have super-users (admin or not) who have a Metabase account. Those "super-users" create questions and dashboards, and that's all good.

But we also have "viewers only", who shouldn't be able/have to modify dashboards; only looking at dashboards.

Problem

Sharing dashboards is great for that. However, these dashboards include private/financial data… so we'd better not have them publicly available on the Internet.

Several options exist (embedding with Apache protection, LDAP, Apache protection of shared dashboard), but they don't seem fully satisfactory.

Feature request

➥ Would it be possible to add the possibility of a password authentication for dashboards sharing?

Example

You would define the password in the same page where you set up sharing settings, e.g.:
Screenshot from 2019-05-15 11-27-16_modif_shadow

Accessing the URL would then first prompt you for something like this:
Screenshot from 2019-05-15 12-08-18_shadow

@tuaris

This comment has been minimized.

Copy link

commented May 16, 2019

I've recently run into this issue with the need to provide a partner with access to specific information. Password protection was a requirement. As a workaround I had to instead revamp the permissions in our instance, add a user account for the partner, and grant them limited access through group permissions.

I believe that properly configured groups and permissions on the instance is the correct approach. However it's also understandable that such an approach may be difficult in some circumstances. Having the option to password protect a shared dashboard would be beneficial.

@tlrobinson

This comment has been minimized.

Copy link
Member

commented May 16, 2019

The public URLs are unguessable UUIDs, so it doesn't seem like adding password would add much to the security.

I suppose one argument for passwords is that URLs get saved in browser history.

Regardless of whether we add this, in the meantime you could also build a very simple web application that uses the "Embed this in an application" feature to add password protection, e.x.

const express = require("express");
const bodyParser = require("body-parser");
const jwt = require("jsonwebtoken");

const PORT = process.env["PORT"] || 3000;
const METABASE_SITE_URL = process.env["METABASE_SITE_URL"];
const METABASE_SECRET_KEY = process.env["METABASE_SECRET_KEY"];

const PASSWORDS = {
  question: {
    70: "hello"
  },
  dashboard: {
  }
};

const app = express();
app.use(bodyParser.urlencoded({ extended: false }));
app.get("/:type/:id", (req, res) => {
  res.send(`
<form method="post">
    <input name="password" placeholder="Enter the password" />
    <button type="submit">Login</button
</form>`);
});
app.post("/:type/:id", (req, res) => {
  const resourceType = req.params.type;
  const resourceId = parseInt(req.params.id);
  const actualPassworld = req.body.password;
  const expectedPassword = PASSWORDS[resourceType][resourceId];
  if (expectedPassword && expectedPassword === actualPassworld) {
    const payload = {
      resource: { [resourceType]: resourceId },
      params: {},
      exp: Math.round(Date.now() / 1000) + 10 * 60 // 10 minute expiration
    };
    const token = jwt.sign(payload, METABASE_SECRET_KEY);
    res.redirect(`${METABASE_SITE_URL}/embed/${resourceType}/${token}`);
  } else {
    res.send("nope");
  }
});

app.listen(PORT, () => console.log(`Listening on port ${PORT}!`));

You could store the passwords in a database somewhere, and have an admin page to add/remove them, etc.

@EBoisseauSierra

This comment has been minimized.

Copy link
Author

commented May 17, 2019

@tlrobinson Thanks for your answer. I admit you are unlikely to guess the URL, yet I wouldn't dare telling my client "Anyone who knows the URL can access your financial data… but you know, it's hard to guess!" (-;
In the end, I guess it's a question of "perceived security" (I don't like this concept, though), with a 2FA-ish protection (URL + password).

Anyway, I'll definitively give a try to the code you have sent — I appreciate the time you have granted me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.