IP Changes Invalidate Cookie

I understand this change is overall to protect account security, but as stated a multitude of times in this post this really puts a huge strain on most forms of automation. I’m hoping Roblox is willing to reconsider this, or at the very least make a viable solution for people who legitimately use forms of automation. Even a heads up would of been nice and given me some time to create something that’s compliant with this change, but unfortunately myself and a lot of my friends are scrambling right now to ensure there isn’t too much downtime regarding various automation bots.

1 Like

@xChris_vC and I run RocketApps. (application centre and Roblox API provider). We are noticing more requests failing than usual but still about 60%, maybe even a little more, goes through like usual.

We have no idea why some cookies got invalidated and others haven’t.

Due to the way that our system was designed, every request to the Roblox API is being sent from another IP address.

Are we certain Roblox is invalidating cookies based on the IP address they’re being created with (login)?


This is part of an A/B test of a new security feature. These sorts of things really should be announced prior to being a thing.

A decent chance this change wasn’t rolled to your remaining cookies. It must have only been rolled out to some % of Roblox users (which is well what A/B testing is).


Yes Correct, I can confirm that the cookies that are regenerated are the ones when you log in from america & UK, If you are European and you log in from Germain, Spain, France and other similar countries you do not experience this problem, Probably some of your IPs are from European countries.

1 Like

This is actually a super smart way to prevent cookie logging. It’s not a guarantee though.

Here’s a work around that I tested yesterday and should work:

  1. Create a server instance via a provider (obtain a static IP)
  2. Load it with an OS (Operating System) that has a graphical interface and lets you remote. (I.e windows)
  3. Log into that box with creds that you have for your bot account.
  4. Grab the cookie as you would normally.
  5. Run bot on the same machine.

Because you logged into the box with the same creds and you have a static IP (which will not change), it’s essentially the same as logging into your personal computer. If you’re using linux and you have an active SSH terminal, you probably won’t get around logging in because of the active captcha that exists on a few endpoints that authenticate you (afaik command line based tools like CURL won’t work). That’s why it’s imperative to get as close to your personal computer as possible.

Cookie login methods (all of them) are bad.

I think the idea here is to move fully to OpenCloud which does in fact provide an IP whitelist. They could be setting up for future use cases. I.e whitelisting certain APIs that they want developers to use. As opposed to unlisting the docs page when usage is discouraged. OpenCloud is an effective way to do just that.

Web API development is not officially supported by Roblox. We all knew this walking in. Over the years, they’ve made changes that directly benefited their views on the platform. Since this is purely security and helps to protect millions of accounts from being logged externally, it takes precedence over the minority of developers that use it to bot.

If it was the opposite and bots were officially supported (akin to Discord), the lack of input would be concerning. However, it’s not and therefore they don’t actually owe us a response.

If you’re testing a security feature that actively blocks a bunch of account phishing exploits, the idea is to not directly tell people. Why? It gives people a whole lot of time to develop a counter-exploit. Especially when the system isn’t 100%. The time between which it’s being tested to when it’s fully rolled out could span months and a single exploit could affect the system entirely which again, could potentially affect a fair number of accounts. This is a common security notion / practice across most companies. Unless you bot or phish, the user shouldn’t directly be impacted by this.

I think that a VPN is the least of your worries if you’re storing private information directly on your laptop. Chances are that the VPN is directly from the company that you work with and if that’s not the case, that’s pretty unfortunate. VPNs are typically used to be anonymous and to hide IPs. They’re a really good vector if you want to phish. The actual functional purpose of a VPN goes directly against this feature frictionally. If you were to allow VPNs, this feature wouldn’t exist.

Now, I do have a library that deals with cookies. I hate the fact that I have to use cookies and encourage their use. If Roblox wanted to whitelist the certain APIs to bot accounts, this is a decent way to do it. OpenCloud is a much better interface and cookie-based login was always supposed to be inherently temporary.

While this change does come as a surprise and many of the people on here seem to be overly dramatic, for once (and I don’t say this often), this is a much needed security change. The pros of this change completely outweigh the cons. Bot developers on this platform have always been a niche community. Account integrity issues on this platform have always been a widespread issue. Captcha being a bandaid fix. The console warning people. It’s clear that they’re taking this issue very seriously and quite frankly, if this helps a bunch of people from not losing their accounts, I’m all for it.

Even if it means that my own library will be impacted negatively. I can’t in good faith submit myself to constantly recommend cookie usage directly. Roblox has a very young user base. Many of them do not know what account security is or care. That’s part of the downsides when being on a platform that has a bunch of kids. Whether you bot / automate or not and you use an unprotected method to authenticate, thousands of bad actors are doing the same for malicious reasons. Thousands that supercede the select few doing it for good reasons.

