|
| 26 Aug 2013 02:17 AM |
There is so much that you can do with these two methods that they just outweigh any cons you throw at it.
For example: * 3rd party databases to support global data persistence * scraping data from other sites (in game RSS readers) * advanced analytics (# plays per day, unique vs. returning players, etc) * more
Now the cons:
* games could get accused of DoSing other sites solution: add a reasonable cooldown time to both methods * user cookies can be stolen solution: send HTTPGet and HTTPPost requests from the server, not the client
It's 3 AM so I can't think of any other cons.
Discuss! |
|
|
| Report Abuse |
|
|
|
| 26 Aug 2013 04:07 AM |
It's possible to fix the first con by adding a limit and it's possible to fix the second by doing what you said (and also by just not giving the header info and only the response body).
I think the developers should try it. If it turns out really badly (it probably won't), then they can always turn it back off. Otherwise, they can leave it on. It would allow for so much that the pros would probably outweigh the cons, indeed. |
|
|
| Report Abuse |
|
|
|
| 26 Aug 2013 07:56 AM |
^
It was unlocked before for a short while and nothing _really_ bad happened. I really do believe it has amazing potential. |
|
|
| Report Abuse |
|
|
As8D
|
  |
| Joined: 24 Dec 2009 |
| Total Posts: 2907 |
|
|
| 26 Aug 2013 08:16 AM |
As long as we can get content from outside Roblox, it'll be great to have. Just imagine, then the spoiled up InsertService-restriction can be replaced (and probably more secure), as well as having server-DP-like-stuff.
Uh, I'd say having the possibility to send data is required. Otherwise, if we ex. want to log players in our server, as well as ex. scores, group statics and more (allowing for ex. a global message system in-game through a couple of popular games), that part will ruin it.
Sorry if I'm missing something, but there's not much harm you can do by sending data from a script. Then you could as well save it on a PBS and check it once in a while...?
- As, neko-sama. meow. |
|
|
| Report Abuse |
|
|
|
| 26 Aug 2013 11:42 AM |
This, quite frankly, sounds like a terrible idea. Reading 3rd party websites? Extreamly abusable. Reading any CSRF tokens and data from the client that requests? Terrible. Even if it's on the server, that is still a terrible idea because it's impossible to moderator and would be full of security holes. |
|
|
| Report Abuse |
|
|
|
| 26 Aug 2013 11:47 AM |
| At the very least we should be able to access the raw data from some certain pages. Like https://api.roblox.com/* and certain JSON URLs on the main site |
|
|
| Report Abuse |
|
|
|
| 26 Aug 2013 05:22 PM |
| RenderSettings: How is reading 3rd party websites abusable? If they contain any foul language it'll never show up since any output method you choose (GUIs, etc) filters its input. And I fail to see how this could lead to major security issues if it's executed correctly. |
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 26 Aug 2013 05:24 PM |
| @Techboy Reading 3rd party websites may be against it's copyright? |
|
|
| Report Abuse |
|
|
|
| 26 Aug 2013 05:28 PM |
| cntkillme: Even if it's against that site's ToS, the worst that can happen is having ROBLOX IPs banned for that specific site. You can't get in legal trouble for just crawling a public site. |
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 26 Aug 2013 05:30 PM |
Roblox should make it white-listed then. Because Roblox probably can get in a lot of trouble. |
|
|
| Report Abuse |
|
|
dekkonot
|
  |
| Joined: 22 Dec 2010 |
| Total Posts: 6685 |
|
|
| 26 Aug 2013 05:31 PM |
Umm...
~ Linguam latinam est optimum ~ |
|
|
| Report Abuse |
|
|
oxcool1
|
  |
| Joined: 05 Nov 2009 |
| Total Posts: 15444 |
|
|
| 26 Aug 2013 05:34 PM |
HTTPPost is bad idea, especially locally...
HTTPGet seems total useful and save. Theres already methods that sends requests to ROBLOX server such as Preload. So cookies isn't a problem, especially if server-side. |
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 26 Aug 2013 05:35 PM |
Honestly, they should allow many other protected methods. Like ScriptContext.Error |
|
|
| Report Abuse |
|
|
Bubby4j
|
  |
| Joined: 25 Dec 2008 |
| Total Posts: 1831 |
|
|
| 26 Aug 2013 05:36 PM |
| Seems like you could make it unabuseable, make it so each user has to verify that they own the domain which it makes requests to (such as uploading a verification page like google webmaster tools requires) so that they could only DDOS their own website. |
|
|
| Report Abuse |
|
|
|
| 26 Aug 2013 05:37 PM |
Running it server side exposes all the server-only URLs (see gameserver.ashx) that regular places aren't supposed to have access to. I propose HttpGet just blocks access to these URLs and run it server side as originally planned.
|
|
|
| Report Abuse |
|
|