search

cryptoadvance / specter-desktop

A desktop GUI for Bitcoin Core optimised to work with hardware wallets
MIT License
808 stars 241 forks source link

Redirection not working when removing device #2063

Open aphex3k opened 1 year ago

aphex3k commented 1 year ago

Describe the bug When removing a device from specter desktop, the redirection is not working properly.

You should be redirected automatically to target URL: . If not click the link.
<html>
<body>
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href=""></a>. If not click the link.
</body>
</html>

To Reproduce Steps to reproduce the behavior:

  1. Remove a (bitcoin core hot wallet) device from specter desktop.

Expected behavior The wallet should be remove and the user flow should not be interrupted.

Screenshots image

Desktop (please complete the following information):

k9ert commented 1 year ago

Can't reproduce. I'd say that implementation can be improved but currently it works like this:

So if you adjust the url for your umbrel, does it redirect to / ?

aphex3k commented 1 year ago

Here is how I can reproduce it reliably:

  1. Add New Device
  2. Other
  3. Paste (any) xpub xpub6CtK6FS9iZp6HkRa8xHunR7CQrTSQKLNYpkjAuLhcgoSKFRpmoQVkgZBTV1319DdwyyZLKV7yLXFRbaMNwSB3Sq7vxu5uY4k5MkKEmCY8h8
  4. Name it whatever, I chose test
  5. Continue
  6. Cancel wallet creation
  7. Forget the device
  8. Error response

The redirection seems to work for GET requests from http://umbrel.local:25441/devices/device/<arbitraty name for non-existent waller>/ to http://umbrel.local:25441/wallets/wallets_overview/ according to Chrome developer tools the redirect fails from a POST however...

General Headers

Request URL: http://umbrel.local:25441/devices/device/test/
Request Method: POST
Status Code: 302 FOUND
Remote Address: 192.168.1.233:25441
Referrer Policy: strict-origin-when-cross-origin

Response Headers

connection: keep-alive
content-length: 206
content-type: text/html; charset=utf-8
date: Fri, 20 Jan 2023 17:21:19 GMT
location
server: Werkzeug/2.0.0 Python/3.9.16
vary: Cookie

Request Headers

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cache-Control: max-age=0
Connection: keep-alive
Content-Length: 116
Content-Type: application/x-www-form-urlencoded
Cookie: <redacted>
Host: umbrel.local:25441
Origin: http://umbrel.local:25441
Referer: http://umbrel.local:25441/devices/device/test/?newdevice=true
Sec-GPC: 1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36

It receives a 302 response. 303 is specifically used to redirect after a POST request so I believe the server should return a 303 instead of a 302.

k9ert commented 1 year ago

I can't confirm that on a development environment with the tag v1.14.3 checked out. I get this flow which is what i described above: image My assumption is, that this is a misconfiguration on the umbrel side.

Whether this is a 303 or 302 shouldn't matter. A 302 is a temporary redirect whereas a 303 is a permanent redirect. It might make a difference from a SEO point of view but not whether this is treated correct or not. We even imho need to use 302 here as we want to be free to change the implementation anytime.

aphex3k commented 1 year ago

There is not really any logs that I can provide to further debug what is going on, are there?

k9ert commented 1 year ago

I'd suggest to create an issue on the umbrel project and ask whether there proxy-config might have caused this. I can't reproduce it and it's very likely that it's a misconfiguration.