I am currently exploring different processes for saving a javascript object generated by a user.
One option I am exploring is to require the user to save their data to a file, that they can later re-upload to the website to continue working on.
Problem is, I need a way to ensure that the save file cannot change between download and re-upload.
Making a save file with javascript is possible.
Freezing objects is possible, but I am not sure if this will prevent the user from manipulating the data before re-upload.
Is there a way to save a JSON object to a file and prevent the user from editing the file?
If you save an object locally onto a users HHD you cannot make it tamper-proof. They always have the ability to edit it no matter what.
You can however make it so you can test whether it's been tampered with using checksums and hashes and the like.
If your site knows when this has happened then it's easy - you can just check the file hash value against your value and if they're the same allow the user to pick up where they left off.
If it's being done anonymously then your file generation process must have its own encrypted/unknown checksum process attached to the file. Then on upload check again to see if tampering has occurred.
Again, I suggest you think in terms of DETECTING alteration rather then PREVENTING alteration.
Essentially what you want is a checksum to also be generated and verify against that. You can read more about methods to do so here: https://en.wikipedia.org/wiki/File_verification
If you truly wish to ensure the file has not been tampered, you will need to store the checksum results somewhere else that the user can't access.
Related
I am building a discord bot using discord.js and NodeJS. I have multi-line (about 20 lines long) message that I wish to send to a channel for a certain command. For improving the readability of the source code, I thought that I would use a different file for storing this message. Initially, I thought I would move the contents to a text file and then use fs.readFile() to read the contents. But, now, I think it's better to store the contents in a variable (lets say multiLineString in another js file (say message.js and export this variable from the file. That way, I could directly get the contents using require('./message.js').multiLineString. But I don't know if this is a good practice as I am new in NodeJS. So, which is the correct or better method, in terms of both memory and performance?
You should consider storing these messages in JSON files. (go read about JSON). They're safer than pure Javascript for this purpose: You have to totally trust the content of files you require(). But files you read and then do JSON.parse() on will just make that function throw an error if they're wrong.
The real question here is, whether you want to be able to edit that message on purpose (without having to restart your server) - or not.
If not, there's nothing really wrong with any approaches you mentioned. The only thing that you'd rather avoid is rereading the text on each request (especially with a synchronous operation). Slightly more time will be spent on converting the text read from a file system into a proper JS value, but that's really negligible.
However, if message itself should be dynamic and you want to be able to update it without having your server restarted, that's different. And if that's the case, strive for how easy is for admin to work with that file, not for how performant the operation is; you'll have to spend time on reading this anyway. The best you can do is to check some kind of 'fast' marker - for example, update time (if we still talk about the files) - before actually attempting to reread it.
I want to preLoad data from the server so that it will be immediately available when I call for it. The data is stored in a file called "data.json".
At first, I thought to save data.json to an object and reference it when I need it.
However, depending on the user's actions it may take a while before I need the data that this object has stored. So memory management becomes a bit of a concern as the object is quiet large (~5 mb).
My question is, when I call for data.json via ajax, does the browser internally "cache" this file for the duration of the website session.
Meaning, if I called for the file via ajax again after calling for it already, the browser would instantly get the file from its own internal memory instead of going back to the server?
If so it seems it would be wasteful saving an extra copy of this file in JavaScript. However, I can't find any information/standards about this online.
So in short, do I need to save the downloaded file to an object? Or is it safe to let browsers handle this internally?
There are several different types of "cache" in play here. It sounds like you're asking "How long does the browser's JavaScript engine keep an object in memory" and the answer is "As long as there's a reference to it."
The browser's (HTTP) cache, on the other hand, lives longer; an entry may live for days or weeks or years, depending on the available space, the freshness headers on the response, etc.
For a scenario like you've described, you probably want to prefetch the JSON to a local cache file, then load that cache file into JavaScript only as needed.
I am working with php and heatmap js to generate a heat-map.
I was thinking of going down the path of allowing the user to upload a floor-map jpg file initially and then allow him to add the sensor names to different locations in the floor-map.
Once the sensor locations are specified, I need to save that configuration to an XML file. Once I have this set of information (img_id, [sensorid1,x1,y1], [sensorid2,x2,y2],..,[sensoridn,xn,yn]), I can query my database for the latest values of sensors and then display as heat-map on the image (on the specific sensors' x and y coordinates) real-time.
I would like to know if saving the configuration as XML is the right way of doing it. Is there there a better way of temporarily storing the information using javascript/PHP?
There are likely a bunch of ways to solve this. My preference would be for JSON, as it is natively supported by Javascript and PHP. It is also MUCH easier to read and write.
When you say "saving", what do you mean? If you need it to be stored server side, then creating DB entities that the data structure can be mapped to and stored in will be far better than trying to create files server-side. Depending on how the app gets hosted, you may not have permission to do that, and if your server ever goes away you could loose that data (However, there are safe ways to create files using a service like AWS S3). Storing it in a database not only gives you a single place to worry about backups, but also lets you query the data in interesting and powerful ways (SQL etc) easily, without having to figure out how to do that for files with every new query.
I made a website for crowd-funding. I know that we should have used a platform for this. (other issues determined us not to)
The page that I have created has no database behind.
What I am trying to do is create some kind of hidden form that updates the sum that was raised so far.
I am not a very technical person but I do know that modifications made through javascript / jQuery ar usually temporary.
But, since scripts like website visit counters do exist I am wondering and appealing to the collective wisdom of this community:
Is there a way to update an attribute of a html element through some kind of hidden form without a database behind?
Perhaps writing to a .json file and updating the attribute from the data?
(I need to do this today as I will not be at the office during the campaign and it is very hard for a person that has no technical skills to do it... not that hard, but still, not user friendly.)
In order to display variable data, you need to get these data somewhere.
Do you have write access to your server file system?
What service level do you expect during data manipulation? Does it suffice if you just go and upload modified file every time manually?
What about embed in your Web page an IMG and then upload it with always the same name and different content?
There is a database even behind "dummy" hit counters, no magic.
I'm coding a website that involves storing very simple data, just a very long list of names with no additional data, on the server. As this data is so simple, I don't really want to use MySQL (it would be a bit too clunky) so I'm asking what's the best way to store very simple data on the server.
I definitely would favour speed over anything else, and easy access to the data via javascript and AJAX would be very good too as the rest of the site is coded in javascript/jQuery. I don't really care if the data can be viewed freely (as it will be available anyway), as long as it can't be changed by unauthorised users.
There are a lot of things to think about with this.
Is the information the same for all users with just a single set that applies to all users out there? Or is there a separate set of data for each user?
How is the data going to be served to the client, my guess here is that you would be having a web service or otherwise that might return a JSON.
From a security standpoint, do you want someone to be able to just "grab" the data and run?
Personally I find that a database if often a better choice, but otherwise i would use an XML file. Keep in mind though that you have to be careful with loading/reading of XML files to serve web requests to prevent any potential file locking issues.
Use an XML file that is web-accessible. Then you can query the XML file from the browser if need be, and still parse/write it in PHP. You'll want to use the flock function in PHP to make sure that two instances of a page don't try to write to the file at the same time.
Write it to a file and save the data as a serialized object. This way when you read in the data it's instantly accessible as the variable type you need (array, obj, etc). This will be faster than XML parsing.