From Newsgroup: comp.lang.javascript

I'd like to have some buttons on my site for "voting", eg. say there are emoticons on a post saying "angry", "happy", "sad" - users can click one. Now what I'd like to prevent is users repeatedly clicking a button to increase the no. of votes for that button (or even worse, a script doing it!). I'm a little confused as to how to architect this...? Do I set a client-side cookie when the button is clicked, say, to expire in 5 mins or whatever; or do I have to set up Apache (SOMEhow!) to prevent repeated votes coming in from the same IP or something like that? (I REALLY don't like this idea - it's highly likely that there could be 2 people who have the same IP within a small time frame - it's a small geographical location I'm targeting the site at, and I plan for the site to be VERY POPULAR!! :) )
Thanks for your help.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

On Wed, 21 Nov 2018 00:50:11 -0800 (PST), groovee@cyberdude.com wrote:

I'd like to have some buttons on my site for "voting", eg. say there are emoticons on a post saying "angry", "happy", "sad" - users can click one.
Now what I'd like to prevent is users repeatedly clicking a button to increase the no. of votes for that button (or even worse, a script doing it!). I'm a little confused as to how to architect this...? Do I set a client-side cookie when the button is clicked, say, to expire in 5 mins
or whatever; or do I have to set up Apache (SOMEhow!) to prevent repeated votes coming in from the same IP or something like that? (I REALLY don't
like this idea - it's highly likely that there could be 2 people who have
the same IP within a small time frame - it's a small geographical
location I'm targeting the site at, and I plan for the site to be VERY POPULAR!! :) )

Thanks for your help.

For voting system, the server is the one that keep the vote count, not the client. The client simply send a vote or unvote request, then the server translate that to a +1 or -1 vote, and update the vote count. How the server keep the vote count, is up to you. It can be in a database, or in a plain
text file. But database is recommended if there are multiple things which
can be voted.

For the vote/unvote UI on the web page, make the user's vote status known to scripts, and present the vote button. Make it shows "Like" if the user
hasn't voted, or "Unlike" if the user has voted. Make the button's `click` event handler immediately disables the button, then send the vote/unvote request. If the request finished completely, meaning that the server has acknowledged the request, change the user's voting state in the script, then reenable the button.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

groovee@cyberdude.com writes:

I'd like to have some buttons on my site for "voting", eg. say there
are emoticons on a post saying "angry", "happy", "sad" - users can
click one.

This is not going to be a client-side scripting issue so you'll need to
move the question elsewhere to get the best answers.

Now what I'd like to prevent is users repeatedly clicking a button to increase the no. of votes for that button (or even worse, a script
doing it!).

Fundamentally, you can't because nothing in this sort of interaction
knows what a person is. I click "happy" and pass the laptop to my
friend in the cafe and she clicks "happy". You can't tell if that was
me again or not. And there's nothing to stop me loading the page in
every machine in a lab full of PCs and clicking "happy" on them all.

The point is that you need to decide how seriously to take this and then
pick what notion of "user" identity you can live with.

Most sites that take this seriously will use logins. That does not
uniquely identify a person, of course, but it might do. The trouble is
you put off casual users. I just walk away from 95% of sites that want
me to register. I just can't be bothered in most cases, but maybe your
content and services will be so compelling you can force people to
register in order to use some parts, like the voting.

I'm a little confused as to how to architect this...? Do I
set a client-side cookie when the button is clicked, say, to expire in
5 mins or whatever; or do I have to set up Apache (SOMEhow!) to
prevent repeated votes coming in from the same IP or something like
that? (I REALLY don't like this idea - it's highly likely that there
could be 2 people who have the same IP within a small time frame -
it's a small geographical location I'm targeting the site at, and I
plan for the site to be VERY POPULAR!! :) )

Those two cancel each other out so you are probably not talking about a
lot of users. That's good, because you need to store the votes on the
server. There's really no other reliable way.
--
Ben.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 21 Nov 2018 in comp.lang.javascript:

This is not going to be a client-side scripting issue so you'll need to
move the question elsewhere to get the best answers.

While this is a good answer, it is not perfect.

c.l.j. is not a group dedicated to *clientside* Javascript only,
and it is quite possible and even convenient to use Javascript serverside.

