View Issue Details

IDProjectCategoryView StatusLast Update
0007131Multi Theft Auto : San AndreasClientpublic2013-05-08 12:15
ReportervEnom.skAssigned Toccw 
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Product Version 
Target Version1.3.2Fixed in Version1.3.2 
Summary0007131: [REQUEST] client-side fetchRemote
Description

Desired use:

  • downloading files that change often directly from http server ( e.g. screenshot gallery, avatars, web content, latest gags )
  • using all MTA server's resources for syncing rather than file downloads. Especially useful for MTA servers with separate web server machine
  • asynchronous image downloads ( e.g. skin selection - instead of downloading all images on server join, loading them efficiently as player browses them )
  • downloading huge TXDs/DFFs files. Some servers use them heavily, it is not very comfortable to wait for 20MB download
  • downloading statistical graphs created on the web server ( e.g. money growth in time, pie charts )
TagsNo tags attached.

Users sponsoring this issue
Sponsors List Total Sponsorship = EUR 10

2012-07-05 23:22: SHC//Sniper (EUR 10)
Users sponsoring this issue (Total Sponsorship = EUR 10)

Activities

MCvarial

2012-06-24 12:14

viewer   ~~0016889

Even though downloadFile covers some of that functionality, I would love to see this implemented.

arranTuna

2012-06-24 18:21

manager   ~~0016890

"- asynchronous image downloads ( e.g. skin selection - instead of downloading all images on server join, loading them efficiently as player browses them )"

triggerClientEvent and triggerLatentClientEvent can do that.

Letting client scripts request files from other servers is a security risk as a server could use its clients to DDoS somebody.

Kernell

2012-06-28 05:02

reporter   ~~0016896

vEnom.sk,
This is a error in security for the client.

qaisjp

2012-06-28 18:07

administrator   ~~0016899

Mind explaining the security vulnerability?

I +1 this.

arranTuna

2012-06-28 19:54

manager   ~~0016907

qaisjp it's in my comment:

"Letting client scripts request files from other servers is a security risk as a server could use its clients to DDoS somebody."

A bit like sound streams.

MCvarial

2012-06-28 19:57

viewer   ~~0016908

I suppose some kind of protection could be added, like only 1 request every 60 seconds for the same IP.

drifterCZ

2012-06-29 12:05

viewer   ~~0016912

Last edited: 2012-06-29 12:06

What about allowing to acces only the server ip without any limit?

  • if other ip's also possible, limit could be about 10requests/30sec (you cant flood with it and its enough for some more complex work.

It will be very useful, even if yo allow it to call only server ip (where player is joined), if you dont want to allow all for security reasons

arranTuna

2012-06-29 13:31

manager   ~~0016913

"What about allowing to acces only the server ip without any limit?"

You mean the server that hosts the MTA server? Why not just use downloadFile then?

drifterCZ

2012-06-29 17:12

viewer   ~~0016917

Why yes? Host server is not only MTA resources folder... You have a lots of work ahead if you still didn't find it out.

arranTuna

2012-06-29 17:33

manager   ~~0016918

Junction, bridge, virtual directory, surely one of those things must allow you to access files that are outside of the resources folder through the resources folder.

PhatLooser

2012-06-29 18:30

reporter   ~~0016922

