Would be nice if we'd have some client-side storage-limited IO locked to the store folder.
null IO.WriteFile(string path_relative_to_the_store_directory, array<int> buffer);
array<int> IO.ReadFile(string path_relative_to_the_store_directory);
:edit: Files in store are cleared if they do not exist in the server's store directory every rejoin. Maybe VCMP/04beta/serverdata/ip-port.
:edit: Stream functionality like file in sqstdlib would be even better due to efficiency.
This was discussed before. I agree, we should be given a space of like 5MB to store our data in client side. But writing and reading files, never.
Quote from: KAKAN on Jun 09, 2017, 10:34 AMBut writing and reading files, never.
How else and why not?
Quote from: EK.IceFlake on Jun 09, 2017, 10:36 AMHow else and why not?
SQLite for example and security reasons.
localStorage or IndexedDB in JS standards. Something like that.
And for the other part, I said that it was discussed. So search it.
You read my mind about that , +1
but you know maybe it abused like making viruses and so on :v
We will never allow arbitrary client-side I/O since it can be abused to write malicious executables that automatically run when the player's computer is restarted.
At best we could give a limited amount of space per server for a key/value store.
Quote from: Stormeus on Jun 09, 2017, 09:52 PMWe will never allow arbitrary client-side I/O since it can be abused to write malicious executables that automatically run when the player's computer is restarted.
At best we could give a limited amount of space per server for a key/value store.
What about making a folder for the files and disallow the way to reach to any folder and making specific extintions that can't be excited
Like bat exe vbs and so on?
Quote from: Zeyad Ahmed on Jun 09, 2017, 11:28 PMQuote from: Stormeus on Jun 09, 2017, 09:52 PMWe will never allow arbitrary client-side I/O since it can be abused to write malicious executables that automatically run when the player's computer is restarted.
At best we could give a limited amount of space per server for a key/value store.
What about making a folder for the files and disallow the way to reach to any folder and making specific extintions that can't be excited
Like bat exe vbs and so on?
Sure, I'll just surreptitiously write 500GB of data to your hard drive to exhaust it then.
Oh, I know how to fix that, we'll just limit the amount of space a server has to write to the client's disk. But maybe I can crash your computer by writing a file named $MFT. (https://www.theverge.com/2017/5/26/15696704/microsoft-windows-7-windows-8-pc-crash-bug-ntfs) In which case we can limit writing data to a specific file per server, or limit the types of data that can be written.
Now we're just at this suggestion:
Quote from: KAKAN on Jun 09, 2017, 10:34 AMwe should be given a space of like 5MB to store our data in client side
Quote from: KAKAN on Jun 09, 2017, 10:39 AMlocalStorage or IndexedDB in JS standards. Something like that.
Quote from: Stormeus on Jun 09, 2017, 09:52 PMOh, I know how to fix that, we'll just limit the amount of space a server has to write to the client's disk. But maybe I can crash your computer by writing a file named $MFT
What the F*ckThat's why my D: Drive is corrupt and it says some $MFT bla bla and i cant do check desk
you know something i got a big
:v
I'll then recommend client-side SQLite storage, maybe with reversed endianness to prevent users from tampering with it using ordinary SQLite editing tools.
Quote from: Zeyad Ahmed on Jun 10, 2017, 04:55 AMQuote from: Stormeus on Jun 09, 2017, 09:52 PMOh, I know how to fix that, we'll just limit the amount of space a server has to write to the client's disk. But maybe I can crash your computer by writing a file named $MFT
What the F*ck
That's why my D: Drive is corrupt and it says some $MFT bla bla and i cant do check desk
you know something i got a big :v
For fucks sake we can read what you're saying there's no need for the size tags.
Quote from: EK.IceFlake on Jun 10, 2017, 04:58 AMI'll then recommend client-side SQLite storage, maybe with reversed endianness to prevent users from tampering with it using ordinary SQLite editing tools.
Why would you store anything on the client-side that you can't trust the client not to modify?
Quote from: EK.IceFlake on Jun 10, 2017, 04:58 AMI'll then recommend client-side SQLite storage, maybe with reversed endianness to prevent users from tampering with it using ordinary SQLite editing tools.
If you don't want the users to see or edit something, you should not be storing it on the client side. We will not be giving people the false sense of security that their completely broken approach is somehow okay. If anything, this store should be something standard that is easy to debug with existing tools.
What about XML data saving?
Quote from: Doom_Kill3R on Jun 10, 2017, 08:38 AMWhat about XML data saving?
XML is hard to naturally represent using Squirrel objects and SQLite is too complex for a small and simple client-side store. JSON would probably be the preferred approach if and when this is implemented.
Quote from: Xmair on Jun 10, 2017, 06:58 AMQuote from: Zeyad Ahmed on Jun 10, 2017, 04:55 AMQuote from: Stormeus on Jun 09, 2017, 09:52 PMOh, I know how to fix that, we'll just limit the amount of space a server has to write to the client's disk. But maybe I can crash your computer by writing a file named $MFT
What the F*ck
That's why my D: Drive is corrupt and it says some $MFT bla bla and i cant do check desk
you know something i got a big :v
For fucks sake we can read what you're saying there's no need for the size tags.
i know but iam suprised !
Quote from: Stormeus on Jun 10, 2017, 08:44 AMQuote from: Doom_Kill3R on Jun 10, 2017, 08:38 AMWhat about XML data saving?
XML is hard to naturally represent using Squirrel objects and SQLite is too complex for a small and simple client-side store. JSON would probably be the preferred approach if and when this is implemented.
Agree. And just like in JS, you can give us both localStorage for simplicity and IndexedDB. I personally like the 2nd implementation more, but you know, it'll be a bit hard for the ones not so familiar with it.
Quote from: maxorator on Jun 10, 2017, 08:36 AMQuote from: EK.IceFlake on Jun 10, 2017, 04:58 AMI'll then recommend client-side SQLite storage, maybe with reversed endianness to prevent users from tampering with it using ordinary SQLite editing tools.
If you don't want the users to see or edit something, you should not be storing it on the client side. We will not be giving people the false sense of security that their completely broken approach is somehow okay. If anything, this store should be something standard that is easy to debug with existing tools.
The same can be said about _mem, though.
Shh, focus on the current suggestion and don't start a debate about something else.
I find the reason that people can write malicious executables on others' computers invalid. Why? Because, at this moment, every file that you place in "YOURSERVERDIRECTORY/store" is downloaded into the client's computer. What about that :D ?
Quote from: EK.IceFlake on Jun 10, 2017, 09:49 AMQuote from: maxorator on Jun 10, 2017, 08:36 AMQuote from: EK.IceFlake on Jun 10, 2017, 04:58 AMI'll then recommend client-side SQLite storage, maybe with reversed endianness to prevent users from tampering with it using ordinary SQLite editing tools.
If you don't want the users to see or edit something, you should not be storing it on the client side. We will not be giving people the false sense of security that their completely broken approach is somehow okay. If anything, this store should be something standard that is easy to debug with existing tools.
The same can be said about _mem, though.
Yes, I think we've learned from that mistake.
Quote from: Shadow on Jun 10, 2017, 04:50 PMI find the reason that people can write malicious executables on others' computers invalid. Why? Because, at this moment, every file that you place in "YOURSERVERDIRECTORY/store" is downloaded into the client's computer. What about that :D ?
This has already been partially addressed. We already omitted the file I/O functions in Squirrel because a malicious scripter could've trivially escaped the data store.
This is kind of easy to detect, though, but then someone could just write as much data as they want without caring about how much space is available on the user's hard drive. At least with the download screen (and future refinements coming to it) this would be easy to detect.
Then we need to restrict the amount of space available to a few megabytes at most, at which point we're just going to restrict people to a JSON file that we manage anyway.
IMO SQLite would be much more manageable than JSON.
Making my own database library to interface with that JSON in a friendlier format would be quite fun though.
I really wanted to do this :( IO.ReadFile("../../../../password.txt"); (<<< was a joke)
IndexedDB (https://developer.mozilla.org/en/docs/Web/API/IndexedDB_API) then. It is more manageable than JSON, maybe SQLite too? . If not, then we come to LocalStorage, which is a variable dealing with JSON tables. That is what the devs are more likely to implement
The only way I could see the developers adding support for writing a file to a players pc would be writing a secrete fake windows file that is hidden, As well set to blend in with the registry or some type of other method. As well encrypted. And just name it a .dll maybe Windows_64_32.dll
This file would only be used for writing the players original UID at sometime when the player joins their first server. This would prevent ban evades etc.
Anything else would be highly useless, Sorry just trying to make the post more useful
That's all unnecessary and insecure. No one should be writing anything critical like UIDs for ban tracking to the client's hard drive. And there are other uses for client-side storage, like keeping track of settings for a server's GUI system or other client-side features.