As I posted previously,
can we get CORS accessibility for API endpoints, at least only for OpenCloud endpoints? It’s impossible to create websites that access Roblox APIs from the web without hosting your own infra or trustiong some CORS proxy provider that they’re not gonna harvest API keys.
First of all, great changes. I think these will make the platform a better place and all around more secure. However, there are a few issues that stand in the way of these changes.
I belive changing errors to a standard format is something that has been needed for years. There is just SO many different error formats. (As someone who’s made Roblox API wrappers, this was something that ALWAYS annoyed me).
However, I do have a question: would it be possible to make all of the possible formats and error codes available on the docs page? If there’s going to be two possible formats that I have to check for with errors, I want to have a list of possible responses and error codes so I can make sure that I can cover everything.
For example, a not authorized response would include the old and new error response that our programs would have to be able to handle.
Even just a way to force the new/old errors. Being able to force opt-in would be really nice as well. Otherwise, there’s not really an easy way of handling this change, other than just spitting out a generic error is something goes wrong, which makes error handling impossible.
The new IP-locked cookies should be great for account security, and something that has been requested for years.
However, this does bring about a problem: running workflows that require cookies on a VPS or runner (like GitHub actions) will no longer work. An ideal solution for the time being is to allow us to create API keys which can function as cookies. Until all apis are supported by the Open Cloud API, we HAVE to use cookies, and so this change will prevent a lot of automated workflows and testing. Please consider this.
While these changes are great, I’m noticing a theme of neglecting to provide us with appropriate alternatives before removing features. Please add alternatives before you remove features.
I don’t want to be pessimistic - I just want to be able to use the API.
This has been brought up multiple times, but the apis at presence.roblox.com (Presence Api) still seem to be very inaccurate.
We will follow up on this issue.
Where do we submit the feature requests for the Open Cloud?
hi @LifeDigger - please submit a new Feature Request post on the dev forum under Website Features, e.g. Upload Images via Open Cloud API, and it’ll be brought to our attention!
it’s not often you see DevForum updates for the web API. thanks for this!
Is there any rhyme or reason to the 9XXX status codes? Should we look at those codes or the status code when determining the cause of an error?
Not everyone has access to the features requests category so it is impossible for most of us to submit them. A survey would be a good alternative
There are numerous cases where the HTTP Status Code does not provide enough information to know the cause of an error. For example, a 403 could be returned because of a missing XSRF token, or a lack of permissions on an endpoint.
The numeric error codes are intended to uniquely identify these common base-level errors so they are easier to handle.
Will we receive a index of the error codes at some point? As in 9001 = Error 1, 9002 = Error 2, etc. Also, will they be sychronized across all APIs, or be specific to each API? Will they overlap (123 means Error 1 in the users API, while 123 means something else on the games API)?
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.
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.
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?
We will follow up on this and make sure a replacement is available.
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.
Users can accidentally leak tokens just as easily as cookies, I don’t see what your point is here