Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
1.4.0rc3 exception - Insufficient permissions #3375
What were you doing?
Printing (from OctoPrint) using 1.4.0 rc3 (latest from github staging/devel branch). Running with Python 3.8
What did you expect to happen?
No exception in the logs
What happened instead?
Found the exception below while tailing octoprint.log. I do remember seeing this error before but not 100% sure.
Did the same happen when running OctoPrint in safe mode?
Version of OctoPrint
Latest from staging/devel. OctoPrint 1.4.0rc3.dev9+g124f01ca running on OctoPi 0.15.0 (environment up to date).
Operating System running OctoPrint
Raspbian. Using Python 3.8
Printer model & used firmware incl. version
Ender 3. Marlin 2.0.0 (released version)
Browser and version of browser, operating system running browser
Link to octoprint.log
Can provide if needed.
Link to contents of terminal tab or serial.log
Can provide if needed.
Screenshot(s)/video(s) showing the problem:
I have read the FAQ.
Log is available here: https://gist.github.com/gdombiak/d0813fed419e27a0a641932b769e4758
That log includes this exception as well as more examples of the other exception reported in the other issue.
There's a whole bunch of 403's that go before this exception (which I need to figure out why it gets logged with a full trace and causes a 500 instead of simply returning a 403 as well). That reeks a bit of a lost session and hence #3370 which I already fixed in current RC3.dev versions late yesterday afternoon. It's sadly hard to say because you redacted the client IPs, which are the key here to figure out if it's indeed the same session issue. Can you check if the IP for which the login was logged at line 1701 (
At least the 500/stack trace should be fixed by the above commit. Actually not a regression in 1.4.0 but 1.3.11 already.
Still thinking the permission loss that triggered it is actually caused by #3370. Would be great if you could confirm or deny or just test if it is still reproducible with current
Arrggg! I never delete logs but just did that when running my other tests to have clean logs ...... grrrrrr!
I will try to do my best to find a way to reproduce this error. I only saw it once ever in the logs. Will see if an old http session can do the trick.
You frown, but for me that is good news because it sounds like the 403 was indeed the one from #3370.
I want to try to push out the third RC before that, so let's just hope it's really gone ;)