Guest users - and perhaps access control granularity

Hi all

I've used Octoprint for some time now, and it works well. However, if used in a shared environment, such as with a makerspace, it would be nice to have a way to sort more granular access to users. Given some sort of common user database (LDAP or whatnot), users could be given access to start a job and view whatever's on the webcam, but not to stop other users' jobs. I guess I can do a wee bit of the coding myself once I get my head twisted around the current code, but still, it'd be a nice start to allow for creating "guest" users, with similar access as to today's guest users not being registered,

Could creating such guest users be a start to this?

thanks

roy

The current release candidate for the next version has incorporated a lor more granular permissions. You may want to start your research there.

While OctoPrint 1.4.0 (currently in release candidate state) does add more granular permissions (instead of all or nothing), it does not yet entirely cater for the following:

OctoPrint 1.4.0 does not discern between jobs "owned" by different users. It also does not discern between starting a printjob and canceling it. This could be added in a future release though.

And this is actually where I want to go to, just had to break down the work into something bite sized ^^

6 Likes

That would be really nice. If so, adding owners to files and perhaps directories and some simple access control there as well would perhaps be appropriate? It'd be fun to see something like this in a print farm at a makerspace :slight_smile:

I dunno.

The more I hear about print farms the more it raises the hackles on the back of my neck. Certainly, businesses with 20 or 30 printers need good solutions for their business model. But I really think that they should pay for the development so that their business is a success. I don't think that others should make profits all the while asking for free solutions.

So, very granular user control is what I was used to as an I.T. manager back for a variety of companies. Your average parent who owns a household printer might possibly be interested in keeping a younger child from starting a print but that feels a bit like a contrived example. Okay, schools probably want to protect their assets and they don't have unlimited funds (at least here in the states).

It feels to me like one rogue anonymous/guest user in a school or kiosk situation has too much power to trash a 3D printer.

I remember the times when I've stayed at hotels where they have machines which help you to make your own waffle or pancakes. Many times I've seen that the station is a total mess (batter everywhere) and the burnt pancakes are now rammed into the separation slide and the belt is now stuck. Guest users aren't invested in the technology and don't seem to care whether the machine is healthy or not, in other words.

My tought was not a business, where it obviosly makes sense to pay for the development of something like this, but more of a makerspace like the one where I'm a member. We don't have a "business model" - it's all volunteer-ran, so we don't really have a huge budget. We have coders, though… Schools with 3d printers probably would also want something like this to allow for fair use of the printers and with some control over who's doing what.

In a makerspace you could issue NFC RFID cards, add a PN532 reader, set the dip switches for I2C, enable it using raspi-config on the Pi and connect it as shown here:

Photo of the desk in front of me:

The wires land at BOARD pins 3, 4, 5 & 6. Adafruit's adafruit_pn532 package makes easy work of reading the ID from the card.

You'd want to write a plugin which reads card scans and logs in the individual. By marrying this with one of the other plugins you could even write something to charge someone for the filament/hours they used a particular printer or minimally logged all that.

we'll need to introduce rfid cards to the members, then, which won't be very practical. also, this was a question about octoprint and not something else

I'm sort of used to the kind of makers who enjoy solving their own problems, to be honest. But I guess I'm an odd bird.

So any maker should help his or her own and not ask on forum in case something happening already or of others have input? That doesn't make sense.

And now everyone take a deep breath please. It's ok to ask for features or help, even in a commercial context (which this ain't), as long as it's in a friendly tone. I get where you are coming from guru (and the particular cases that you have in mind also make me grumpy), but I think you are biting the wrong person here. So... both of you, shake hands and be done with it :wink:

1 Like

Sorry if I come across as grumpy. I was an instructor back in 2018 at a coding academy and I encouraged my students to become problem solvers. I get that not everyone who comes here to the forum are actually coders, though.

I like maker spaces. They make me feel at home. Ask all the questions you want from us. Somebody wise once said "Be the change that you'd like to see in the world". For me that means, find a problem and solve it. If I'd said that RFID thing to one of my students (Cesar) his eyes would have lit up and he'd have actively engaged me in conversation for an hour on the subject and would have tried that. I kind of like that in younger people.

btw, if we get to having a user-job connection, this also means that makerspaces or similar places can use octoprint to get an overview over which user uses the most filament. some places may even use it for billing…

I really want to help - where should I start working?

I myself perhaps three years ago started here and then read on to the Developing Plugins section. At the time I really wouldn't have called myself a Python coder but could code in almost everything else.

I just wonder if there has been any progress here. I use a makerspace in Oslo and we have some 10 FFF printers and it would be rather nice to keep track of usage and allow for some authentication etc. If there is anything I can do to speed this up, I'll do my best :slight_smile:

No progress in that direction. Job based access control is a long term goal, not something to expect falling out of things in a maintenance release.

1.4.0 has a granular permission system that should cover a lot of bases already, 1.4.1 will fix an issue with regards to a full read-only mode as well. This project is still primarily done by only me, and the pandemic has had me scramble to keep up with requests and stuff.

What can be done for this to be sped up? As a largeish makerspace, open to everyone, more or less, it'd be very nice to get some access control for the printers.

What exactly do you need in terms of "access control for the printers"? Have you taken a look at the existing possibilities with 1.4.0 with regards to permission management? What precisely are you missing from them?

The only way to speed things up is to contribute development resources. Read, someone has to sit down and develop stuff, in close cooperation so it is actually mergeable and doesn't cause issues with other established workflows.

As I posted initially, it's about allowing registered users (LDAP or something) to post new jobs, but not interrupt other people's jobs, since it can lead to a hassle if someone makes a mistake and with a makerspace with 300 members, these things will happen. I'll continue to try to find experienced people that know python well enough to contribute.

Thanks for your reply and your good work!