Haven’t been able to log in

Gingerlegs@lemmy.world · edit-2 5 days ago

Haven’t been able to log in

MrKaplan@lemmy.world · edit-2 4 days ago

Hi,

this was possibly an unintended side-effect of our increasingly aggressive AI crawler DDoS blocking. When increasing the scope of issuing Cloudflare challenges we missed excluding API endpoints from the rule, that should be fixed now.

This should only have affected clients with browser user agents though, and I see requests with user agent VoyagerApp/1.0. @aeharding@vger.social do you know if Voyager can send browser-like user agents when installed from App Store?

aeharding@vger.social · edit-2 4 days ago

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 <browser ua> 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

MrKaplan@lemmy.world · 4 days ago

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?

aeharding@vger.social · 3 days ago

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?

Yes, that’s right, that is odd! 🤔