Tynezz
|
  |
| Joined: 28 Apr 2014 |
| Total Posts: 4945 |
|
|
| 10 Aug 2016 04:47 PM |
a. multiple events doing each their own purpose
b. one event that calls whatever function in a module script based on the arguments |
|
|
| Report Abuse |
|
|
Casualist
|
  |
| Joined: 26 Jun 2014 |
| Total Posts: 4443 |
|
|
| 10 Aug 2016 04:49 PM |
| I prefer b, it's just easier to maintain. |
|
|
| Report Abuse |
|
|
Real_Edgy
|
  |
| Joined: 23 Oct 2013 |
| Total Posts: 1212 |
|
|
| 10 Aug 2016 04:50 PM |
| yeah, b is your best friend. you can easily make a remoteevent/remotefunction that calls any one from any modulescript. just remember about client/server visibility issues |
|
|
| Report Abuse |
|
|
Tynezz
|
  |
| Joined: 28 Apr 2014 |
| Total Posts: 4945 |
|
|
| 10 Aug 2016 04:50 PM |
| also, is it better to have a 'key' so that people can't send fake requests? |
|
|
| Report Abuse |
|
|
|
| 10 Aug 2016 04:52 PM |
depends on what your remoteevent is doing
This siggy is copyrighted © |
|
|
| Report Abuse |
|
|
Tynezz
|
  |
| Joined: 28 Apr 2014 |
| Total Posts: 4945 |
|
|
| 10 Aug 2016 04:53 PM |
| but then, wouldn't they be able to view my code and then finding the key, which makes this useless? |
|
|
| Report Abuse |
|
|
Casualist
|
  |
| Joined: 26 Jun 2014 |
| Total Posts: 4443 |
|
| |
|
Casualist
|
  |
| Joined: 26 Jun 2014 |
| Total Posts: 4443 |
|
|
| 10 Aug 2016 04:54 PM |
| My last post was meant for killerbot |
|
|
| Report Abuse |
|
|
|
| 10 Aug 2016 04:54 PM |
I like a, I find it much easier to maintain with the way my code is set up. In the past I've used b, but I've adapted it since to suit my current programming style.
"also, is it better to have a 'key' so that people can't send fake requests?" I don't know what you mean by a 'key' and neither a 'fake request'. |
|
|
| Report Abuse |
|
|
Real_Edgy
|
  |
| Joined: 23 Oct 2013 |
| Total Posts: 1212 |
|
|
| 10 Aug 2016 04:54 PM |
have the server generate a key in realtime and encrypt it on the client
it's undoable but it's better than nothing |
|
|
| Report Abuse |
|
|
Casualist
|
  |
| Joined: 26 Jun 2014 |
| Total Posts: 4443 |
|
|
| 10 Aug 2016 04:56 PM |
| @OP Server should be validating requests independently of keys, key validation is only good for preventing other users from pretending to be someone else. |
|
|
| Report Abuse |
|
|
Tynezz
|
  |
| Joined: 28 Apr 2014 |
| Total Posts: 4945 |
|
|
| 10 Aug 2016 04:56 PM |
| that still wouldn't work right because they can look at the encryption source |
|
|
| Report Abuse |
|
|
|
| 10 Aug 2016 04:57 PM |
i would think you can invoke the server to generate a key and return that, then send that through a remote event
and then that won't be exploitable i would think
Formerly xXTheRobotXx, add 13,349 posts |
|
|
| Report Abuse |
|
|
Real_Edgy
|
  |
| Joined: 23 Oct 2013 |
| Total Posts: 1212 |
|
|
| 10 Aug 2016 04:57 PM |
real-time generated key
//REAL-TIME//
meaning the key isn't a hard-coded value that's encrypted
|
|
|
| Report Abuse |
|
|
|
| 10 Aug 2016 04:59 PM |
client script:
--invoke server, with return value being key fireserver with key val
on server
oninvoke:
math.randomseed(tick())
local key = math.random(1,1e7)
return key
onserverevent
if not key then p:kick()
Formerly xXTheRobotXx, add 13,349 posts |
|
|
| Report Abuse |
|
|
Tynezz
|
  |
| Joined: 28 Apr 2014 |
| Total Posts: 4945 |
|
|
| 10 Aug 2016 05:04 PM |
okay so im doing this:
in server: updating key every 60 seconds and sending a client event to everyone to update their keys |
|
|
| Report Abuse |
|
|
|
| 10 Aug 2016 05:05 PM |
you could have a module script function that does what i said for ease of use
but idk your method probably works too
Formerly xXTheRobotXx, add 13,349 posts |
|
|
| Report Abuse |
|
|
TimeTicks
|
  |
| Joined: 27 Apr 2011 |
| Total Posts: 27115 |
|
|
| 10 Aug 2016 05:06 PM |
@Tynezz, it really depends on the situation. For example I may have two totally differents remote for different things such as a chat handler verses one that clone a brick. You would name these separetely. However if you have a module that handles lets say spells, then you would do
spells.OnServerEvent:connect(function(prl,reason,...) if reason == 'blah' then
elseif reason == 'blah2' then
end end
|
|
|
| Report Abuse |
|
|
Real_Edgy
|
  |
| Joined: 23 Oct 2013 |
| Total Posts: 1212 |
|
|
| 10 Aug 2016 05:07 PM |
having a dynamic key might break some client interactions due to network lag and sending old keys
maybe keep a current and last key |
|
|
| Report Abuse |
|
|
Casualist
|
  |
| Joined: 26 Jun 2014 |
| Total Posts: 4443 |
|
|
| 10 Aug 2016 05:09 PM |
^^Lord has it right (in their first post, I disagree with his pseudo code), you have the client request a key and use that to sign their requests, but you still need the server to evaluate requests. All this does is prevent people from forging requests from other clients. The client can still fake their own requests (i.e. they can request 10000 coins for themselves still, but they can't pretend to be Lord_Narwhal and request 10k coins on their behalf).
I'd use http://wiki.roblox.com/index.php?title=API:Class/HttpService/GenerateGUID for auth.
i.e. local keys = {}
on server
oninvoke:
math.randomseed(tick()) local key = game:GetService("HttpService"):GenerateGUID() while keys[key] do --// astronomical chances of generating a key already in use, but still in the realm of possibility key = game:GetService("HttpService"):GenerateGUID() end
return key
onserverevent
if not key or keys[key] ~= player then --// reject the request rather than kick, because if they forge a request from someone else we've given them a way to kick other players. --// possibly flag all players for monitoring (1 flag per server they are in in which this happens, use flags count to narrow down offenders as time goes on) else --// process request end |
|
|
| Report Abuse |
|
|
kools
|
  |
| Joined: 11 Jan 2009 |
| Total Posts: 1659 |
|
|
| 10 Aug 2016 05:10 PM |
I disagree and think a is the better option. Option a allows you to more strictly do type checking on how your events are called (because you aren't working with optional arguments). It also allows you to visualize the different remote events and functions you have by traversing some folder in ReplicatedStorage instead of going through a code wall.
Option b requires you to flesh out a "key" system. That's simply an abstraction layer to provide the same functionality already available with option a! |
|
|
| Report Abuse |
|
|
|
| 10 Aug 2016 05:11 PM |
lol i didn't even know that generator existed
Formerly xXTheRobotXx, add 13,349 posts |
|
|
| Report Abuse |
|
|
Tynezz
|
  |
| Joined: 28 Apr 2014 |
| Total Posts: 4945 |
|
| |
|