search

titaniumnetwork-dev / Ultraviolet

A highly sophisticated proxy used for evading internet censorship or accessing websites in a controlled sandbox using the power of service-workers. Works by intercepting HTTP requests with a service worker script that follows the TompHTTP specifications.
https://docs.titaniumnetwork.org/proxies/ultraviolet
GNU Affero General Public License v3.0
441 stars 3.61k forks source link

Possible regression? Running latest stable with Ultraviolet-App breaks some requests. #64

Closed Ghxst closed 9 months ago

Ghxst commented 1 year ago

Issue tracker is ONLY used for reporting bugs. New features should be discussed on our Discord server.

I'm receiving transport errors / HTTP 500 responses on requests that previously showed no issues.

Most notably and easy to test are the requests to play.google.com/log and the batchexecute endpoints you encounter through google sign in on for example Spotify or Uber.

Other UV version that is tested was "^1.0.8-beta" which does not have this behavior.

Expected Behavior

I expect the requests to not cause any issues like before.

Current Behavior

Request are returning a HTTP 500 error

There was an error during the transport or processing of this request. Error code = 103, Path = /v3/signin/_/AccountsSignInUi/data/batchexecute Incomplete XSS header at end of request (500)

Possible Solution

Find out what caused the regression.

Steps to Reproduce

  1. Build and run app as per Ultraviolet-App instructions
  2. Navigate to https://accounts.spotify.com/en/login/google
  3. Open devtools
  4. (optional) submit any email, can be fake
  5. Observe console + network log

Context (Environment)

The easiest to reproduce this behavior on are

Aside from the 2 examples given this affects any website that has the google sso integration.

Tested against a UV setup that was setup using "@titaniumnetwork-dev/ultraviolet": "^1.0.8-beta" as dependency (not my setup, but I test it personally, it was provided by one of the kind people from the Discord).

It was suggested this could be a bare v3 issue, but I was informed that the UV setup above used the latest version of the bare server.

edit: After clarification the bare server version of the older working setup is actually v2

Ghxst commented 1 year ago

These requests don't seem to hit the bare server at all, they seem to fail in the SW part.

Ghxst commented 1 year ago

image image I don't see what could be failing the fetch() , any ideas would be greatly appreciated.

Confirmed with mitmproxy and debugging uv.sw.js that this 500 error is produced by the global catch when the fetch() throws this error.

Ghxst commented 1 year ago

ok when I manually execute the fetch the network tab gives me a Status that says (failed) net::ERR_H2_OR_QUIC_REQUIRED, likely because of the Streams api ? when I set the body to undefined and continue to execute the request, it will go through without issues and will hit the bare server, confirmed in mitmproxy. image

Ghxst commented 1 year ago

In firefox the requests seem to go through however bare is not handling the data that's sent, it drops the payload. image while in the network log you can easily tell the data is being sent like intended image

Ghxst commented 1 year ago

Rolled back to titaniumnetwork-dev/ultraviolet 1.0.10 and have no issues, this is definitely a regression :/

Ghxst commented 9 months ago

Was this fixed? If so can you link the patch here?