Create a VRChat API proxy layer

[TapGhoul]

The logic has a few parts: auth, 2fa, and actually making requests. First, for all requests of all types, you need a useragent in the form of WaterWolf/1.0.0 issues@waterwolf.club (replace email as required) All API requests need to go to the host https://api.vrchat.cloud/

---

For auth:

To perform authentication, first perform a GET request to /auth/user with the header Authorization: Basic base64(urlencode(username):urlencode(password)) - standard BASIC authentication method, just with urlencoded parts. This should be using the URL-safe form of base64. Capture the created auth cookie for future use. You should either get {"ok": true} (if you already have a valid 2FA cookie) or {"requiresTwoFactorAuth": []} with the values of either emailotp, totp or otp for email 2FA, TOTP or recovery code.

To perform 2FA, you need to POST to https://api.vrchat.cloud/api/1/auth/twofactorauth/totp/verify, with a JSON body of {"code": "otphere"} (replace the "totp" in the URL with method - we only want TOTP). You should get back a response of {"verified": true} and a cookie set of twoFactorAuth - keep this handy.

You can do these either once a week, or just keep tabs on the cookie expiry of these two to redo it when needed. These will have different expiries, and can be renewed separately - they are not paired beyond the account they belong to.

IMPORTANT NOTE - doing this too often can lead to an account ban. You can do it a couple times and be fine, but you shouldn't be doing this more than once an hour at the most. But realistically the cookies last at least a couple weeks, so this is not something you should need to do frequently.

---

For requests:

For requests, you should just pass through anything requested, with the following conditions:

• Rate limit requests to only allow 1 request per second. Any faster and it may make vrchat unhappy.
• If you get back the status code 429 (too many requests), you must wait 5 seconds, and try again (with a maxumum request count). Note, some endpoints should not be retried, so this should be opt-in - primarily invite messages, invite response messages and bio updates will get this status code for one request per half hour. For these, you should not retry.
• If you get back a 401, time to re-auth! You should be monitoring this separately at the start of a request, deferring as needed to perform proper auth at the start of a request, but this is less important.
• Other status codes should be passed back to the requester, such as 404, where the entity does not exist, or 403, where the authenticated user lacks access to the resource.