Users and security

[slifty]

I believe the current simplebook model is something like this:

1. Mediawiki user specifies pages to render
2. Simplebook is invoked, and passes the pages to render to the api service.
3. Api service invokes node / puppeteer, which logs in as a special "simplebook" user in order to render the page and save as pdf.
4. ... the rest of the process goes here

The issue is that the pdf generation is therefor not limited by the invoking user but rather is limited by the credentials of the simplebook user.

That is an issue for two reasons:

• It may be possible for someone to print a page that they don't have access to (but simplebook does).
• The information rendered on the page will be whatever simplebook has access to (e.g. hidden torque fields may be either visible or hidden inappropriately depending on the nature of the permission disparity between the end user and simplebook's user)

We need to think through the right way to address this securely.

[slifty]

I'm going to attempt to summarize some of the conversations around this topic.

For context: as part of the installation of the SimpleBook / collection plugin, torque-sites installs a little plugin that does credential magic for a special mwlib user.

What's going on here is that if a page rendering request is made as a special user (whatever the value of mediawiki_mwlib_username) then the user / group for that request is populated based on values that have been encoded in the request header.

So what we need to do here is:

1. Update the SimpleBook python / node to accept and forward { all / most / some } header values that it receives as part of a book printing request.

2. Update that ansible collection.php template to properly write / parse those headers.

We want to pass along more than JUST that header since there may eventually be other critical values / config values passed through similar means and we don't want the SimpleBook plugin to have to know about it.

[frankduncan]

Oh, I really like using http header values here. That's a really elegant way to do it. Maybe just all headers that start with "X-SimpleBook" can get forwarded back to mediawiki.

[slifty]

Good news and bad news.

I checked out some best practices around when / how to use HTTP headers. Short story is that HTTP headers are best used for meta request data (e.g. authentication tokens, return format, etc). Here's a StackOverflow thread about it.

This situation doesn't scream "metadata" (though an argument could be made).

I'm going to start off not using headers but instead I'm adding two new plugin config variables:

    "SimpleBookPassthroughParameters": {
      "description": "Dictionary of key / value pairs to be passed back to this MediaWiki as part of any rendering requests",
      "value": null
    },
    "SimpleBookRenderingCredentials": {
        "description": "Login credentials to this MediaWiki as an object with `username` and `password` properties",
        "value": null
    },

These would then be passed as part of the normal form / request data.

[frankduncan]

I would definitely make the argument that this is metadata. Though I could see that there should be one metadata field "X-SimpleBookParams" that is a urlencoded parameter style list.

But if it ends up working, I'm not going to argue it excessively.

[slifty]

Not opposed to shifting to header approach -- or even just supporting both so that it's up to the mediawiki implementation to decide whether the passthrough data should be passed as a header or a request value.

The authentication credentials to be used when making the call is the other question and I just need to reflect on whether "authentication to be used in a future HTTP call" is truly metadata (if that's metadata, why isn't "URLs to be used in a future HTTP call" considered metadata, for instance).

As an example -- I could see a situation where we want some of these passthrough values to actually be tied to specific URLS (for instance "render X url from the point of view of user Y" or "use view Z with url A") and so in this sense it is NOT metadata to the API call (which is where headers are considered the Right Approach) but really these things are parameters to that booklet-rendering API call.

To be clear: I am NOT implementing url-specific-config as a feature of SimpleBook right now, but I think considering that example helps clarify what is and is not metadata.

Hope this makes sense.

[frankduncan]

Ah, I see what you're saying in that mediawiki could change what parameters are passed based on what page is actually being rendered. In our use case, it's a general meta set of information, so that's where my mind was. That makes a lot of sense, and so this implementation plan seems great!

Also note that authentication is optional. In fact, for most wikis that would use this, it's unneeded.

[slifty]

Closing this for now because the current model does address these concerns -- basically the user credentials are passed as part of the book generation request, and forwarded back to the wiki / parsed by the plugin to invoke the passed through credentials.