Inconsistent Guest Permissions in printerstate.js

[codeceptsDE]

The problem

When accessing OctoPrint as guest, you can (if set up correctly) start a print, pause a print, but never cancel a print.
If you can start a print, and are also allowed to pause a print (potentially ruining the part, too), you should be allowed to cancel a print. This behavior is inconsistent otherwise.
Any logged in user, even with the most restrictive permissions, would be able to cancel a print.

This issue is due to the way permissions are checked in printerstate.js:

OctoPrint/src/octoprint/static/js/app/viewmodels/printerstate.js

Lines 48 to 76 in cd0f476

	self.enablePrint = ko.pureComputed(function () {
	return (
	self.isOperational() &&
	(self.isReady() || self.isPaused()) &&
	!self.isPrinting() &&
	!self.isCancelling() &&
	!self.isPausing() &&
	self.loginState.hasPermission(self.access.permissions.PRINT) &&
	self.filename()
	);
	});
	self.enablePause = ko.pureComputed(function () {
	return (
	self.isOperational() &&
	(self.isPrinting() || self.isPaused()) &&
	!self.isCancelling() &&
	!self.isPausing() &&
	self.loginState.hasPermission(self.access.permissions.PRINT)
	);
	});
	self.enableCancel = ko.pureComputed(function () {
	return (
	self.isOperational() &&
	(self.isPrinting() || self.isPaused()) &&
	!self.isCancelling() &&
	!self.isPausing() &&
	self.loginState.loggedIn()
	);
	});

The print and pause button check self.loginState.hasPermission(self.access.permissions.PRINT), while cancel requires self.loginState.loggedIn(). It should be the former as well, or maybe self.loginState.loggedIn() || self.loginState.hasPermission(self.access.permissions.PRINT) to prevent guests in an unsecured environment from messing with prints.

I am not sure if there are changes required in the backend, too.
As far as I am aware, the variant with the OR above has no adverse security implications, as by default, guests do not have print permission.

I use OctoPrint in an isolated LAN environment, and I want all users to be able to use the basic functionalities of the printer without requiring a login. This currently works, besides this limitation that guests with print permission cannot cancel a print.

Did the issue persist even in safe mode?

Yes, it did persist

If you could not test in safe mode, please state why ("currently printing" is NOT an excuse!)

No response

Version of OctoPrint

1.9.3

Operating system running OctoPrint

OctoPi

Printer model & used firmware incl. version

No response

Browser and version of browser, operating system running browser

No response

Checklist of files to include below

• Systeminfo Bundle (always include!)
• Contents of the JavaScript browser console (always include in cases of issues with the user interface)
• Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
• GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)

Additional information & file uploads

No response
octoprint-systeminfo-20240416093746.zip

[foosel]

That was indeed only the permission check in the frontend that was wonky, and purely visual too. The backend already was adjusted to only require PRINT, and the API client didn't do any further checks browser-side. This was probably a leftover from the time prior to having the granular permission system and simply slipped through so far. Thanks for spotting this! It will be fixed in 1.10.2.