I am making a poll site. And for making sure that people can't vote twice I'm saving their IP with the ID for the poll in a database. But this requires me to send the IP from the client to the server to retrieve the data out of the database. I am doing this all on the button: Vote so it checks when you click vote.
Now I am using Express and socketio and Node.js. I can't really figure out how to retrieve the IP.
The user does not have to register to vote or create a poll.
The method above might not be the best one and I think there might be a better one. So my question is:
What would be the best way to check if someone has already voted on a poll.
If you want to find the IP address, inside your express application:
app.get('/ip', function (req, res) {
var ip = req.headers['x-forwarded-for'] || req.connection.remoteAddress || req.socket.remoteAddress || req.connection.socket.remoteAddress;
//do whatever you want with it
});
And to answer your question, personally I'd require the user to type some sort of unique identification, like a university id number, tax number (thats how we're identified here in Brazil for example), anything that you can guarantee is unique to only one individual in your area of interest.
If you can't get something like that, I guess you'd have to register your users.
Related
Hello I hope you are very well, I would like to ask you a question that I have not been able to deduce the answer to.
In a course I was seeing that to send a message to a specific user with socketIO.js the to () method is used and the id as a parameter, but I have a doubt, that id is auto generated by socketIO as far as I understand, so I would like to know How can the frontend know that id? The example that I saw in the course does it from the console and sends it directly to the method with the id that it already knows, then that example is not so real, what I would like to know in itself How is it that it performs a one-to-one chat if the id is autogenerated by the socket? I don't know if I understand.
For example, to start a conversation with another user, you can click on a button, trigger an event that makes emit, send the id of the user who writes, the event that should trigger the backend with socket, but my question is how does it taste like who send the message? How do you know the id of who is being sent to when establishing communication between 2 users for the first time? Obviously this must be sent by frontent as a parameter but also how does the frontend give this id of who will it be sent to? I don't know if you can store a fixed socket id for a user in a DB or Can you use your DB id to use with sockets? more than everything is what I can not deduce how it would be done?
I do not know if I understood with the question, more than everything is that, I do not know how it obtains or assigns the id for the target from where the message is sent and if this can be fixed and stored in db or is there any method to this.
I thank you in advance for your response, and any resources that you share with me about it or if you recommend a course with, I would greatly appreciate it.
as an example I have this method
io.on('connection', (client) => {
client.on('privateMessage', (data)=>{
const person = user.getPersona(client.id) //get this
client.broadcast.to(data.para).emit('privateMessage', createMsj( person.name, data.messages));
});
}
But where does the front-end of the person to receive the message to pass it to the method?
The front-end will not know the socket.io id of any other clients. This is where your server needs to be involved.
Each of your users presumably has some username that is displayed in the client UI and this is the name that other clients would know them by.
So, your server needs to keep a mapping between username and socket.io clientID. So, a user can send a request to your server to connect to BobS. Your server then needs to be able to look up BobS, find out if that user is currently connected and, if they are, then what is their socket.id value. That way, your server can facilitate connecting the two users.
This mapping would not typically be kept in a permanent store (such as a database) because the socket.id is a transient value and is only good for the duration of that client's socket.io connection. As such, it is more typically just kept in some sort of Javascript data structure (such as a Map object).
I'm running a simple node.js server that also gots a webinterface using express.
Every time a clients goes on the website I'd like to find out who else from this clients network is connected.
I know that I can read out the localIP address of every client using some syntax like this.
var ip = req.headers['x-forwarded-for'] ||
req.connection.remoteAddress ||
req.socket.remoteAddress ||
(req.connection.socket ? req.connection.socket.remoteAddress : null);
... but how can I determine which clients are in the same network? (LAN)
I'm aware that the IP-address is nearly unnecessary/needless because of the currently unkwown Network ID - but how can I determine the networkID on the nodeJS server?
Edit: Is this also possible using socket-io with node.js?
Any help would be really appreciated. Thanks.
If you just want to check if two players are in the same LAN, looking at their remoteAddress using your code should be enough. You might want to assign unique IDs to each player, so if you have 2 players with different IDs but same IP address, it means that they are in the same LAN.
On the other hand, if you really want to obtain their local IP address for other purposes, you might want to look at this answer on how to process os.networkInterfaces()
My app consists of several PHP endpoints which are accessible via AJAX. The problem is they are also accessible via anyone who makes an HTTP request to the same endpoint. I can add checks for HTTP_X_REQUESTED_WITH and HTTP_REFERER as specified in this answer, but these can be spoofed. I could add a secret key that needs to be posted with the request, but anyone viewing the javascript and/or the console would be able to see this key. What is the solution here?
People often think that because they're using Ajax requests regular sessions don't work. They do.
If you have an endpoint to delete something from the database that's visible in the source code, such as:
example.com/user/1/delete
You can protect this request from non authenticated users the same way you would when using a non Ajax HTTP request in the browser. Using sessions. If the user has the privileges to remove users, this route will work, otherwise return an error (or do nothing).
You can also protect an API using OAuth. There's a great document here that explains how it works: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/
Most of the answers are not helpful if you have your app and your api on separate domains for example app.example.com and api.example.com - in that case sessions won't work and you would have to turn to OAuth which is quite a big hammer for such a simple problem.
Here is what I would do:
I assume you have users in a database and a unique identifier like user_id=12345. I also assume that you have your Jobs in a Database and they also have unique ID's like job_id=6789.
First on app.example.com you encrypt both IDs with something fast and easy like Blowfish:
$secret_uid = mcrypt_encrypt(MCRYPT_BLOWFISH, "your_secret", strval($user_id));
$secret_jid = mcrypt_encrypt(MCRYPT_BLOWFISH, "your_secret", strval($job_id));
I assume your endpoint would work somewhat like this:
api.example.com/jobs/delete/<job_id>/<user_id>
so now from Ajax you call that endpoint, but instead of calling with plain IDs
api.example.com/jobs/delete/6789/12345
you call it with the encrypted IDs:
api.example.com/jobs/delete/6A73D5B557C622B3/57F064C07F83644F
On the API side of your software you decrypt the parameters:
$jid = mcrypt_decrypt(MCRYPT_BLOWFISH, "your_secret", <param_1>);
$uid = mcrypt_decrypt(MCRYPT_BLOWFISH, "your_secret", <param_2>);
Now you can search your db for uid and jid and perform whichever task you were planning to do. Make sure that a user can only delete his own jobs of course.
I admit this is not a 100% solution, but it leaves an attacker with a lot of guess work - he would have to guess the user_id and a matching job_id, the encryption algo and your secret. It does not protect against running millions of brute force attempts to guess a matching pair, but it put's the odds in your favor (and you should have some sort of quota limitation protection of your endpoints anyway).
Good luck!
There isn't one. If you give someone some data, then they can process it in whatever way they like. You can't control what happens to it after it leaves your server.
Likewise, you can't control what data they send to the endpoint.
it is very important for a developer to put authentication for API or web services. dchacke and BugHunterUK has given perfect answers, I just want show you simple code I use to make very simple and easy to use authentication.
Adding Session for the authentication
you can add session, and session timeout for your APIs so, only your app can use this, you can start session when front page of your app is loaded, you can set timeouts and also restrict the different service for different users by sessions.
General Idea how to do that
<?php
if(!empty($_SESSION['api_session']) && $_SESSION['api_session'] == 'usertype'){
//usertype comprise of what access you want to give
//guest, registered user, stack holder, admin etc.
...
header('Content-Type:application/json;');
echo json_encode($output);
}
Currently now i am using io.emit where i send the event to all the connected users and in client side i check whether the id of user i emit is equal to the id of client side then the condition runs i thinks its making my code messy and bit slow is there anything i can do like connecting then in one group so when retrieving them i would be easier for me.
//server side
var id = 1;
io.emit('check',id);
// on client side
socket.on('check',function(data){
var current_user_login = //getting current user login id by php
if(data == current_user_login) {
//run some code
}
});
If you want to put certain sockets in the same room, so that it's easy
to broadcast to all of them together. Try this:
var io = require('socket.io').listen(80);
io.sockets.on('connection', function (socket) {
socket.join('group');
socket.broadcast.to('group').emit('new member');
});
Hope this helps.
The better way to solve this problem is to create an association between the user you want to send the data to and that user's socket so you can .emit() only to that particular socket. This is much, much more efficient than sending to everyone especially when you have lots of connected sockets.
You would have to explain to us much more about how you know which socket or user you want to send to in order for us to help figure out how to do that association in your server.
socket.io has the concept of "rooms" which are groups of sockets that makes it easy for you to place a socket in a specific group and to then broadcast to a specific group of sockets.
Or, each socket has an id and each socket has access to the cookies that were present when the connection was first made, both of which can sometimes be used to identify which user you want to send to. But, you'd have to explain how you know which user you want to send to for us to help give you an idea how to code that into your server.
I'm implementing a like feature for a site I'm working on. A user doesn't have to be logged in and they can either like or dislike a particular page. At the end of it all I'd like to be able to populate a list of articles or stories with the most likes.
I have a very simple method that currently uses an onclick javascript function to update a database via ajax and a php function.
This is working ok. What I'd like to do is prevent a user from spamming the button.
At first I thought of maybe getting the IP address, storing that in the database and then running a check. Is there a better way?
Technically there isn't a bomb proof way to do so. You could get pretty close by allowing one vote per ip-useragent combination. You'd have to implement this on the server side.
PHP Example
$concienceKey = md5($_SERVER['REMOTE_ADDR'] . $_SERVER['USER_AGENT']);
$query = "SELECT COUNT(*) FROM clickConcience WHERE key = `" . $concienceKey . "`";
//run your query
//.....and get the $count;
//
//already voted!
if($count > 0){
echo 'already voted';
return false;
}
//remember entry
$insert = "INSERT INTO clickConcience (key, datetime) VALUES (`" . $concienceKey . "`, NOW())";
//run your query
//.....and insert
//
return true;
straight forward answer, you won't be able to do it.
If I really want to SPAM your "like" button, I will find a way to do so, especially if you're not forcing me to be signed in (I used to write pretty good bots and were pretty efficient spamming big link submission sites).
Javascript will only stop mediocre spammers or sock puppet account holders. As a spammer I can circumvent your Javascript pretty easily, either by programming a time-based robot to like your post, or by sending requests directly to your server (I will not even load your site).
What you need to do, if you really want to prevent spammers from spamming this feature efficiently (efficiency is the keyword here because spammers can still spam your feature, but their likes won't count) is to log every IP that likes a post along with its geographical information (it's not always 100% accurate, but it's a good start) and then run a process in the background that checks for suspicious origins and penalize such likes (either by assigning them less value, or just subtracting them from the total count).
For example if your main audience is people living in the United States, but one post gets a bunch of likes from Mexico, Salvador, India, Australia, Russia, then it's more than likely that there's a spammer behind a proxy or a network similar to TOR and he/she can change his/her IP address at his/her will.
After a few hundred thousand records, you'll have a good base to start blacklisting IP addresses. I usually use R programming language to get statistical information about my databases.
But then again, a good spammer could use a list of IP addresses of compromised computers coming from your audience's country or geographical location, and use those IPs to abuse the feature. Those bots are harder to spot, but you can analyze previous posts and come up with useful metrics as "Likes/comment ratio".
If one post has a huge number of likes, but low number of comments, then it's very probable that someone spammed it, but then again I can program my bot to like AND post a comment so the numbers look natural.
I'm not sure what kind of project you're working on, but if it's something similar to link submission, do not rank (whatever your users are liking) by the number of likes.
The number of likes should only be a factor, you can take a look at how HackerNews or Reddit rank the posts (those projects are open source), but it's a combination between multiple factors.
Just hide the button after it has been clicked for the first time.
It does even makes more sense, when using an AJAX handler for sending the click...
Use cookies. Lets say you have a button where the user can like article 123456789
<button id="like" articleID="123456789">Like</button>
script :
function setLike(articleID) {
document.cookie=articleID+'=y';
}
function hasLiked(articleID) {
var cookies=document.cookie.split(';');
for (var i=0;i<cookies.length;i++) {
var cookie=cookies[i].split('=');
if (cookie[0]==articleID) return true;
}
return false;
}
var button=document.getElementById('like');
button.onclick=function() {
var articleID=this.getAttribute('articleID');
if (!hasLiked(articleID)) {
//register the like in your system
//...
//
setLike(articleID);
} else {
alert('You cant like or dislike an article twice');
}
}
Of course the user can delete all his or hers cookies - but a user can also like the same page / article from 100 different computers. The above prevents the most common scenario : People repetetively clicking like or dislike a lot of times from the same computer in a short distant of time.