View Issue Details

IDProjectCategoryView StatusLast Update
0008648Multi Theft Auto : San AndreasScriptingpublic2017-06-29 00:54
ReporterGallardo9944Assigned ToJusonex 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Product Version1.5.3 
Target Version1.5.4Fixed in Version1.5.4 
Summary0008648: [Request] Allow clientside fetchRemote to access other servers
Description

I guess this doesn't need to be explained. MTA becomes REALLY limited when you can't access outside world directly from the client.

Some services require the same IP to be used everywhere. Example: you want to make a music player. Fine, we can request the list of links via php or via the server's fetchRemote, but if the links are sent clientside, the links can't be played due to API limitations (different IP = different link). Here worldwide clientside fetchRemote comes in really handy. I don't really understand the point of this "limit" and this limit should be removed.

TagsNo tags attached.

Relationships

has duplicate 0007713 closed New issues fetchRemote traffic limitation instead of IP limitation 
related to 0009474 closed New issues Make a custom downloading system without resource system 

Activities

AlexTMjugador

2014-11-23 12:42

viewer   ~~0022554

Last edited: 2014-11-23 12:42

View 2 revisions

I also don't really understand why clientside fetchRemote is so limited. You can already use events to send to clients any data (even malicious ones) returned by serverside fetchRemote. Perhaps it's blocked in the client due to unexpected DNS resolving being possible, but I think that scripts should be able to deal with that checking received data hash (you can't do anything that can damage a client's computer with current MTA functions).

Cazomino05

2014-11-23 12:45

administrator   ~~0022555

1) the possibility of using MTA clients as a ddos weapon
2) the possibility of downloading large things to MTA clients and is mitigated by the fact you have to use your own bandwidth, not someone elses

Gallardo9944

2014-11-23 15:26

viewer   ~~0022559

Last edited: 2014-11-23 16:19

View 2 revisions

  1. What's the problem of restricting those requests rather than simply blocking all of them?
  2. We can download stuff to clients with events, fetchRemote is not really the only method to do that.

vx89

2015-03-15 21:50

viewer   ~~0023092

Last edited: 2015-03-17 22:32

View 2 revisions

1) ddos can also be achieved via playSound function, which does not restrict ip.

I would love client-side fetchRemote to support other servers (and also https) to support Spotify's local server (http://cgbystrom.com/articles/deconstructing-spotifys-builtin-http-server/ )
cef3 integration might also allow it, but this would be a more direct approach. Which requires custom 'origin' header though (normal browser ignore such headers and also provide their own for security reasons).

Gallardo9944

2015-03-25 19:44

viewer   ~~0023123

As far as CEF is getting implemented, isn't it worth making fetchRemote cross-domain too? Browsers have the same functionaliy anyway, just without interface.

Woovie

2015-03-25 19:49

manager   ~~0023124

No.

qaisjp

2015-03-25 20:02

administrator   ~~0023125

Hmmm vc89, nice find.

thisdp

2017-05-07 02:33

viewer   ~~0025912

Why I think it is available to access other server is that
if fetchRemote use TCP protocol
1.Nobody want to use it to launch a tcp ddos attack because it is easy to fright against TCP ddos attack
2.We can use web browser's whitelist and blacklist to solve security problem.

So make fetchRemote access other server is reasonable

ccw

2017-05-07 02:56

administrator   ~~0025913

fetchRemote has recently been updated to work with CEF whitelists

thisdp

2017-05-07 03:08

viewer   ~~0025915

thx

thisdp

2017-05-07 03:17

viewer   ~~0025916

and this is duplicated https://bugs.multitheftauto.com/view.php?id=9474

Issue History

Date Modified Username Field Change