[1.4.0rc3] Permission issue, can start print from Cura without such permission

[foosel]

Problem

@foosel

Could you please check what appkeys exist in your system and for which users, and that the key in Cura is actually for the user you expect it to be? You can do so via Settings > Application Keys.

I just tested again, making sure to be logged in as the api_user to get the API key (that has > limited access) and although I can not move or preheat the printer within Cura, slicing and clicking "Print with OctoPrint" does in fact upload the file (allowed) and start the print (shouldn't be allowed).

Originally posted by @gcurtis79 in #3389 (comment)

Solution

Make sure PRINT permission gets checked on evaluation of select and print request parameters on upload API, probably not the case right now, causing this issue.

[fieldOfView]

Is this something you plan to fix today (this year) still? If not this sounds like something I could make a PR for, for you to check out next year.

[foosel]

Not today, so sure, go ahead :)

[fieldOfView]

It looks like the PRINT permission is properly checked on evaluation of select and print request parameters on upload API, however the PRINT permission seems broken.

All permissions which specify additional needs (FILES_DOWNLOAD, FILES_DELETE, FILES_SELECT, PRINT, GCODE_VIEWER and TIMELAPSE_ADMIN) seem to always be available. This can also be seen in the UI by revoking the File List permission; the file list should disappear but it doesn't. Same with removing the File Delete permission, which should remove the trash icon from the file list but doesn't.

Removing the FILE_LIST need from the definition of these permissions fixes this. Removing the FILE_SELECT from the PRINT permission fixes the issue reported by @gcurtis79.

I've been looking why multiple needs are not working and will continue to do so.

[fieldOfView]

My previous assessment seems incorrect. The problem is not so much multiple needs, but the FILES_LIST permission seems suspect.

See below

[fieldOfView]

My original assessment was correct. I understand the Needs and Permissions a bit better now.

When an OctoPrintPermission has multiple Needs, Permission.allows() checks if there's an intersection between the needs of the Permission and the provides of the Identity. Because the length of the intersection is not checked, this is true if one or more needs overlap. So because the PRINT permission also has the FILES_SELECT permission, Permission.PRINT.can() returns true if the user does not provide a print Needs but has a files_select Needs.

The quickest fix is to remove the multiple Needs in the OctoPrintPermissions definitions. A better fix is to check the length of the intersection between the Identity provides and Permission needs to be the same as the Permission needs in Permission.allows, but that's an upstream fix.

[fieldOfView]

This is fixed by 3229e65, because that removes the multiple Needs.

By doing that, it also sort of removes the necessity of #3414, but that PR might still be useful as defensive programming in the case that multiple Needs ever make a return (the implementation of having multiple Needs on a Permission is still there).

[foosel]

Yeah, I'm actually just now looking through it and trying to figure out if it will have any problematic side effects. Leaning towards a merge though.

[foosel]

PR merged and permission modelling changed, so this should be solved and ready for 1.4.0rc4

[foosel]

1.4.0rc4 is out