OAuth2 validation flow issues

[bnjmnt4n]

When running global-spotify-remote-mode, the Spotify login URL is continuously opened, and does not stop until Emacs is closed.

When running spotify-my-playlists (or any of the other functions), the Spotify login URL is opened only once, but the local server for the callback appears to be shutdown by the time I've logged in.

What I've had to do is to use spotify-my-playlists first to login, which redirects me to an unable to connect URL (since the server has shut down), then run global-spotify-remote-mode so the server remains available, and refresh my previously unable to connect URL, and try to Ctrl-G from global-spotify-remote-mode.

Additionally, I also had to apply https://github.com/bnjmnt4n/spotify.el/commit/2052913477b07c869a64f2329a6a27feee860450 to ensure that the directory for OAuth2 token storage was created.

[bnjmnt4n]

Apart from this issue with the OAuth2 flow, the changes in #64 by @jkdufair seem to be working great.

[jkdufair]

@bnjmnt4n FYI, this should be fixed with a recent commit to #66. Let me know if you still have issues with it.

[jcf]

TL;DR Firefox can end up sending requests that get a 404 back from httpd. If you experience this, it might be your browser config causing problems; try a private browsing session, or a fresh Firefox profile. For me, it was the IPFS Companion extension that broke things by assuming requests to http://localhost:8080/ were requests to a local IPFS gateway.

---

I'm experiencing issues with the OAuth2 flow too. For some reason Firefox gives me a 404 where curl will happily communicate with Smudge and its httpd servlet. I've seen this same thing in the past when I've tried using httpd to develop static websites, and ended up using a different HTTP server.

---

Update: looking at the logged requests from httpd, it appears Firefox and curl get a 404 and 200 respectively because they send different GET requests:

;; With Firefox, notice the `get` includes mention of protocol, host, and port.
(connection "127.0.0.1")
(request
  (date "Fri,  9 Apr 2021 10:41:22 GMT")
  (address "127.0.0.1")
  (get "http://localhost:8080/smudge-api-callback")
  (headers
   ("GET" "http://localhost:8080/smudge-api-callback?code=..." "HTTP/1.1")
   ("Host" "localhost:8080")
   ("User-Agent" "Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0")
   ("Accept" "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8")
   ("Accept-Language" "en-GB,en-US;q=0.7,en;q=0.3")
   ("Accept-Encoding" "gzip, deflate")
   ("Dnt" "1")
   ("Connection" "keep-alive")
   ("Upgrade-Insecure-Requests" "1")
   ("Cache-Control" "max-age=0")
   ("Content" "")))
(error 404 nil)

;; With `curl`, just the path.
(connection "127.0.0.1")
(request
  (date "Fri,  9 Apr 2021 10:41:38 GMT")
  (address "127.0.0.1")
  (get "/smudge-api-callback")
  (headers
   ("GET" "/smudge-api-callback?code=..." "HTTP/1.1")
   ("Host" "localhost:8080")
   ("Accept-Encoding" "deflate, gzip, zstd")
   ("User-Agent" "Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0")
   ("Accept" "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8")
   ("Accept-Language" "en-GB,en-US;q=0.7,en;q=0.3")
   ("Dnt" "1")
   ("Connection" "keep-alive")
   ("Upgrade-Insecure-Requests" "1")
   ("Pragma" "no-cache")
   ("Cache-Control" "no-cache")
   ("Content" "")))

I've also removed some info that was down to me misunderstanding how defservlet* worked.

---

Update 2: Chromium does the same thing as curl, and gets a good response from Smudge's httpd server. Looks like this is specific to Firefox.

---

Update 3: In a clean Firefox profile, I'm seeing the same behaviour across Firefox, Chromium, and curl, which leads me to believe there's some extension or setting that's causing Firefox to send proxy-style requests that include the full URL in the GET <request-uri> line.