Polis: Prevent non-privileged accounts from accessing admin UI of all conversations

[patcon]

This is mostly harmless, though a bit confusing, since there are unexpected errors when trying to interact with inputs.

Steps to Reproduce

1. Sign up for a non-privleged account: https://pol.is/createuser
2. Find a conversation you are only a participant in, e.g., https://pol.is/3ntrtcehas
3. Change the url to access the admin interface: https://pol.is/m/3ntrtcehas

Observed Behavior

• Can explore a read-only version of most admin pages.
• ❗ Can submit seed comments of unrestricted length. e.g., https://pol.is/m/3ntrtcehas/comments
• ❗ Can view unmoderated/rejected statements. https://pol.is/m/3ntrtcehas/comments/rejected
• Can try to edit fields (errors show in save status), and try to click checkboxes (silent no-op).
• Can try to view reports and monitoring states ("loading" text forever). https://pol.is/m/3ntrtcehas/reports

Expected Behavior

Wouldn't have access to admin pages.

[patcon]

https://gitter.im/pol-is/polisDeployment?at=5efccfa8b8152d34847637da

@colinmegill: I would try to go after the loading states and check the consoles. If it’s actually ‘unauthorized’ then what it really is is an unhandled error on monitor view, and then simply correct that there, redirect on the client to login, and figure out why the same pattern isn’t applied on configure view. Sounds like the create report page may be doing something in the right direction

[joshsmith2]

A little community +1 on this - to raise another potential harm here, this might lead to disclosure of sensitive personal data where it's been entered by participants and rejected by moderators (e.g. we've seen participants plonking their email addresses into the statement submit bar.)

As you can't currently delete these comments through the admin interface (right?) closing this issue would deal with a potential data breach

[colinmegill]

Agree, @joshsmith2, I'd like to have a fix in for this this week.

[patcon]

I did a little poking around, and a line of investigation involves some components where an error prop exists, and does some checks as if it's expecting an object to be passed (e.g., this.props.error.status == 401) but it seems that the reducers was later refactored and now passes error as a boolean, and a separate status prop with the error.status value.

Will investigate more later

EDIT: the reducer is related to user data, so that's a good sign

[patcon]

From gitter:

colin pointing to https://github.com/pol-is/polisServer/commit/c0127c1c4f027309af1ca19550599bd06955091c

[patcon]

This is with the change suggested in the above msg.

Accessing conversation I do NOT moderate

Ok, so when I re-enable that commented out line, it works pretty well for a conversation I shouldn't have access to:

Access conversation I DO moderate

But interestingly, now I get the same redirect when trying to make any change to a convo I do own. Not that I get redirected only on save, and the save still "takes".

[patcon]

When inspecting component props in browser using react devtools, seems that on saving, the is_mod and is_owner keys disappear from zid_metadata for some reason...