info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
JavaScript code security
76 views
Skip to first unread message
justaguy
May 23, 2017, 4:02:08 PM5/23/17
to
For a web app that is hosted on an AMAZON AWS server, I use JavaScript to prevent duplicate data entry for a key field (a question of "EXACT" match was asked here before), considering the fact that the FORM would involve a large amount of data input I didn't implement server side duplicate data validation but I have code to detect if the user browser's JavaScript is disabled, if so, I would alert the user and not display the data entry form. However, just now I noticed that there are two duplicate records. What could possibly caused this issue? One possibility is that the AWS server has been compromised, thus, such duplicate data could be generated via SQL statement. Another thing, about a week ago, one of the key files were removed from this same server.
What's your thought?
Thanks.
What's your thought?
Thanks.
justaguy
May 23, 2017, 4:12:04 PM5/23/17
to
Thomas 'PointedEars' Lahn
May 23, 2017, 7:12:09 PM5/23/17
to
Stefan Ram wrote:
> justaguy <lichun...@gmail.com> writes:
>>I use JavaScript to prevent duplicate data entry for a key field
>
> The rules of parallel programming apply here, because
> several clients can run in parallel. You might have a kind
> of race condition. That's what servers and database are
> made for, i.e., e.g.,
>
> CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
>
> .
GIGO.
--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
> justaguy <lichun...@gmail.com> writes:
>>I use JavaScript to prevent duplicate data entry for a key field
>
> several clients can run in parallel. You might have a kind
> of race condition. That's what servers and database are
> made for, i.e., e.g.,
>
> CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
>
> .
GIGO.
--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
justaguy
May 23, 2017, 8:15:06 PM5/23/17
to
> Stefan Ram wrote:
>
> > justaguy writes:
> >>I use JavaScript to prevent duplicate data entry for a key field
> >
> > The rules of parallel programming apply here, because
> > several clients can run in parallel. You might have a kind
> > of race condition. That's what servers and database are
> > made for, i.e., e.g.,
> >
> > CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
> >
This approach would generate a db insertion error. I'd prefer to implement server side duplicate data validation to this method. But as mentioned earlier I'd prefer not to implement server side validation.
> > justaguy writes:
> >>I use JavaScript to prevent duplicate data entry for a key field
> >
> > The rules of parallel programming apply here, because
> > several clients can run in parallel. You might have a kind
> > of race condition. That's what servers and database are
> > made for, i.e., e.g.,
> >
> > CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
> >
justaguy
May 23, 2017, 8:56:43 PM5/23/17
to
Ben Bacarisse
May 23, 2017, 9:44:53 PM5/23/17
to
programming, it's not the kind of thing that most web users could do.
The bottom line is that client-side scripting can't do any serious
validation. Use it to improve the user experience, not to protect your
data integrity.
--
Ben.
justaguy
May 23, 2017, 10:06:05 PM5/23/17
to
On Tuesday, May 23, 2017 at 9:44:53 PM UTC-4, Ben Bacarisse wrote:
"Certainly", could you show me an example?
Stefan Weiss
May 23, 2017, 10:14:07 PM5/23/17
to
justaguy wrote:
only the JavaScript part is optional. If you are at all concerned with
security (and the title of your question suggests that you are), input
validation on the server side is a must. This is not negotiable. The unique
constraint in the database is an added safety net (which you should also
use). It will typically not activate during normal operation, but when it
does, it can save your data integrity.
Relying on client side validation alone is the software equivalent of this:
https://i.imgur.com/bYiIN56.jpg
Given your description, it's impossible to say what caused your duplicate
entries. If I had to guess, I would put my money on
1) you hit "reload" after a form submit
2) you made a mistake in your client side checks
........
........
42017) somebody hacked your server and decided to mess with you by
inserting a duplicate record
........
43501) aliens
Problem (1) can be solved by using the POST-Redirect-GET pattern or using
one-time tokens.
Problem (2) can be solved by fixing your code.
Problem (43501) can be solved by sending Jeff Goldblum to the mother ship
and infecting it with a virus.
- stefan
>> Stefan Ram wrote:
>>> CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
>
> This approach would generate a db insertion error. I'd prefer to
> implement server side duplicate data validation to this method. But as
> mentioned earlier I'd prefer not to implement server side validation.
Of the three methods to prevent duplicate records mentioned in this thread,
>>> CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
>
> This approach would generate a db insertion error. I'd prefer to
> implement server side duplicate data validation to this method. But as
> mentioned earlier I'd prefer not to implement server side validation.
only the JavaScript part is optional. If you are at all concerned with
security (and the title of your question suggests that you are), input
validation on the server side is a must. This is not negotiable. The unique
constraint in the database is an added safety net (which you should also
use). It will typically not activate during normal operation, but when it
does, it can save your data integrity.
Relying on client side validation alone is the software equivalent of this:
https://i.imgur.com/bYiIN56.jpg
Given your description, it's impossible to say what caused your duplicate
entries. If I had to guess, I would put my money on
1) you hit "reload" after a form submit
2) you made a mistake in your client side checks
........
........
42017) somebody hacked your server and decided to mess with you by
inserting a duplicate record
........
43501) aliens
Problem (1) can be solved by using the POST-Redirect-GET pattern or using
one-time tokens.
Problem (2) can be solved by fixing your code.
Problem (43501) can be solved by sending Jeff Goldblum to the mother ship
and infecting it with a virus.
- stefan
justaguy
May 23, 2017, 10:47:19 PM5/23/17
to
On Tuesday, May 23, 2017 at 10:14:07 PM UTC-4, Stefan Weiss wrote:
> justaguy wrote:
> >> Stefan Ram wrote:
> >>> CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
> >
> > This approach would generate a db insertion error. I'd prefer to
> > implement server side duplicate data validation to this method. But as
> > mentioned earlier I'd prefer not to implement server side validation.
>
> Of the three methods to prevent duplicate records mentioned in this thread,
> only the JavaScript part is optional. If you are at all concerned with
> security (and the title of your question suggests that you are), input
> validation on the server side is a must. This is not negotiable. The unique
> constraint in the database is an added safety net (which you should also
> use). It will typically not activate during normal operation, but when it
> does, it can save your data integrity.
>
> Relying on client side validation alone is the software equivalent of this:
> https://i.imgur.com/bYiIN56.jpg
>
>
> Given your description, it's impossible to say what caused your duplicate
> entries. If I had to guess, I would put my money on
>
> 1) you hit "reload" after a form submit
We can eliminate this one because after form submission it's automatically redirected to another page (eliminating the opportunity of "reload", hence, room for creating duplicate records).
> justaguy wrote:
> >> Stefan Ram wrote:
> >>> CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
> >
> > This approach would generate a db insertion error. I'd prefer to
> > implement server side duplicate data validation to this method. But as
> > mentioned earlier I'd prefer not to implement server side validation.
>
> Of the three methods to prevent duplicate records mentioned in this thread,
> only the JavaScript part is optional. If you are at all concerned with
> security (and the title of your question suggests that you are), input
> validation on the server side is a must. This is not negotiable. The unique
> constraint in the database is an added safety net (which you should also
> use). It will typically not activate during normal operation, but when it
> does, it can save your data integrity.
>
> Relying on client side validation alone is the software equivalent of this:
> https://i.imgur.com/bYiIN56.jpg
>
>
> Given your description, it's impossible to say what caused your duplicate
> entries. If I had to guess, I would put my money on
>
> 1) you hit "reload" after a form submit
> 2) you made a mistake in your client side checks
> ........
> ........
> 42017) somebody hacked your server and decided to mess with you by
> inserting a duplicate record
> ........
> 43501) aliens
>
Evertjan.
May 24, 2017, 3:11:53 AM5/24/17
to
justaguy <lichun...@gmail.com> wrote on 24 May 2017 in
comp.lang.javascript:
>> The bottom line is that client-side scripting can't do any serious
>> validation. Use it to improve the user experience, not to protect your
>> data integrity.
>>
> "Certainly", could you show me an example?
Wrong Q.
"An" example of code that "can't do" something is nonsense.
The burden of proof is on your side in providing "an" example
of code that can.
=====
Only serverside is outside the complexity of what browser is used,
or even what non-browser programme.
Only serverside can know what other users, or the same user in different
windows, just did.
Only serverside is protected from clentside code mongering.
I can imagine some clever ways clientside code can provide a low level of
such security, but only with the help of serverside code, like one-time
values of hidden <input>s.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
comp.lang.javascript:
>> The bottom line is that client-side scripting can't do any serious
>> validation. Use it to improve the user experience, not to protect your
>> data integrity.
>>
> "Certainly", could you show me an example?
"An" example of code that "can't do" something is nonsense.
The burden of proof is on your side in providing "an" example
of code that can.
=====
Only serverside is outside the complexity of what browser is used,
or even what non-browser programme.
Only serverside can know what other users, or the same user in different
windows, just did.
Only serverside is protected from clentside code mongering.
I can imagine some clever ways clientside code can provide a low level of
such security, but only with the help of serverside code, like one-time
values of hidden <input>s.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
justaguy
May 24, 2017, 8:56:43 AM5/24/17
to
On Wednesday, May 24, 2017 at 3:11:53 AM UTC-4, Evertjan. wrote:
> justaguy wrote on 24 May 2017 in
> justaguy wrote on 24 May 2017 in
> comp.lang.javascript:
>
> >> The bottom line is that client-side scripting can't do any serious
> >> validation. Use it to improve the user experience, not to protect your
> >> data integrity.
> >>
> > "Certainly", could you show me an example?
>
> Wrong Q.
>
> "An" example of code that "can't do" something is nonsense.
>
> The burden of proof is on your side in providing "an" example
> of code that can.
>
> =====
>
> Only serverside is outside the complexity of what browser is used,
> or even what non-browser programme.
>
> Only serverside can know what other users, or the same user in different
> windows, just did.
>
> Only serverside is protected from clentside code mongering.
>
> I can imagine some clever ways clientside code can provide a low level of
> such security, but only with the help of serverside code, like one-time
> values of hidden <input>s.
>
All right. I'm going with the best practice of server side data validation now. Thanks.
>
> >> The bottom line is that client-side scripting can't do any serious
> >> validation. Use it to improve the user experience, not to protect your
> >> data integrity.
> >>
> > "Certainly", could you show me an example?
>
> Wrong Q.
>
> "An" example of code that "can't do" something is nonsense.
>
> The burden of proof is on your side in providing "an" example
> of code that can.
>
> =====
>
> Only serverside is outside the complexity of what browser is used,
> or even what non-browser programme.
>
> Only serverside can know what other users, or the same user in different
> windows, just did.
>
> Only serverside is protected from clentside code mongering.
>
> I can imagine some clever ways clientside code can provide a low level of
> such security, but only with the help of serverside code, like one-time
> values of hidden <input>s.
>
justaguy
May 24, 2017, 9:01:11 AM5/24/17
to
On Tuesday, May 23, 2017 at 9:44:53 PM UTC-4, Ben Bacarisse wrote:
John G Harris
May 24, 2017, 9:19:53 AM5/24/17
to
On Wed, 24 May 2017 06:01:06 -0700 (PDT), justaguy
<lichun...@gmail.com> wrote:
<snip>
that sends all sorts of naughty submit data to your server ?
John
<lichun...@gmail.com> wrote:
<snip>
>On a second thought, I realized it's easy to avoid client side data duplication validation by opening up two tabs for the same form, copy/paste identical data to the two screens and then hit submit for both, without server side data validation, now we would have two identical records. Though 99% of users would not do that but the 1% asshole could cause problem.
And a third thought : What's to stop a hacker writing his own web page
that sends all sorts of naughty submit data to your server ?
John
Ben Bacarisse
May 24, 2017, 9:28:52 AM5/24/17
to
"Evertjan." <exxjxw.h...@inter.nl.net> writes:
> justaguy <lichun...@gmail.com> wrote on 24 May 2017 in
> comp.lang.javascript:
>
>>> The bottom line is that client-side scripting can't do any serious
>>> validation. Use it to improve the user experience, not to protect your
>>> data integrity.
>>>
>> "Certainly", could you show me an example?
>
> Wrong Q.
>
> "An" example of code that "can't do" something is nonsense.
You cut too much context. justaguy quoted "certainly" because I'd
> justaguy <lichun...@gmail.com> wrote on 24 May 2017 in
> comp.lang.javascript:
>
>>> The bottom line is that client-side scripting can't do any serious
>>> validation. Use it to improve the user experience, not to protect your
>>> data integrity.
>>>
>> "Certainly", could you show me an example?
>
> Wrong Q.
>
> "An" example of code that "can't do" something is nonsense.
stated that something can certainly be done (circumvent client-side data
validation) and he was asking for an example of that. The thread seems
to have moved now so no need for one, I think.
<snip>
--
Ben.
Evertjan.
May 24, 2017, 12:07:37 PM5/24/17
to
Ben Bacarisse <ben.u...@bsb.me.uk> wrote on 24 May 2017 in
comp.lang.javascript:
>>> "Certainly", could you show me an example?
>>
>> Wrong Q.
>>
>> "An" example of code that "can't do" something is nonsense.
>
> You cut too much context. justaguy quoted "certainly" because I'd
> stated that something can certainly be done (circumvent client-side data
> validation) and he was asking for an example of that. The thread seems
> to have moved now so no need for one, I think.
Okay, Ben.
comp.lang.javascript:
>>> "Certainly", could you show me an example?
>>
>> Wrong Q.
>>
>> "An" example of code that "can't do" something is nonsense.
>
> You cut too much context. justaguy quoted "certainly" because I'd
> stated that something can certainly be done (circumvent client-side data
> validation) and he was asking for an example of that. The thread seems
> to have moved now so no need for one, I think.
justaguy
May 24, 2017, 1:01:14 PM5/24/17
to
On Wednesday, May 24, 2017 at 9:19:53 AM UTC-4, John G Harris wrote:
> On Wed, 24 May 2017 06:01:06 -0700 (PDT), justaguy
> On Wed, 24 May 2017 06:01:06 -0700 (PDT), justaguy
> wrote:
>
> <snip>
> >On a second thought, I realized it's easy to avoid client side data duplication validation by opening up two tabs for the same form, copy/paste identical data to the two screens and then hit submit for both, without server side data validation, now we would have two identical records. Though 99% of users would not do that but the 1% asshole could cause problem.
>
> And a third thought : What's to stop a hacker writing his own web page
> that sends all sorts of naughty submit data to your server ?
>
> John
Good thought. So, a hacker sees the FORM's action line and sends naughty submit data to it, there we go, we got a serious problem. I vaguely recall a technique to prevent such hacking? That's the name of it? Thanks.
>
> <snip>
> >On a second thought, I realized it's easy to avoid client side data duplication validation by opening up two tabs for the same form, copy/paste identical data to the two screens and then hit submit for both, without server side data validation, now we would have two identical records. Though 99% of users would not do that but the 1% asshole could cause problem.
>
> And a third thought : What's to stop a hacker writing his own web page
> that sends all sorts of naughty submit data to your server ?
>
> John
Evertjan.
May 24, 2017, 1:18:53 PM5/24/17
to
justaguy <lichun...@gmail.com> wrote on 24 May 2017 in
comp.lang.javascript:
> I vaguely recall a technique to prevent such hacking?
> That's
"What's" ?
> the name of it? Thanks.
Using your intelligence.
comp.lang.javascript:
> I vaguely recall a technique to prevent such hacking?
> That's
> the name of it? Thanks.
justaguy
May 24, 2017, 2:40:03 PM5/24/17
to
On Wednesday, May 24, 2017 at 1:18:53 PM UTC-4, Evertjan. wrote:
> justaguy wrote on 24 May 2017 in
> justaguy wrote on 24 May 2017 in
> comp.lang.javascript:
>
> > I vaguely recall a technique to prevent such hacking?
>
> > That's
>
> "What's" ?
>
> > the name of it? Thanks.
>
> Using your intelligence.
>
To prevent cross domain (server) form posting, one method seems to find the header info of the http request to determine where the request comes from and if it's not from the same domain/server then reject the FORM posting.
>
> > I vaguely recall a technique to prevent such hacking?
>
> > That's
>
> "What's" ?
>
> > the name of it? Thanks.
>
> Using your intelligence.
>
Evertjan.
May 24, 2017, 5:08:13 PM5/24/17
to
justaguy <lichun...@gmail.com> wrote on 24 May 2017 in
and the header can be manipulated.
comp.lang.javascript:
> On Wednesday, May 24, 2017 at 1:18:53 PM UTC-4, Evertjan. wrote:
>> justaguy wrote on 24 May 2017 in
>> comp.lang.javascript:
>>
>> > I vaguely recall a technique to prevent such hacking?
>>
>> > That's
>>
>> "What's" ?
>>
>> > the name of it? Thanks.
>>
>> Using your intelligence.
>>
>
> To prevent cross domain (server) form posting, one method seems to find
> the header info of the http request to determine where the request comes
> from and if it's not from the same domain/server then reject the FORM
> posting.
The posting is not froom another server, but from the client,
> On Wednesday, May 24, 2017 at 1:18:53 PM UTC-4, Evertjan. wrote:
>> justaguy wrote on 24 May 2017 in
>> comp.lang.javascript:
>>
>> > I vaguely recall a technique to prevent such hacking?
>>
>> > That's
>>
>> "What's" ?
>>
>> > the name of it? Thanks.
>>
>> Using your intelligence.
>>
>
> To prevent cross domain (server) form posting, one method seems to find
> the header info of the http request to determine where the request comes
> from and if it's not from the same domain/server then reject the FORM
> posting.
and the header can be manipulated.
justaguy
May 24, 2017, 5:26:55 PM5/24/17
to
On Wednesday, May 24, 2017 at 5:08:13 PM UTC-4, Evertjan. wrote:
> justaguy wrote on 24 May 2017 in
> comp.lang.javascript:
>
> > On Wednesday, May 24, 2017 at 1:18:53 PM UTC-4, Evertjan. wrote:
> >> justaguy wrote on 24 May 2017 in
> >> comp.lang.javascript:
> >>
> >> > I vaguely recall a technique to prevent such hacking?
> >>
> >> > That's
> >>
> >> "What's" ?
> >>
> >> > the name of it? Thanks.
> >>
> >> Using your intelligence.
> >>
> >
> > To prevent cross domain (server) form posting, one method seems to find
> > the header info of the http request to determine where the request comes
> > from and if it's not from the same domain/server then reject the FORM
> > posting.
>
> The posting is not froom another server, but from the client,
> and the header can be manipulated.
>
I was referring to the posting from a web browser (a user agent) on another server, but if it were from the same server (say, I'm the owner of this server), then if another party is able to add file to or change any file on this server that would mean my server has been compromised. About "the header can be manipulated", then, this technique of knowing where the FORM request comes from wouldn't be effective neither. That's what you're saying, correct?
> justaguy wrote on 24 May 2017 in
> comp.lang.javascript:
>
> > On Wednesday, May 24, 2017 at 1:18:53 PM UTC-4, Evertjan. wrote:
> >> justaguy wrote on 24 May 2017 in
> >> comp.lang.javascript:
> >>
> >> > I vaguely recall a technique to prevent such hacking?
> >>
> >> > That's
> >>
> >> "What's" ?
> >>
> >> > the name of it? Thanks.
> >>
> >> Using your intelligence.
> >>
> >
> > To prevent cross domain (server) form posting, one method seems to find
> > the header info of the http request to determine where the request comes
> > from and if it's not from the same domain/server then reject the FORM
> > posting.
>
> The posting is not froom another server, but from the client,
> and the header can be manipulated.
>
Evertjan.
May 25, 2017, 10:26:19 AM5/25/17
to
justaguy <lichun...@gmail.com> wrote on 24 May 2017 in
comp.lang.javascript:
>> > To prevent cross domain (server) form posting, one method seems to
>> > find the header info of the http request to determine where the
>> > request come
> s
>> > from and if it's not from the same domain/server then reject the FORM
>> > posting.
>>
>> The posting is not froom another server, but from the client,
>> and the header can be manipulated.
>>
>
> I was referring to the posting from a web browser (a user agent) on
> another server,
A web-browser resides on a user machine, not on a server.
> but if it were from the same server (say, I'm the owner
> of this server),
Impossible, you cannot post "from" a server.
Well, you could using serverside xmlhttp,
so not from a browser, do you mean that?
> then if another party is able to add file to or change
> any file on this server that would mean my server has been compromised.
But what has this serverside "file" to do with posting in the sense of
sending a page request including GET [querystring] or POST [header] content?
> About "the header can be manipulated", then, this technique of knowing
> where the FORM request comes from wouldn't be effective neither. That's
> what you're saying, correct?
Indeed, but not as a consequence of your server file story.
comp.lang.javascript:
>> > To prevent cross domain (server) form posting, one method seems to
>> > find the header info of the http request to determine where the
>> > request come
> s
>> > from and if it's not from the same domain/server then reject the FORM
>> > posting.
>>
>> The posting is not froom another server, but from the client,
>> and the header can be manipulated.
>>
>
> I was referring to the posting from a web browser (a user agent) on
> another server,
> but if it were from the same server (say, I'm the owner
> of this server),
Well, you could using serverside xmlhttp,
so not from a browser, do you mean that?
> then if another party is able to add file to or change
> any file on this server that would mean my server has been compromised.
sending a page request including GET [querystring] or POST [header] content?
> About "the header can be manipulated", then, this technique of knowing
> where the FORM request comes from wouldn't be effective neither. That's
> what you're saying, correct?
Myers
May 29, 2017, 10:55:02 AM5/29/17
to
That is great dude but how could we use it in other ways?
Myers
May 29, 2017, 10:55:30 AM5/29/17
to
That is pretty challenging
Wally W.
May 29, 2017, 2:57:51 PM5/29/17
to
That is where scripting belongs -- not in my browser, especially for
navigation.
Does it cost more server machine cycles to:
1) Run a server-side script, or
2) Spew all the javascript (including multiple browser detection
tests, only one of which is applicable per visitor) to each client
machine?
How much internet bandwidth is wasted through the inefficient sending
of scripts to client machines?
Evertjan.
May 30, 2017, 3:41:46 AM5/30/17
to
Wally W. <ww8...@aim.com> wrote on 29 May 2017 in comp.lang.javascript:
> How much internet bandwidth is wasted through the inefficient sending
> of scripts to client machines?
I agree somuch with your implied somuch, Wally W.
> How much internet bandwidth is wasted through the inefficient sending
> of scripts to client machines?
Measuring the waist circumference for computing someone's BMI
may not be an inefficient waste.
However, your tautological waisted inefficiency
is sometimes called distributed computing.
<https://en.wikipedia.org/wiki/Distributed_computing>
<https://en.wikipedia.org/wiki/List_of_distributed_computing_projects>
Thomas 'PointedEars' Lahn
Jun 23, 2017, 4:53:24 AM6/23/17
to
Wally W. wrote:
^^^^^^^^
Your real name belongs there.
> On Wed, 24 May 2017 05:56:37 -0700 (PDT), justaguy wrote:
>>On Wednesday, May 24, 2017 at 3:11:53 AM UTC-4, Evertjan. wrote:
>>> I can imagine some clever ways clientside code can provide a low level
>>> of such security, but only with the help of serverside code, like
>>> one-time values of hidden <input>s.
>>
>>All right. I'm going with the best practice of server side data
>>validation now. Thanks.
JFTR: These approaches are not mutually exclusive. In fact, the best
server-side validation framework will also generate adequate client-side
validation code.
> […]
> Does it cost more server machine cycles to:
^^^^^^^^^^^^^^^^^^^^^
Besides, there is no “javascript”.
And although “multiple browser detection tests”, and “browser detection
tests” in general, do not have to be served by the same server, they are not
only unnecessary; they are, with few exceptions, *unwise*.
We have discussed this here /ad nauseam/. You should learn about a topic
before you comment on it.
> How much internet bandwidth is wasted through the inefficient sending
> of scripts to client machines?
Difficult to say. However, scripts do not *have* to be sent *inefficiently*
to client machines, and there is also “internet bandwidth […]” and “server
machine cycles” “wasted” by unnecessary roundtrips to servers.
^^^^^^^^
Your real name belongs there.
> On Wed, 24 May 2017 05:56:37 -0700 (PDT), justaguy wrote:
>>On Wednesday, May 24, 2017 at 3:11:53 AM UTC-4, Evertjan. wrote:
>>> I can imagine some clever ways clientside code can provide a low level
>>> of such security, but only with the help of serverside code, like
>>> one-time values of hidden <input>s.
>>
>>All right. I'm going with the best practice of server side data
>>validation now. Thanks.
server-side validation framework will also generate adequate client-side
validation code.
> […]
> That is where scripting belongs -- not in my browser, especially for
> navigation.
You are mistaken; at best, you are out of touch.
> navigation.
> Does it cost more server machine cycles to:
> 1) Run a server-side script, or
^^^^^^^^^^^^^^^^^^
> 2) Spew all the javascript (including multiple browser detection
> tests, only one of which is applicable per visitor) to each client
> machine?
1). That was easy :)
> tests, only one of which is applicable per visitor) to each client
> machine?
Besides, there is no “javascript”.
And although “multiple browser detection tests”, and “browser detection
tests” in general, do not have to be served by the same server, they are not
only unnecessary; they are, with few exceptions, *unwise*.
We have discussed this here /ad nauseam/. You should learn about a topic
before you comment on it.
> How much internet bandwidth is wasted through the inefficient sending
> of scripts to client machines?
to client machines, and there is also “internet bandwidth […]” and “server
machine cycles” “wasted” by unnecessary roundtrips to servers.
Evertjan.
Jun 23, 2017, 7:39:39 AM6/23/17
to
Thomas 'PointedEars' Lahn <Point...@web.de> wrote on 23 Jun 2017 in
comp.lang.javascript:
>>>All right. I'm going with the best practice of server side data
>>>validation now. Thanks.
>
> JFTR: These approaches are not mutually exclusive. In fact, the best
> server-side validation framework will also generate adequate client-side
> validation code.
Indeed, using the same [nonexistent] Javascript code both serverside and
clientside pretty much insures validation goes the same way both before and
after submission, when we ignore or heed the problem of different renderers.
comp.lang.javascript:
>>>All right. I'm going with the best practice of server side data
>>>validation now. Thanks.
>
> JFTR: These approaches are not mutually exclusive. In fact, the best
> server-side validation framework will also generate adequate client-side
> validation code.
clientside pretty much insures validation goes the same way both before and
after submission, when we ignore or heed the problem of different renderers.
0 new messages