If it’s not supported on OpenCloud and it won’t be supported on OpenCloud, it’s probably because Roblox doesn’t want you to do it. If it will be supported, wait it out. It’s a better long term solution than whatever you think you can come up with.

Something to think about. 2c.


I don’t agree with this at all.

When a company explicitly makes their web endpoints public with docs, even makes articles for some of them on the DevHub, creates a thread for when those endpoints are deprecated, and gives announcements when things change, it is “officially supported”.


A company can make their docs public all they want. They have, and have always maintained that they have no opinion towards it but, that it’s not officially supported. You’re mixing the term “support” with “convenience”.

If it was officially supported, we wouldn’t be on this thread talking about cookies nor would they be unlisting, removing or captcha’ing endpoints without developer input. : )


Or make it only for developers, for exemple Jenny is a developer and she want to get cookies, roblox just check if Jenny is a DevForumMember or if she have agreed on cookies TOS (thats can be a good idea too) then she can get the cookie.


This is a good point - if they intended to properly support the workflows of Roblox web developers, we wouldn’t be here.

However, when Roblox does the things I’ve mentioned (and even create flairs on the forum for web developers fwiw), that implies that Roblox sees web development on their platform as a legitimate thing and not just “no opinion towards it”. They should have announced this change, and we didn’t all have this coming.

I also can’t see any direct security risk if they had announced this a day or a week earlier - what could cookie loggers/abusers have done during that time (besides just attempting to steal as many accounts as possible until the change rolls out)


Its possible that they made this change by mistake or they didn’t consider this specific use case for this change, roblox is a big company and all it takes is a decision made by one employee to increase security not considering this use case and we end up with this situation.

As I mentioned earlier, they can easily take this time to look for alternative methods that would get them the same result. This is why a lot of us have seen an uptick in fake discord server mods scams where people essentially fake screenshots and then impersonate a moderator of a server. From there they try to capitalize on the fact that you’re panicking about something you haven’t done and ask you to reveal information that you otherwise wouldn’t of had given up.

1 Like

In a normal society, that would make perfect sense but, this is Roblox and I can assure you that they’re far from normal. Unless they say the words “we officially supported bots”, it’s not officially supported. OpenCloud is a push towards that. However, with the current methods used to login, Roblox wouldn’t support a use case that can directly lead to the loss of someone’s account. Especially when they’re going this far to prevent it. “Web Developer” can literally mean anything web-based. Not everything web-related has to do with APIs.

If you’re testing a system (A/B testing) that relates to security, what are one of the things that they’re testing for?

Integrity. More specially account integrity.

If you’re an attempting to develop an exploit that directly phishes accounts, what do you think that exploit is targeting?

Integrity. More specifically account integrity.

By the transitive property of common sense, we can conclude that they want time with minimal interference to make sure that this system is concrete. Announcing it across the platform while it’s not concrete is not a smart play.

Truthfully, I don’t know what it is someone could develop in this time span because I don’t actively phish accounts. That being said, just because we don’t know doesn’t mean that someone else doesn’t.

If you’ve ever worked at a big company, it definitely isn’t one person. It’s a team of people. Often times cross functional. As weird as Roblox is, I think that they thought about this for a while and that this is a change that needed to happen in order for us to get anywhere in terms of automation support on this platform.

1 Like

This change (or at least what I believe this change is intended to be) would prevent all methods of stealing cookies to gain access to someone’s account, including cookie logging and sending people the cookie through some other means.

They can look for “alternative methods” (which would be vulnerabilities if they existed) during this time as well.

1 Like

I know, I was using that as a example about how it could easily be overlooked.


I’ve had that happen to me twice.

They’re incredibly annoying when you can’t get hold of a real mod/admin of the server to report the issue and get unbanned.

I’ve now disabled Direct Messages from Server Members for all servers to stop it happening.


If you look through the devforum you can see cases where staff respond acknowledging and ticketing unintended endpoint behavior, so they are maintaining the endpoint based on user’s reports.


Those endpoints directly affect users. So any issues that you find on those endpoints can affect users. If this wasn’t the case, they wouldn’t care.

Well after a few years Roblox is finally doing something about compromisers I guess

1 Like

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.

  • User accounts will have improved security.
  • Automation can still go through as usual (as those accounts can opt-out).

We are only facilitating small & large groups, such as 2M+ member communities. It’s a significant portion of the Roblox experiences.