Convenient, because you can sometimes use the same code serverside and clientside, for instance with pre and post submission checking of the
validity of a form response.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 21 Nov 2018 in comp.lang.javascript:

This is not going to be a client-side scripting issue so you'll need to
move the question elsewhere to get the best answers.

While this is a good answer, it is not perfect.

c.l.j. is not a group dedicated to *clientside* Javascript only,
and it is quite possible and even convenient to use Javascript
serverside.

Yup, good point. However the problems that need to be addressed are independent of the server-side language, and I think people on other
groups are more inclined to discuss them. Having sorted out the design
the OP could come back here for language advice.

Or do you plan to help with some server-side Javascript proposals?

<snip>
--
Ben.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 22 Nov 2018 in comp.lang.javascript:

c.l.j. is not a group dedicated to *clientside* Javascript only,
and it is quite possible and even convenient to use Javascript
serverside.

Yup, good point. However the problems that need to be addressed are independent of the server-side language, and I think people on other
groups are more inclined to discuss them. Having sorted out the design
the OP could come back here for language advice.

However, I think the difference between Javascript in casu strictior,
and the interface functionality with the appplication should be made more clear to our newbees.

Some function write examples:

document.write();
window.alert();
console.log();

WScript.Echo();

Response.write();

process.stdout.write();

==========

mix example:

<%@ Language = "Javascript" %>
<%
var a = 3 * 17;

<script>console.log('serverside value a = ',<% = a %>);</script>

Or do you plan to help with some server-side Javascript proposals?

I already did in the 15 to 20 odd years on this NG.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
<snip>

Or do you plan to help with some server-side Javascript proposals?

I already did in the 15 to 20 odd years on this NG.

I meant help this poster. Is there anything the server-side JavaScript
brings to the party that you think would likely be missed by people
replying to a post in a web authoring group?
--
Ben.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 22 Nov 2018 in comp.lang.javascript:

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
<snip>

Or do you plan to help with some server-side Javascript proposals?

I already did in the 15 to 20 odd years on this NG.

I meant help this poster. Is there anything the server-side JavaScript brings to the party that you think

Well, that is not Javascript specific, we would have to know what serverside OS, scripting engine and database engine the OP has available and what he is most confortable with.

would likely be missed by people
replying to a post in a web authoring group?

Don't know, at least what is pertinent in this NG.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

On Friday, 23 November 2018 03:12:11 UTC+5:30, Evertjan. wrote:

Or do you plan to help with some server-side Javascript proposals?

I already did in the 15 to 20 odd years on this NG.

I meant help this poster. Is there anything the server-side JavaScript brings to the party that you think

Well, that is not Javascript specific, we would have to know what serverside OS, scripting engine and database engine the OP has available and what he is most confortable with.

Er - I know crap all about serverside JS - I *have installed* node.js on my local machine, but I have pretty much no idea about it yet, and I once tried to look up if it's possible to access MySQL databases from inside it, I don't think I managed to figure out how, or whether it's even possible... :)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

groovee@cyberdude.com wrote on 24 Nov 2018 in comp.lang.javascript:

On Friday, 23 November 2018 03:12:11 UTC+5:30, Evertjan. wrote:

Or do you plan to help with some server-side Javascript proposals?

I already did in the 15 to 20 odd years on this NG.

I meant help this poster. Is there anything the server-side
JavaScript brings to the party that you think

Well, that is not Javascript specific, we would have to know what
servers ide
OS, scripting engine and database engine the OP has available and what
he is most confortable with.

Er - I know crap all about serverside JS - I *have installed* node.js on
my local machine, but I have pretty much no idea about it yet, and I
once tried to look up if it's possible to access MySQL databases from
inside it, I don't think I managed to figure out how, or whether it's
even possible... :)

Things are not limited to what you know.

Javascript [or more exactly ECMA-script] can be implemented on different platforms and the interface code with those platforms are not part of Javascript in sensu strictior.

My entry into this thread was not metn to help you in your supposed quest,
but to correct the misconception raised by others, that Javascript by
default would mean 'Javascript as available in a browser'.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
--- Synchronet 3.20a-Linux NewsLink 1.114