This prevented slices from happening if the mouse-cursor came (even near) the model.
originally done as part of CURA-12634 -- attempt to cherry-pick and subsequent rework later for CURA-12732
It's OK to do this in this manner and not via for example the keyring, since we there's no actual user-name involved, only the machine-name -- anyone on the same machine is _already_ capable of sending the basically the exact same request that originated the access in the first place.
part of CURA-12708 (alt implementation)
We set the preference value for people who used USB-printing in the previous version, from the next version onwards, it'll be disabled by default -- as not many people still print by USB-cable, and more importantly, it can mess up some systems. It's not going away at the moment though.
CURA-12333
First use of 3.11's StrEnum in the code base I think -- anyway, Python autoboxes these (maybe even the old str,enum things as well, but irrelevant now), so there's nothing in the way of making this an enum and have type-_checking_ instead of type-_o_'s.
done as part of CURA-12624
Otherwise if the server (on the printer) gives back something that can be parsed into JSON, but _isn't_ the authorization digest info, the thing breaks.
part of CURA-12624
New rules means we have to put printjobs and such behind a little authentication, as these contain personally identifiable info. These two effected calls where found _outside_ of the API class where I thought to be able to fix it 100%. See also the TODO's in the neighbourhood -- but I'm not sure I can just do what those say (move the relevant methods to the API), as those methods to be moved are _inside_ the larger Cura SDK (and they're public) and the place where I'm meant to move them to (the ClusterAPIClient) is _not_ (as they're in a plugin).
part of CURA-12624
The new regulations make a decent amount of sense -- but just because we agree with them doesn't mean we'd implemented this yet. Anyway, information wich can be used to personally identify people should be kept behind (virtual) locks and bars. The new firmware will only allow certain operations _after_ a request has been made to the .../auth/request endpoint, and someone in the physical vicinity (of the printer) has pressed ALLOW on a popup (with the application and name of the requester shown, on the printers' UI). After that, _as long as you put the relevant Authorization Digest in your HTTP headers_ (and use at least SHA-256), you may proceed to make other requests without the printer-server flipping out with a FORBIDDEN error.
The current commit _should_ also still work with printers that still have old (well, current I guess...) firmware -- but I didn't test that yet.
CURA-12624
