I have been working on a library which enable a website to add a comment section to their website.
The idea was to keep it as lightweight as possible thus I preferred to use JSON for basic data storage like comment's message, website and username. All of these data is public and can be access directly via JSON. I don't mind this since comments are going to get display publicly anyway.
However, the problem arises when I want a user to be notified when someone replies to their comment. Email is there in input field but I don't want it to be stored in the public JSON file. Is there any other server side data storage schema where I can store the email privately and at the same time use those emails from server side scripts to send email?
MySQL and others will make the library clunky, so that's out of the list.
Or even beside these conditions is there any other possible way to do this?
What you need is APIs and not a data source. A data source is a truth where all data lives. Like in your example, if you have email in your data, it will always be there. Unless you keep email field separately.
The way is to create api that will output required data from JSON files (or database). You can choose to hide the data that you don't want to show.
This way, you only expose the api, instead of the file name directly, which has risks of being modified or altered or hacked very easily.
Other way without using API is to have multiple JSON files.
One file will have basic data, and other will have confidential data, along with a foreign key like unique key that'd map the confidential or other data with the main record.
Example:
Comments.json:
{
"comments": [{userId: 1, ...},{...}]
}
CommentDetails.json
{...}
Users:
[
1: {"username": "", "email": "asdas#asdas.com",...}
]
You can use a database like MongoDB, that stores JSON documents, to keep the data of users and comments.
Then, the users collection will not be sent completely to the user, filterint the emails and other sensitive data.
Create a second JSON file, or CSV file for that matter, which is kept private, that maps users to their emailIDs.
Interesting project you are attempting, btw. Good luck!! :)
Why not just use a .htaccess in a directory where the data is stored and use something like "Deny from All"?
Your scripts could access then, but no user's browser.
Assuming there will be a mail server involved, can you host a web service with two endpoints?
Endpoints:
sends emails; takes an sender guid instead of an email address
stores an email; takes an email address and returns a sender guid
This web service could then be used by your library from any www accessible server. At the web service host the emails could be stored in the format of your choice. You will also want to secure you web service to prevent others from triggering mail notifications.
Related
I want to use an a decryption algorithm on the data I receive through REST-API, for that I am storing the secret-key in angular component ts file.
I want to know that after I build and deploy the code. Will my secret key be visible somewhere in the browser, because the built code is pure javascript which is fetched by server.
I am using crypto-js library for decryption of data.
var secret_key = "super-secret";
CryptoJS.AES.decrypt(ciphertext, secret_key)
If you can explain the situation why you need it, may be a chance you can get better way to do it.
There are 3 different ways to achieve it :-
Pass roles/permissions to local storage as well as same time put into session table(or any other table) in backend. Check role/permission every time user request for something to make sure it is not modified.
Store the roles/permission in backend e.g in session table and then provide roles/permission on every request. This way you do not have to worry about any modification by user anytime.
Pass the encrypted (RSA algorithm)roles/permission in cookies and make cookie httpOnly true and secure true, these cookies cannot be accessed/modified as per protocol and then in each request you will have
The best practice here is to execute encrypt/decrypt operation on backend (server-side) and get the decrypted value from you API
Yes it will be visible to individuals looking for it. You should never store secrets in any client-side code.
The key should be acquired from a server once the client authenticates.
Good post on key storage options
https://pomcor.com/2017/06/02/keys-in-browser/
Section 5.2 of WebCryptoAPI discusses a bit about key storage
https://www.w3.org/TR/WebCryptoAPI/
I am trying to make a webpage and server where a user can enter in recipes and have them sent to (using JSON) the server and have the server store them in a file so that if the server is closed and reopened the user can request for something they've entered previously and can get it. I know how to send the JSON object both to the server and how to send the JSON object back to the client. I should note this can't use jquery.
What I need help with is how to store it in a file server side and get the contents from it later using a node.js server. They should all be stored in the same directory and I need to know how to get a list of the recipes in that directory. I've tried looking around but I can't seem to find the answer :(.
Example:
user makes a recipies
{ name:"cheese n waffles"
time:90,
ingredients:"cheese, eggs and waffles",
equipment:stove
};
Browser sends the JSON object to the server.
Client asks for a list of the recipes stored.
user asks for the recipe for spaghetti.
what I need help with:
server gets a list of the recipes it has stored
server takes the JSON object and stores it in /serverRootDir/recepiesStorage
server accesses /serverRootDir/recepiesStorage and gets the spaghetti recipe
You should be using a JSON based database such as MondoDB
It takes some learming however implementing with a text file will eventually become much more work and will function poorly
(Posted on behalf of the OP).
I have solved the problem. I will be using:
To read a file (access a recipe): fs.readFileSync() or fs.readFile().
To save a file (update a recipe): fs.writeFileSync() or fs.writeFile().
To get an array of files in a directory (retrieve the list of recipes): fs.readdirSync() or fs.readdir().
How do I save html registration form data into a JSON file then log in based on it, without using any server side scripting languages? I want to use only Javascript and jQuery.
HTML file "simple form" contains:
First Name, Middle Name, Last Name, User Name, Password, Confirm Password, E-Mail, Phone
When a user enters his data and clicks the register button, his data will be saved in a JSON file on the server. I have created this JSON file on the server as:
C:\inetpub\wwwroot\usersData.txt
And based on this file usersData.txt, when another user wants to register, I need to check the that user name is unique, if it is a unique user name, save his data back to the JSON file.
I also need to know how to update the password in the JSON file when I use a hypothetical change_password() JS function.
Under normal circumstances, you should not be able to modify files on the server from client side scripting. Allowing that would let a malicious user put anything into that file, or, depending on configuration, any other file the server can access.
Doing only authentication client side is also problematic. If the client can download the userData.txt, the malicious user would know every user's email, password and phone number; using the email and password he could probably login to the user's email account, and another bad stuff can happen, so please don't do it!
So, there's no way to properly do it clientside...
I think you would be better served by not bothering to collect the data -- client-side authentication can never be trusted. Don't try to build a system that pretends to be safe. Instead, make the insecurity very obvious: store the username in a cookie and let any user type any username into whatever field sets the username cookie. (The cookie is just so they don't have to re-type it all the time.)
If you don't care about security be upfront and honest about it.
If you plan to do authentication on the server side, which you really really really should, you have to have something listening on the server, either your code or delegate the authentication to some other system. There's no way to magically update a file on the server from javascript running in the browser.
I have a JSON web service to return home markers to be displayed on my Google Map.
Essentially, http://example.com calls the web service to find out the location of all map markers to display like so:
http://example.com/json/?zipcode=12345
And it returns a JSON string such as:
{"address": "321 Main St, Mountain View, CA, USA", ...}
So on my index.html page, I take that JSON string and place the map markers.
However, what I don't want to have happen is people calling out to my JSON web service directly.
I only want http://example.com/index.html to be able to call my http://example.com/json/ web service ... and not some random dude calling the /json/ directly.
Quesiton: how do I prevent direct calling/access to my http://example.com/json/ web service?
UPDATE:
To give more clarity, http://example.com/index.html call http://example.com/json/?zipcode=12345 ... and the JSON service
- returns semi-sensitive data,
- returns a JSON array,
- responds to GET requests,
- the browser making the request has JavaScript enabled
Again, what I don't want to have happen is people simply look at my index.html source code and then call the JSON service directly.
There are a few good ways to authenticate clients.
By IP address. In Apache, use the Allow / Deny directives.
By HTTP auth: basic or digest. This is nice and standardized, and uses usernames/passwords to authenticate.
By cookie. You'll have to come up with the cookie.
By a custom HTTP header that you invent.
Edit:
I didn't catch at first that your web service is being called by client-side code. It is literally NOT POSSIBLE to prevent people from calling your web service directly, if you let client-side Javascript do it. Someone could just read the source code.
Some more specific answers here, but I'd like to make the following general point:
Anything done over AJAX is being loaded by the user's browser. You could make a hacker's life hard if you wanted to, but, ultimately, there is no way of stopping me from getting data that you already freely make available to me. Any service that is publicly available is publicly available, plain and simple.
If you are using Apache you can set allow/deny on locations.
http://www.apachesecurity.net/
or here is a link to the apache docs on the Deny directive
http://httpd.apache.org/docs/2.0/mod/mod_access.html#deny
EDITS (responding to the new info).
The Deny directive also works with environment variables. You can restrict access based on browser string (not really secure, but discourages casual browsing) which would still allow XHR calls.
I would suggest the best way to accomplish this is to have a token of some kind that validates the request is a 'good' request. You can do that with a cookie, a session store of some kind, or a parameter (or some combination).
What I would suggest for something like this is to generate a unique url for the service that expires after a short period of time. You could do something like this pretty easily with Memcache. This strategy could also be used to obfuscate the service url (which would not provide any actual security, but would raise the bar for someone wanting to make direct calls).
Lastly, you could also use public key crypto to do this, but that would be very heavy. You would need to generate a new pub/priv key pair for each request and return the pubkey to the js client (here is a link to an implementation in javascript) http://www.cs.pitt.edu/~kirk/cs1501/notes/rsademo/
You can add a random number as a flag to determine whether the request are coming from the page just sent:
1) When generates index.html, add a random number to the JSON request URL:
Old: http://example.com/json/?zipcode=12345
New: http://example.com/json/?zipcode=12345&f=234234234234234234
Add this number to the Session Context as well.
2) The client browser renders the index.html and request JSON data by the new URL.
3) Your server gets the json request and checks the flag number with Session Context. If matched, response data. Otherwise, return an error message.
4) Clear Session Context by the end of response, or timeout triggered.
Accept only POST requests to the JSON-yielding URL. That won't prevent determined people from getting to it, but it will prevent casual browsing.
I know this is old but for anyone getting here later this is the easiest way to do this. You need to protect the AJAX subpage with a password that you can set on the container page before calling the include.
The easiest way to do this is to require HTTPS on the AJAX call and pass a POST variable. HTTPS + POST ensures the password is always encrypted.
So on the AJAX/sub-page do something like
if ($_POST["access"] == "makeupapassword")
{
...
}
else
{
echo "You can't access this directly";
}
When you call the AJAX make sure to include the POST variable and password in your payload. Since it is in POST it will be encrypted, and since it is random (hopefully) nobody will be able to guess it.
If you want to include or require the PHP directly on another page, just set the POST variable to the password before including it.
$_POST["access"] = "makeupapassword";
require("path/to/the/ajax/file.php");
This is a lot better than maintaining a global variable, session variable, or cookie because some of those are persistent across page loads so you have to make sure to reset the state after checking so users can't get accidental access.
Also I think it is better than page headers because it can't be sniffed since it is secured by HHTPS.
You'll probably have to have some kind of cookie-based authentication. In addition, Ignacio has a good point about using POST. This can help prevent JSON hijacking if you have untrusted scripts running on your domain. However, I don't think using POST is strictly necessary unless the outermost JSON type is an array. In your example it is an object.
I need to make something like google-analytics, I mean that it has to be very simple to install and enables a comunication between 2 websites.
Let me explain the idea.
I'm developping an application (with ZF) where my clients will be online shops, OSCommerce only at the begining. Those shops need to get some info from my app's database, send me some info and propose to their clients to use my app's service.
What does the code needs to do:
if there is a certain $_GET param in the URL (that indicates that the user is coming from my site) -> starts a session in the shop and send me some info for my stats (IP, browser info, etc...)
if this user buys something during this sesion -> send me some info about the sale (total, id, ...)
during the checkout process (checkout-payment.php in OSC) give the possibility to the user (the shop's client who is also a member of my application) to insert his email+password from his my-application's account in order to get a discount in the order he's placing.
I know how to program all this, editing the shop's files, but my problem is that I have no idea about how to make it in the google-analytics way (give a small javascript to my customers to install in their store) and neither what to look for in google in order to find the information I need.
So, can anyone helps me to get in the right path?
Thanks in advance
Since you'll be needing to go cross-domain with this utility, you'll want to write your javascript piece for inclusion using JSONP. Your JSONP "call" could simply be made to some PHP script on your server by tacking on information obtained from window.location (like the query string, for example).
Maybe all you need is to give your customer an URL pointing to your js library? And than your library can work or better provide them with API to your service to get customer data etc.?
And yes - JSONP can help you with inter-domain comunication...