I've been thinking about it, and I've been thinking about it hard.
Almost all the big servers (CIT, etc.) that have more then 200 players (200 players, that can't be considered a botnet!) would never risk anything to be considered DDoSing.
After a few experiments, I can even say that a DDoS via MTA clients would be thinkable, but its unimagineable that a well-set homepage would even bulge at a "200 player DDoS" - especially because most of those players have a bunch of bottlenecks in their interwebs.
In other words, there should be a way to implement it. Maybe reduce the bandwidth depending on the player count, or make it a server-side command that forces the server owner to do it one client after the other.

"DDoSing" actually is already possible - I did a few tests on that and even thought about a report, if it wasn't such unuseable. Fun fact is, that my home internet was "attacked" by myself, and it took about 50 players to Deny the service of a 2 Mbit line (which actually sucks for a server).
Imagine CIT with 500 players attacking some homepage, it would be 20 Mbit of "attack power". Thats not something i'd use MTA clients for. Botnets are cheaper.

Considering the variables: Most kiddie servers have 10 players or less, and also, most "good" servers are well-managed, plus the fun fact that you can get bout 1000 bots for bout 10€, it would be a very expensive botnet to use the MTA clients for something like that. Especially because it can get the lil kiddie banned from the server host really fast if he gets caught.

So, my opinion is:
Downloading a file from a foreign server should be allowed, with limited bandwidth and a limited count. This way some of the server hosts have a chance to add some ads.

ccw

2012-06-30 04:09

administrator   ~~0016925

What is the downside with piping requests through fetchRemote on the server?

qaisjp

2012-06-30 10:24

administrator   ~~0016927

Well, yes, you can already DDoS (i think) by xRemote (callRemote or fetchRemote) serverside in a timer (I'm assuming).

ccw, do you mean fetchRemote client side will ask the server to fetch it and then send to client? I think the downside is server load... otherwise I don't think it would be a problem.

PhatLooser

2012-06-30 20:01

reporter   ~~0016931

Last edited: 2012-06-30 20:03

The main problem is that outsourcing data isn't possible any more.
Imagine running the MTA servers on one servers, and having the "stuff" on another, i.e. Clan management, Forum, etc.
Thats all.
(also, earning mones through advertising no moar possibru).

[GP_A]XetaQuake

2012-07-02 22:38

viewer   ~~0016944

It should be possible to fetch files that are hosted on the same server.

downloadFile() can't be used like this because you need to specify the file in the meta.xml - but sometimes you don't want this, for example, if you are trying to display avatars of users in-game (you can't add them once by once in the meta.xml)

This is a nice ticket that should be combined with #7150 - i think this would result in endless possibilities and even so in a safe environment.

vEnom.sk

2012-07-03 13:44

viewer   ~~0016954

If you are worried about security so much, you can always limit number of requests per second. But please, don't limit the remote server to be the same as MTA's.
All possibilities that this feature opens are simply worth the few issues. No big server would ever risk its reputation to DDoS someone like that. Perhaps some smaller servers would, but I guess 20 players can't do much harm ( especially with limited request per second flow ). And it would be surely noticed by players themselves.

PhatLooser

2012-07-03 13:47

reporter   ~~0016955

Last edited: 2012-07-03 13:51

Maybe if it actually gets noticed by the player it would be less of an issue. You should be able to see it in the console if its added, so players can see and report the abuse.
Another idea is the possibility to deactivate it client side, for those who don't want to risk anything.

qaisjp

2012-07-05 17:04

administrator   ~~0016966

and if the server and site are hosted in the same host, but different directories. Going from
server/mods/deathmatch/resources/resource/
to
../../../../../../site/whatever/www/
would be a pain.

PhatLooser

2012-07-05 20:28

reporter   ~~0016975

That won't work btw.
../../../ doesn't get accepted afaik.
If it does get accepted, its an exploit.

[GP_A]XetaQuake

2012-07-05 23:52

viewer   ~~0016976

As i suggested already, it would be the safest and best way to allow the client-side fetchRemote() access to everything that's on the same IP which is specified in the <serverip> setting.

the <serverip> setting should also be able to handle a domain name that will be resolved to the server IP by the client. But i created an additional ticket for this: #7150

ccw

2012-07-05 23:56

administrator   ~~0016977

Make a script which pipes the requests to a server side script containing fetchRemote

[GP_A]XetaQuake

2012-07-06 09:44

viewer   ~~0016978

Last edited: 2012-07-06 09:45

Thats how i do it. It would be nice to directly fetch a file by the client anyway.
There would be a performance effort, in particular for extra-large or a bunch of files.

This ticket is more a good suggestion than a urgently required feature.

[GP_A]XetaQuake

2012-10-06 23:25

viewer   ~~0017690

What is the current state of this? Although its a critical idea, imagine about the epic opportunities!

Creating a Gmod-Like window to spawn objects via thumbnails? You can't do this server-side without killing the server, at least if a large number of players need to be supplied.

So long as this feature must be enabled in the client options, i see no reason to not adding this! We should give it a try.

dennisuni

2013-03-07 00:04

viewer   ~~0018235

Any updates regarding client-side fetchRemote functionality?
A function like this clientside would open tons of new opportunities for developers.

PhatLooser

2013-03-27 14:40

reporter   ~~0018290

Please consider it...
Even downloading "only images, XML data and text files" would be a huge progress.

SHC//Sniper

2013-04-15 21:23

reporter   ~~0018346

Last edited: 2013-04-15 21:25

The mentioned security concerns mentioned are completely irrelevant compared to the opportunities given by a client-side fetchRemote. Also, piping fetchRemote requests through the server side is a very inefficient way and would only waste MTA's CPU time + RAM with latent event handles instead of just directly grabbing data from webservers that were developed to use very few CPU power when processing http requests.

MTA should remain a game(server) and not become a substitute for webservers.

DennisUniOn

2013-04-25 20:10

viewer   ~~0018402

https://code.google.com/p/mtasa-blue/source/detail?r=5304

Issue History

Date Modified Username Field Change