Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safari PrusaLinlk Authentication with MK4 #386

Open
dsjove opened this issue Apr 9, 2023 · 19 comments
Open

Safari PrusaLinlk Authentication with MK4 #386

dsjove opened this issue Apr 9, 2023 · 19 comments
Labels
bug Something isn't working MINI/+/MK4/XL Relates to Buddy printer

Comments

@dsjove
Copy link

dsjove commented Apr 9, 2023

Authentication eventually works in Safari, but login has to be attempted multiple (inconsistent) times.

  1. On entering IP Address into address bar
  2. Login appears as expected
  3. Enter 'maker' and paste in copied password
  4. Press "Log In"
  5. Login appears reappears unexpectedly
  6. Repeat 2 to 5 times (3)
  7. 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)

@mix579
Copy link

mix579 commented Apr 24, 2023

Same issue on Prusa XL

@nullbreached
Copy link

nullbreached commented Apr 27, 2023

It never works on iOS. Tried a dozen times. IOS 16.5.

@ondratu ondratu added bug Something isn't working MINI/+/MK4/XL Relates to Buddy printer labels Apr 28, 2023
@SmithyAT
Copy link

SmithyAT commented May 23, 2023

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.

@ingorichter
Copy link

I see the problem on Vivaldi on macOS too

@Prusa-Support
Copy link

Prusa-Support commented Jun 23, 2023

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

@aaronvegh
Copy link

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.

@bolsoncerrado
Copy link

Probably related too prusa3d/Prusa-Firmware-Buddy#3161

@guddl
Copy link

guddl commented Aug 1, 2023

Same here. Safari Version 17.0 (19616.1.24.11.3)

@Lowentwickler
Copy link
Collaborator

Could you please provide us some screenshots form dev tools console and network tab while experiencing this issue?

@guddl
Copy link

guddl commented Aug 1, 2023

Since the login overlay window does not disappear, the console does not really show anything :-/
If you need further information ... let me know.

Network:
Bildschirmfoto 2023-08-01 um 17 53 19
Console:
Bildschirmfoto 2023-08-01 um 17 53 37

@pyrho
Copy link

pyrho commented Sep 20, 2023

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):
CleanShot 2023-09-20 at 14 40 04

Typing the credentials within 5 seconds demo (success):
CleanShot 2023-09-20 at 14 40 48

@bolsoncerrado
Copy link

Screw it! I just want a setting to DISABLE this layer of "security"...

@jvasileff
Copy link

The nonce becomes 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 http

and 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

@pyrho
Copy link

pyrho commented Sep 20, 2023

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).

@dunkmann00
Copy link
Contributor

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.

@bolsoncerrado
Copy link

Hopefully someone can port it to Android too!

Prusa is so busy that their firmwares take ages to solve issues like this...

@pyrho
Copy link

pyrho commented Oct 7, 2023

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.

CleanShot 2023-10-07 at 21 14 29@2x

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

@alternate22
Copy link

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+).

@Prusa-Support
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working MINI/+/MK4/XL Relates to Buddy printer
Projects
None yet
Development

No branches or pull requests