SOFIE-95 - Sofie Core Groups with Trusted header POC #11
Conversation
2ce0a6d
to
63b1e29
Compare
|
Reactivity isn't perfect within the ui, but this now behaves fairly sensibly. This portion (minus the polling) could be contributed upstream on its own, as it is fairly standalone and would be useful for anyone else wanting to redo permissions within the ui |
|
This is very much battling how meteor wants auth to work, but I have a hack which sets the userId of a ddp connection when it is opened based off the headers. |
This is a hacky proof-of-concept on header based authentication flow.
For now using the
dntheader, as that gets passed through to meteor.When a ddp connection is opened, it checks the header, and if its not a valid value, it closes the connection. This may not be wanted, as it means this can't be bypassed within nginx, and breaks development.
Then a new meteor method is added, which allows for asking the backend what 'user level' to show in the ui. This is crudely slotted into existing logic, it needs to be redone properly. It also should consider re-checking the value whenever the ddp connection reopens, to allow for invalidating permissions.
The enum may want to be changed, to match the granular system used in the frontend.
But this works, I can run through nginx with
proxy_set_header dnt "admin";and the settings button appears, or change that toproxy_set_header dnt "studio";and it disappears (and for some reason sofie won't let me run a studio in this mode..)We should consider that nrkno#1241 is coming in release52, which removes the existing meteor user based auth. So when finishing this, it might be beneficial to pull in parts of that to avoid making this cooperate with code that is about to disappear.