o you know if Voyager can send browser-like user agents when installed from App Store?
Voyager actually used to haha. But added a static voyagerapp user agent because lemmy.ml started blocking without last year 🫠 can’t win unfortunately. Thanks for fixing.
Btw, voyager PWA will always use browser ua, native app will use VoyagerApp/1.0 for api requests, AND <browserua> VoyagerApp/1.0 for browser managed requests (like loading images).
TLDR native app will always have VoyagerApp/1.0 somewhere in the string, PWA doesn’t touch the ua
i see. for PWAs that’s expected, for the native app i would’ve expected a consistent UA for all requests.
our current blocks/challenges are explicitly targeting things that pretend to be browsers while not actually being browsers. we try to exclude requests that are expected to be accessed by browser based clients that aren’t directly on the main site. appending to browser user agents still matches our browser user agent detection.
i’m not sure why this was causing issues here though, especially with the login, as that should just be 100% api stuff and therefore use VoyagerApp/1.0 from the native app?
I see what you’re saying, but I disagree it should be consistent: the user agent should accurately identify the software that’s requesting a resource.
When Voyager just sends VoyagerApp without the browser stuff, it’s because the code that is making the http request actually bypasses the browser entirely, and is done natively with CapacitorHttp (helps to bypass CORS for perf and server misconfiguration).
I could see an argument for changing it to CapacitorHttp/8.0 VoyagerApp/1.0 for API requests. But if voyager changed the header to include browser ua, that would actually be spoofing since the browser played no part of making or handling the request.
i’m not sure why this was causing issues here though, especially with the login, as that should just be 100% api stuff and therefore use VoyagerApp/1.0 from the native app?
Voyager actually used to haha. But added a static voyagerapp user agent because lemmy.ml started blocking without last year 🫠 can’t win unfortunately. Thanks for fixing.
Btw, voyager PWA will always use browser ua, native app will use
VoyagerApp/1.0for api requests, AND<browser ua> VoyagerApp/1.0for browser managed requests (like loading images).TLDR native app will always have VoyagerApp/1.0 somewhere in the string, PWA doesn’t touch the ua
i see. for PWAs that’s expected, for the native app i would’ve expected a consistent UA for all requests.
our current blocks/challenges are explicitly targeting things that pretend to be browsers while not actually being browsers. we try to exclude requests that are expected to be accessed by browser based clients that aren’t directly on the main site. appending to browser user agents still matches our browser user agent detection.
i’m not sure why this was causing issues here though, especially with the login, as that should just be 100% api stuff and therefore use
VoyagerApp/1.0from the native app?I see what you’re saying, but I disagree it should be consistent: the user agent should accurately identify the software that’s requesting a resource.
When Voyager just sends VoyagerApp without the browser stuff, it’s because the code that is making the http request actually bypasses the browser entirely, and is done natively with CapacitorHttp (helps to bypass CORS for perf and server misconfiguration).
I could see an argument for changing it to
CapacitorHttp/8.0 VoyagerApp/1.0for API requests. But if voyager changed the header to include browser ua, that would actually be spoofing since the browser played no part of making or handling the request.Yes, that’s right, that is odd! 🤔