The issue like what @NinjaFurfante07 has stated most people can’t post in this category as I believe it is for regulars only which at the current moment is impossible to get and kinda a pain ngl.
1 Like
SSL Certificates are NOT required to SEND A HTTPS REQUEST.
You need one if you want a Client to be able to properly send YOUR Server a HTTPS Request.
So, the only change required is changing your endpoints’ prefixes from “http://” to “https://”.
This topic is about the *.roblox.com web API, and not HTTPService. HTTPService will continue supporting HTTP requests.
2 Likes
This is correct.
We are requiring HTTPS for *.roblox.com endpoints, not for third-party domains that developers are using with HttpService.
You misunderstand - what this announcement is saying is that your ExpressJS app should use https:// when sending requests to Roblox’s domain. This announcement is not saying that HttpService will now require all sites to use SSL.
This is fine, but the issue I mentioned here really needs to be addressed. Removal of the current API with no realistic replacement is going to be almost lethal to so many of my projects. Such as RoLive which is used by hundreds of communities across the globe.
I cannot stress enough how important access to PlaceId → UniverseId translation is for the usability of our applications.
It is not practical for us to maintain an authentication cookie just to get a universeId. Then It needs to be used from the same IP address too?
1 Like
We will follow up on this and make sure a replacement is available.
1 Like
In that announcement, multiple endpoints still state that there is no current alternative, have these been since released / when can we expect these endpoints?
This action will not fully fix the underlying-issue in many cases, even with a static IP you must somehow get the .ROBLOSECURITY from that IP address which without visual access to that IP address cannot be obtained due to the captcha requirement for logging in.
This right here is why a bunch of accounts get leaked. Because, everyone in the known universe is encouraged to use a cookie. Which, as you said, completely bypasses the point of logging in.
This is the only platform that I’ve seen that actually encourages the use of cookies. I get that some endpoints don’t work on OpenCloud yet but, you have to remember that your user base and the people who use these tools are kids. Security is a foreign concept to the majority of them and giving them the exact tool and reason to use them is not smart at all.
OpenCloud is good and a fantastic step towards this direction but, encouraging cookie use until OpenCloud support (which has no real public timeline) is not it.
Authentication on this platform has never really been a strong-suit. And it’s unfortunate that for the niche people who use this (aka me) can’t just see a proper, concrete timeline for OpenCloud instead of opting to use a very inconsistent and insecure cookie-logging method.
From a third party library standpoint (I maintain one) and have a server of other maintained ones, it’s really bad, almost insane, to sit here and support cookie login. When a library supports this, we run the risk of our users leaking those cookies on GitHub or anywhere in the wild. Unless those cookies are invalidated, it’s extremely risky. Most modern APIs standardized the point of using tokens and having those as your access point on APIs that naturally do not affect end users.
Roblox is somehow backwards? Mixing development use with public APIs is just going to make it worse for the end user. That’s why no one does that.
For example, automation. Automation is good. People automate groups. Automation is bad so, people were mass botting groups.
Roblox’s Solution: Add capatcha’s everywhere on the site to counteract automation using the same APIs they encourage us to use.
Same End Result: Developer gets hit with hard ratelimits. Users get hit with a horrible web experience through capatcha hell.
Almost every negative impasse added to the site is because someone decided to implement malicious automation on public APIs that affect all users. Simply because, you gave them a clear path to your entire user experience and for years, no one cared.
If you already know the same result, why are we playing the same game over and over? Why is there no communication apart from an “obligatory message” on a service (OpenCloud) that is supposed to be the “biggest effort” for Third Party developers?
As of now, without thinking about OpenCloud, you’re suggesting that a cookie and using user-facing endpoints should be encouraged for use for developers. You’re naturally conflicting a customer / user needs with the developer’s needs and you’re trying to find a middle ground. That middle ground doesn’t feasibly exist. And it definitely doesn’t scale.
That being said, I think that OpenCloud should have a public timeline for support and that this announcement should really stress the point of this being a “temporary solution” until the timeline gives us a better solution.
tl;dr — Communication over here is a mess. Third party support feels like an obligation to make people happy instead of a genuine attempt to connect with third-party developers. Authentication on this platform is a total mess. I’m down to support OpenCloud on my library but, I absolutely refuse to care until there’s a timeline that I can see.
It’s been like 5 years now. Cookies not it. This whole limbo action with sorta-kinda supporting this and sorta-kinda not needs to stop. Pick a side. It’s impossible, as a developer, to really understand the direction of this if no one really cares to tell us. We’re basically dogs. Every bone you give us keeps us happy but, I can assure you that we’re all confused. And of course in the true Roblox fashion, silence.
You = Roblox; Not OP.
7 Likes
Users can accidentally leak tokens just as easily as cookies, I don’t see what your point is here
Thanks for the feedback.
To be clear, we do not recommend using cookies for developer use cases.
We are moving towards a future with Open Cloud where API keys are used for authentication, but it’s going to take some time to fully roll that out. Until that is done, we are trying to support the existing ways our developers interact with the platform.
3 Likes
Yet these tokens are much more limited on what they can be used for (datastore tokens can only be used on datastores and not selling off your limiteds, etc.)
Yeah, you’re right, the tokens would have less impact. Tokens would not mitigate accidental sharing, but they would mitigate the scope of what can happen if the token is leaked.
this is good feedback. the entire project is fairly early and there’s a lot of work even internally to sort things out. I’ll see what we can do about exposing a public timeline.
as for the part of using cookies - this is the only option we have today for developers to interact with our systems. agreed it’s not great and that’s why we’re working on Open Cloud.
4 Likes
I still do not understand how I will run CI/CD workflows to Roblox from a container. I cannot log in due to a captcha token being needed, and I certainly cannot do that on a headless container.
These IP-locked cookies are great and will help with security, but how are we going to run RobloxStudio if we cannot log in? There must be an alternative to this, as I run tests using run-in-roblox.
1 Like
Hi, I appreciate both your responses and the fact that this is being pushed. A lot of libraries, including my own, would be willing to move to OpenCloud if, as stated previously, we could see a timeline. We do have a significant amount of users and any breaking change would hold some level of significance and effort to implement. For that reason alone, it’s hard to hop on the “support train” for a push we have no visibility on.
As of now, we’ve been using web APIs with cookies and over the years (~4), we’ve seen countless get leaked by mistake. Majority of these cookies live inside various repos on a bunch of different public domains. Some even get outsourced through very weird methods. Personally, as an experienced developer myself, I haven’t felt comfortable with cookie-based login simply because, the user base and proper knowledge that these kids have about security is low. That creates an obvious liability for maintainers. Even if it isn’t our fault.
That being said, with more visible communication around this area and most would be more than willing to transition granted that OpenCloud’s functionality meets our user’s use-cases.
3 Likes
Are we ever going to get official support for creating developer products, currently we have to use the client API to do this which does not work very well especially when it involves the usage of cookies.
Looks like the Search API is broken? At least for me.
My Models, as said by this link:
https://search.roblox.com/catalog/json?CreatorID=825098526&Category=6
(best viewed with a browser than prettifies JSON)
I don’t own any models, and this bug also breaks Toolbox when searching for a specific user’s models. Even trying to search the official Roblox account’s assets yield the same front page items, regardless of asset type. Could this bug be related to these changes?
Since the change requiring cookie authentication to be from a static IP, my game’s continuous deployment script broke, because it uploaded a model to deploy the game’s code, as the game itself has millions of individual places that need to get updated. I now have to manually upload the model through studio to deploy changes. There should be a open cloud API for managing models as well.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.