Page MenuHome

Flamenco-Server Proposal: Open Manager Interface calls to local users
Closed, ArchivedPublicPATCH


Currently, only users logged in via blender id can use the manager's interface actions, such as create_new(), revoke_auth_token(), as well as the PATCH eve call used to edit managers.

This is because the only method being used to authenticate users is the validate_token() method that is ran before every request is processed.

The validate_token() can find a user if one of the following is true:

  1. a token is provided via a Bearer Authorization header.
  2. a blender id token is provided via a session cookie.

My proposal is to change the second option to not only accept blender id tokens, but any other provided token that is stored in the database and is provided via the session cookie.

Event Timeline

Kael Baldwin (devthane) renamed this task from Flamenco-Server Proposal: Open Manager Interface API calls to local users to Flamenco-Server Proposal: Open Manager Interface calls to local users.Apr 12 2018, 10:42 PM
Kael Baldwin (devthane) lowered the priority of this task from 90 to Normal.
Kael Baldwin (devthane) created this task.
Kael Baldwin (devthane) updated the task description. (Show Details)

This looks as easy as grabbing the session from flask and then taking the user_id from that session and validating based on that user id.

I'm not sure why we aren't just using flask_login to authenticate these routes however, since it's already authenticating via session cookie anyways. Maybe flask_login doesn't handle login via the blender_id cookie?

If the goal is not to use session cookies, then the front end needs to be altered to use Bearer Tokens instead, and then the validate_token method needs to not check for session cookies at all... I think.

The create new manager and revoke existing token endpoints are easy to fix.

The problem I'm running into now is with editing a manager.
The interface uses the flamenco/manager patch method, which goes through Pillar's patch_handler, which uses authorization.require_login.

I feel like it would be too intrusive to edit the patch_manager, since that's a part of pillar itself.

I think the best solution for allowing a local user to edit a manager, would be to create an actual edit route, that does not use the patch_handler.
This would more closely mirror pillar's project edit workflow.

But I'm curious what you think @Francesco Siddi (fsiddi)

Hello Kael, unfortunately I'm very busy with other projects at the moment. I'll come back to this conversation later next week.

Hey @Francesco Siddi (fsiddi) , I ended up becoming busy myself with another project as well, but am freed up now and am looking into this again.

Would you have time to look at this, perhaps?

I'm going to have to re-acclimate myself to the project again, but once I do I'd like to go ahead and implement this if it sounds like the right direction to go.

Hi Kael - same here unfortunately. I'm definitely interested in looking into this, but it might take some time. I'll keep you posted!

Dalai Felinto (dfelinto) closed this task as Archived.Dec 23 2019, 6:39 PM
Dalai Felinto (dfelinto) claimed this task.

Hi, thanks for your patch.

We are undergoing a Tracker Curfew where we are automatically closing old patches.

If you think the patch is still relevant please update and re-submit it. For new features make sure there is a clear design from the user level perspective.