Add support for event specific password protection

[owi92]

This adds the necessary backend and frontend implementations to allow event specific authentication as done by the ETH.

For technical information, see commit messages. @LukasKalbertodt to test this, you can use this DB command:

update all_events
set credentials = row(
    'sha1:9D4E1E23BD5B727046A9E3B4B7DB57BD8D6EE684',
    'sha1:3CBCD90ADC4B192A87A625850B7F231CADDF0EB3'
)::credentials
where title = 'Beyond Elasticsearch: user-facing search engines';

Of course you can use any other event. This will give the event the password user pass and the password word.

Test here (credentials are "user" and "password")

Closes #1186

[LukasKalbertodt]

Thanks for tackling this huge feature! The PR was nice to review commit by commit. And while below I have written quite a few comments, I think the general direction is absolutely correct, and all remarks are just "local problems", not really anything that requires rethinking everything.

Apart from the inline comments, while testing it I noticed these things:

• The "in flight" circle still spins when invalid credentials are entered on video page. Once the error is shown, the spinner should disappear. This only happens when entering them incorrectly twice... what.
• The whole page flashes when submitting credentials. Also, if the credentials were wrong, this means the entered credentials disappear, which is annoying if u only need to correct a typo.

I have to re-test everything again, but I think this is already a long enough review. I can test again after these things are fixed.

[LukasKalbertodt]

Mhhh this is tricky. So the thing you describe isn't great, right? Because yes, if we mix them together, we have no idea what was originally set. Just so I understand correctly: the only (as in 'singular', not to diminish the importance) reason to mix them together is to have easier queries, right? So we don't have to check both columns everywhere? Or is there more to it?

My gut feeling is to keep them separate. We might have already talked about this, in which case I forgot and would be happy to be reminded :D

Maybe in the future, the ACL selector allows users to select preview, read or write. Well mh no, that could work with either model. I suppose there is no operation that allows users to "just remove a single action permission" from an event, which is what would trigger the thing you mentioned here. The harvest process would also overwrite the whole ACL and wouldn't cause a problem with either model.

So right now I cannot think of a case where your model would break... mhhh. I might think about it a bit more.

[owi92]

is there more to it?

no, I don't think there is.

We might have already talked about this

You suggested doing it like this when we first planned the whole thing. I then said "no lets not, because reasons™". But when implementing it, I realized that I actually find it nicer to have only one filter/check for access things, taking the cue from how read and write roles are handled (whenever something requiring read access is checked, it's not necessary to also check for write, as read also includes all write roles).

[owi92]

For the latest changes of this PR please see Lukas's commit messages and my comment in his PR.

[LukasKalbertodt]

Very good idea adding audioOnly to the API. Only two remarks.

[LukasKalbertodt]

Since this PR has been around for a while and many discussions took place, let me summarize a bit:

Thumbnails are now treated as not-protected by the password. This is in line with the current video portal of the ETH (which is the main reason we are developing this feature). There are use cases and arguments for both options, making the thumbnail protected or not protected, so we might make this more flexible in the future. Having the thumbnail not-protected solved one of the major technical hurdles for us.

The current PR lacks some goodies compared to Ole's initial version of this PR (as mentioned here). This was my decision to ignore this for now to be able to move on with this and also tackle other, more important issues.

• Unlocking a video in a video block on a realm does not rerender/unlock other video blocks on the page. So the user either has to reload or unlock them manually. This can be fixed later, if we want.
• Videos uploaded via the Tobira uploader into a password-protected series will not always inherit the password protection. This will be solved by The visibility selection to control ACL in the uploader should be configurable #1006. The problem is simply that the uploader always attaches event ACLs. Without a properly configured merge mode in Opencast, that means that the ACLs of the series are not used by the event at all. The linked issue will change the uploader to not attach ACLs, if configured like that.
• Password prompt for password-protected videos is sometimes flashed for a short time #1290

But with that, after the last minor remarks above are fixed, this is finally ready.

[LukasKalbertodt]

Praise the lord