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.
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:
- Create a server instance via a provider (obtain a static IP)
- Load it with an OS (Operating System) that has a graphical interface and lets you remote. (I.e windows)
- Log into that box with creds that you have for your bot account.
- Grab the cookie as you would normally.
- 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.
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.
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.
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.
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
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.
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.