Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #35841 > unrolled thread

Voting on a site

Back to article view | Back to comp.lang.javascript

Contents

  Voting on a site groovee@cyberdude.com - 2018-11-21 00:50 -0800
    Re: Voting on a site JJ <jj4public@vfemail.net> - 2018-11-21 16:16 +0700
    Re: Voting on a site Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-21 11:50 +0000
      Re: Voting on a site "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-21 22:26 +0100
        Re: Voting on a site Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-21 23:01 +0000
          Re: Voting on a site "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-22 12:23 +0100
            Re: Voting on a site Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-22 15:07 +0000
              Re: Voting on a site "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-22 22:42 +0100
                Re: Voting on a site groovee@cyberdude.com - 2018-11-24 04:37 -0800
                  Re: Voting on a site "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-24 22:39 +0100

#35841 — Voting on a site

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.

[toc] | [next] | [standalone]

#35843

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.

[toc] | [prev] | [next] | [standalone]

#35844

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.

[toc] | [prev] | [next] | [standalone]

#35846

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)

[toc] | [prev] | [next] | [standalone]

#35847

"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.

[toc] | [prev] | [next] | [standalone]

#35849

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)

[toc] | [prev] | [next] | [standalone]

#35851

"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.

[toc] | [prev] | [next] | [standalone]

#35852

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)

[toc] | [prev] | [next] | [standalone]

#35854

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... :)

[toc] | [prev] | [next] | [standalone]

#35857

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)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web