I would rather you be inconvenienced than the community have their accounts risked through cookie logins. Better security trumps whatever off platform web api nonsense you are doing.
The percentage of users getting their accounts stolen outweighs the small fraction of web developers on the platform.
Better idea: allow users to enable/disable cross-IP cookies.
We are only facilitating small & large groups, such as 2M+ member communities. It’s a significant portion of the Roblox experiences.
This is not a small inconvenience, to get the token to use in the integration you need to login to your roblox account and grab it, but when you put that token into the integration it will then be invalidated due to it having a different IP. Basically it will be extremely hard to do any sort of integration with this change.
It broke our place publishing, our game when published to github pulls models from another place and then publishes the game and models to roblox. But since the cookie now gets invalidated this means that this does not work at the moment and we cannot release updates.
This change is hurtful to my ranking/management service and that of countless others within the community. Many of the core features that we provide revolve around using client-provided .ROBLOSECURITY cookies, necessary for their intended functioning. This is hurting us and our users who have already been affected by this change. Due to the way our infrastructure is scaled, there is no feasible way for us to circumvent this change in a manner that allows us to continue with our current feature set.
I am rooting for all other developers and services out there that this change is reversed, and or an alternative method of authentication for scenarios similar to this is introduced and provided in a timely manner. The fact that this change was made without any advance notice or even at the least a statement notifying of this change (of any sort) is very appalling.
Breaks our game.
Seems shortsighted to remove this feature.
Perhaps an alternative solution if this is intentional is the ability to label an account as an automated account.
I.E Like discord bots, would allow for automated accounts that dont have this issue while also protecting users from cookie stealing.
Coming soon is not enough. This update breaks my applications and is also very counter intuitive - Roblox encourages us to authenticate with cookies when making API requests - even when we do not necessarily need to be authenticated, and gives us higher rate limits. This change is good for security but cannot be rolled out until there is another solution.
EDIT: Maybe we can see a solution as to whitelisting IPs, such as many other providers offer? This would allow me to whitelist my VPS.
What are you on about? There is only one time the captcha is needed which costs about 5 cents, and thats to retrieve the account cookie. The amount of members does not matter.
Alot of services use multiple IP’s which would mean every time the service needs to do something on another IP it would need to complete a captcha, you can’t assume that Chris uses a fixed IP for everything.
Roblox decided to use a wrecking ball and destroy every application that uses their APIs with this update…
I use proxies for my ROBLOX projects constantly & with this brand new update coming into play, I receive 401s always & every cookie invalidates. This has to be possibly the worst update they have come up with… by far…
Please revert this update; all of these applications have gone into the wasteland after this update & which makes it impossible to use the API without getting rate-limited or receiving an unauthorised response.
That’s not how it works, if you’re running it on a VPS, probably do more research?
How this works is that it’ll grab a new Roblox account cookie if the cookie is invalid, this is repeated.
God this is gonna mess up a ton of bots and websites.
What I would love to see is the Roblox team make it more easy for us to create applications with the web endpoints. Ngl the guide itself is not that clear for beginners.
Just install some type of GUI (of the many we have) on this machine, and after that clean it up or disable.
Why could they not just make 1 user per cookie, or just stop the hacker from logging in but without expiring the whole cookie? (This is just a question, if they can’t do that it’s ok.)
Sorry for the late reply, but thank you for clarifying it. I didn’t even consider them.
I had this happen to me, took me a bit to realize this was why the authentication was never working.
Quick edit: @aze_rty provided a significantly better solution that works on lower-end servers. I didn’t take into consideration system resources for most situations where a lightweight VPS is all that’s necessary, so this solution isn’t very useful or helpful to most.
To solve this, I just used X11 forwarding over SSH to pop open Firefox and sign in that way. It’s extremely simple if you have the latest version of Windows 11 (Build 22000+) and WSL 2.
ssh -XC user@server from WSL 2 running Ubuntu 20.04 on Windows 11
-X enables X11 forwarding
-C is for data compression (loads everything a bit faster, but expect severe input delay and lag regardless if this is enabled)
After that, you install Firefox through your package manager and just run it. I can’t speak for what issues others may run into, but it was that simple for me.
I tried to reproduce this issue with two different VPNs on Edge browser but couldn’t do it. why is it not happening to me? is it fixed?
It’s either fixed or rolled out to only selected people.
Try doing this with 0.5 mb of ram on a 3 dollar VPS and it wont go well.
Proxy into the webserver instead.
It’s out for group of users. It’s called A/B testing.