Safari PrusaLinlk Authentication with MK4
Opened this issue · 19 comments
Authentication eventually works in Safari, but login has to be attempted multiple (inconsistent) times.
- On entering IP Address into address bar
- Login appears as expected
- Enter 'maker' and paste in copied password
- Press "Log In"
- Login appears reappears unexpectedly
- Repeat 2 to 5 times (3)
- Now Logged in
Maybe related:
Closing tab with authenticated Prusalink sometimes leaves the page authenticated when reopened, sometimes not.
Occasionally I have seen a weird state where printer data is live updating screen but authentication alert or API Alert errors appear.
MacOS 13.2 (a) Beta (22D7750270d)
Same issue on Prusa XL
It never works on iOS. Tried a dozen times. IOS 16.5.
The problem is that it is not working on MacOS Safari. I turned off all these settings in Safari which could make problems, but without success. With a Arc or any other Chromium browser it is working.
I see the problem on Vivaldi on macOS too
Thanks for reporting.
This sounds like a problem related to Prusa Link itself, however, we don't seem to be able to reproduce the issue with other printer models. We should perform further tests with the MK4 model now and, until then, we can't exclude an issue with the specific MK4 firmware.
Normally we would transfer issues between repositories if needed but a specular issue was opened in the Buddy FW repository simultaneously (prusa3d/Prusa-Firmware-Buddy#3043). We can keep both issues open until we confirm the root of the problem.
Meantime, please save the credentials on your browser after the next successful login.
The browser autofill option should rule out possible user errors at least. We can start from there.
Michele Moramarco
Prusa Research
Found this issue after being unable to sign into PrusaLink on my new MK4 from Safari. Works fine on Chrome! I hate that! I hope you can find the issue.
Probably related too prusa3d/Prusa-Firmware-Buddy#3161
Same here. Safari Version 17.0 (19616.1.24.11.3)
Could you please provide us some screenshots form dev tools console and network tab while experiencing this issue?
Since the login overlay window does not disappear, the console does not really show anything :-/
If you need further information ... let me know.
Network:
Console:
tl;dr
The nonce becomes stale before the user has a chance to submit his credentials.
Hey,
I think I have found the issue, I am able to login successfully 100% of the time on Safari (macOS Ventura 13.5.1, running the latest 5.0.0 firmware on my MK4), and also reproduce a failure 100% of the time.
If you take a look at the code for the xBuddy firmware: https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/bfb0ffc745ee6546e7efdba618d0e7c0f4c909cd/src/common/http/types.h#L151 you will see that the server issues nonce is only valid for 5 seconds. If you fail to provide your credentials within this 5 seconds window, the nonce becomes stale so the server will reject the request.
I'm guessing Firefox and Chrome do something smart like, directly re-issue the request with the user provided credentials when the server responds with stale=true, but Safari does not (not sure what the RFC states regarding this behavior).
An easy fix would be to increase the nonce timeout in the firmware to something that would allow people on mobile devices to type in their passwords (something like 1 minute maybe), but this may have potential security implications, though I think it's no biggie.
edit: Another fix would be to have the server reply with auth_type=ApiKey (the same way Slic3r connects to the printer), the ApiKey being just the password. It seems like this flow is already implemented in PrusaLink-Web too, but since the server explicitely responds with a 401/digest auth request, the browser shows the auth modal window.
Typing the credentials after 5 seconds demo (fail):
Typing the credentials within 5 seconds demo (success):
Screw it! I just want a setting to DISABLE this layer of "security"...
The
noncebecomes stale before the user has a chance to submit his credentials.
Nice find! I built custom firmware with the change and it works great on both a mac and an iPad.
something like 1 minute maybe
I think it should be longer, since it can take a while to find and type in the cryptic system generated password. A good value is probably 300. That's the Apache server default (AuthDigestNonceLifetime 300), so it should be reasonable.
The change I tested:
diff --git i/src/common/http/types.h w/src/common/http/types.h
index 2c8a42b4..e5ce21b8 100644
--- i/src/common/http/types.h
+++ w/src/common/http/types.h
@@ -148,7 +148,7 @@ using Url = std::array<char, MAX_URL_LEN>;
// hopefully never gets stale nonce for request uploading a gcode, which
// can cause an infinit upload loop, if the browser does not read errors
// before sending the whole body.
-static const uint32_t valid_nonce_period = 5;
-static const uint32_t extended_valid_nonce_period = 8;
+static const uint32_t valid_nonce_period = 300;
+static const uint32_t extended_valid_nonce_period = 300;
} // namespace httpand to build the firmware (but to install, you'll have to break the appendix on the buddy board and supposedly void your warrantee):
sudo apt update
sudo apt install python3 python-is-python3 python3-pip python3-venv
git clone https://github.com/prusa3d/Prusa-Firmware-Buddy.git
cd Prusa-Firmware-Buddy
git checkout v5.0.0
python -m venv .venv
python utils/build.py --preset mk4 --build-type release --generate-bbf --bootloader yes
// output file is build/products/mk4_release_boot.bbf
Thanks for making sure and providing details instructions @jvasileff !
I agree copying Apache's default value is good idea.
I really want to tinker with the firmware, but I also don't want to void my new & expensive toy's warranty (I don't like it, but I understand why they do it like this).
Great to see that the cause behind this has been identified.
In the interim, I made an app for iOS that can be used to view PrusaLink. The repo for it is here if interested.
Hopefully someone can port it to Android too!
Prusa is so busy that their firmwares take ages to solve issues like this...
I created a fork of this repository which gets rid of the basic auth prompt, you'll be asked for your password instead (see screenshot).
This works on iOS too.
The password is then stored in localStorage so it survives a browser restart.
The fork is located here: https://github.com/pyrho/Prusa-Link-Web/tree/feat/apikey-auth
To run it:
$> npm install
$> BACKEND_URL="http://<IP ADDRESS OF YOUR PRINTER>" npm run start:mk4
You can then access it via any browser at http://<THE IP OF THE COMPUTER WHERE YOU RAN THE ABOVE>:9000
Thanks for reporting.
This sounds like a problem related to Prusa Link itself, however, we don't seem to be able to reproduce the issue with other printer models. We should perform further tests with the MK4 model now and, until then, we can't exclude an issue with the specific MK4 firmware.
Normally we would transfer issues between repositories if needed but a specular issue was opened in the Buddy FW repository simultaneously (prusa3d/Prusa-Firmware-Buddy#3043). We can keep both issues open until we confirm the root of the problem.
Meantime, please save the credentials on your browser after the next successful login. The browser autofill option should rule out possible user errors at least. We can start from there.
Michele Moramarco Prusa Research
Just in case it can help. I am using a MacBook Pro (Sonoma 14.1) with Safari and Prusa Link connects better than before but still it requires to try two or three times (Printer Prusa MIni+).
Thank you all for your feedback, especially thank you @pyrho for opening a Pull Request!
It seems we are close to a definitive solution - prusa3d/Prusa-Firmware-Buddy#3287 (comment).
Our developers are on it.
Michele Moramarco
Prusa Research