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

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

Server-Side JavaScript

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

Contents

  Server-Side JavaScript Gene Wirchenko <genew@ocis.net> - 2012-07-11 16:59 -0700
    Re: Server-Side JavaScript Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-07-11 18:41 -0700
      Re: Server-Side JavaScript Gene Wirchenko <genew@ocis.net> - 2012-07-11 22:17 -0700
        Re: Server-Side JavaScript Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-07-12 09:26 -0700
          Re: Server-Side JavaScript "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-07-12 17:31 +0000
            Re: Server-Side JavaScript Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-07-12 16:28 -0700
              Re: Server-Side JavaScript Gene Wirchenko <genew@ocis.net> - 2012-07-12 20:52 -0700
                Re: Server-Side JavaScript "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-07-13 06:53 +0000
          Re: Server-Side JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-07-13 18:33 +0200
    Re: Server-Side JavaScript Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-07-14 09:12 +1000

#15024 — Server-Side JavaScript

Dear JavaScripters:

     I have invested so much time in JavaScript that I would prefer
not to have a third language (besides JavaScript and T-SQL).  In my
recent Web-searching, I have run into a lot of statements that using
client-side JavaScript to access SQL Server is wrong, wrong, wrong --
mainly about bad security -- and not much on how to use server-side
JavaScript.

     I would really appreciate some URLs to good reading on
server-side JavaScript: how to get going, reasonable examples,
security issues, et al.

     The model that I am following right now uses ActiveX, and I would
rather have something that works for non-IE browsers.

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]

#15026

On 7/11/12 4:59 PM, Gene Wirchenko wrote:
> Dear JavaScripters:
>
>       I have invested so much time in JavaScript that I would prefer
> not to have a third language (besides JavaScript and T-SQL).  In my
> recent Web-searching, I have run into a lot of statements that using
> client-side JavaScript to access SQL Server is wrong, wrong, wrong --
> mainly about bad security -- and not much on how to use server-side
> JavaScript.
The problem isn't JavaScript itself, but having SQL engine exposed to 
users.   No Client-Side SQL. Period.  At least, not if the database is a 
shared database with content that is valuable. And if its not valuable, 
why do you have it?
>
>       I would really appreciate some URLs to good reading on
> server-side JavaScript: how to get going, reasonable examples,
> security issues, et al.
Search for Node.js, it is server-side JavaScript. Although limiting 
yourself to "no more than n languages" is an artificial limitation which 
may lead to sub-optimal implementations.
>
>       The model that I am following right now uses ActiveX, and I would
> rather have something that works for non-IE browsers.
That doesn't solve the problem of SQL on client-side. Not in the least. 
  You need to have a server-side process which only performs the SQL 
that you have explicitly decided it can run.  You do this *only* by 
using either prepared statements or properly escaping any user input. 
Never ever ever execute any SQL which was constructed directly from form 
submission.  Unless, of course, you're building a front-end interface 
for the SQL engine itself, and have otherwise handled authentication and 
authorization.


HTH,
Daniel.

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

#15027

On Wed, 11 Jul 2012 18:41:04 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

>On 7/11/12 4:59 PM, Gene Wirchenko wrote:
>> Dear JavaScripters:
>>
>>       I have invested so much time in JavaScript that I would prefer
>> not to have a third language (besides JavaScript and T-SQL).  In my
>> recent Web-searching, I have run into a lot of statements that using
>> client-side JavaScript to access SQL Server is wrong, wrong, wrong --
>> mainly about bad security -- and not much on how to use server-side
>> JavaScript.
>The problem isn't JavaScript itself, but having SQL engine exposed to 
>users.   No Client-Side SQL. Period.  At least, not if the database is a 
>shared database with content that is valuable. And if its not valuable, 
>why do you have it?

     Hey, I am just reporting the rants.  I decided they really were
not enough information, so I posted here.

     It is, well, will be valuable.

>>       I would really appreciate some URLs to good reading on
>> server-side JavaScript: how to get going, reasonable examples,
>> security issues, et al.
>Search for Node.js, it is server-side JavaScript. Although limiting 
>yourself to "no more than n languages" is an artificial limitation which 
>may lead to sub-optimal implementations.

     node.js?  Thank you.  I will be searching.

     That might well be on the languages, but I want to get something
implemented.  It has taken me way too long to learn JavaScript.  "The
perfect is the enemy of the good." or words to that effect.

>>       The model that I am following right now uses ActiveX, and I would
>> rather have something that works for non-IE browsers.
>That doesn't solve the problem of SQL on client-side. Not in the least. 
>  You need to have a server-side process which only performs the SQL 
>that you have explicitly decided it can run.  You do this *only* by 
>using either prepared statements or properly escaping any user input. 
>Never ever ever execute any SQL which was constructed directly from form 
>submission.  Unless, of course, you're building a front-end interface 
>for the SQL engine itself, and have otherwise handled authentication and 
>authorization.

     However it works, I want to remove ActiveX from the picture, and
I do want good security.  I will see what node.js does for me.

     Thank you for your reply.

Sincerely,

Gene Wirchenko

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

#15028

On 7/11/12 10:17 PM, Gene Wirchenko wrote:
> On Wed, 11 Jul 2012 18:41:04 -0700, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net> wrote:
>
>> On 7/11/12 4:59 PM, Gene Wirchenko wrote:
>>> Dear JavaScripters:
>>>
>>>        I have invested so much time in JavaScript that I would prefer
>>> not to have a third language (besides JavaScript and T-SQL).  In my
>>> recent Web-searching, I have run into a lot of statements that using
>>> client-side JavaScript to access SQL Server is wrong, wrong, wrong --
>>> mainly about bad security -- and not much on how to use server-side
>>> JavaScript.
>> The problem isn't JavaScript itself, but having SQL engine exposed to
>> users.   No Client-Side SQL. Period.  At least, not if the database is a
>> shared database with content that is valuable. And if its not valuable,
>> why do you have it?
>
>       Hey, I am just reporting the rants.  I decided they really were
> not enough information, so I posted here.
Agreed. It sounds like you understood what was wrong, but not entirely why.
>
>       It is, well, will be valuable.
We all hope so :-)
>
>>>        I would really appreciate some URLs to good reading on
>>> server-side JavaScript: how to get going, reasonable examples,
>>> security issues, et al.
>> Search for Node.js, it is server-side JavaScript. Although limiting
>> yourself to "no more than n languages" is an artificial limitation which
>> may lead to sub-optimal implementations.
>
>       node.js?  Thank you.  I will be searching.
>
>       That might well be on the languages, but I want to get something
> implemented.  It has taken me way too long to learn JavaScript.  "The
> perfect is the enemy of the good." or words to that effect.
I like to suggest you consider either a PHP or Java back-end. Those are 
both far more popular for server-side web-coding than JavaScript, 
although Node.js may be in the process of changing that.

I understand the pragmatism of finished over perfect.  How close to 
perfect something should be is often an engineering decision which 
depends on the project itself.  Imagine a ladder maker who was great 
with wood-carving, but didn't want to learn how to use glue.  His ladder 
worked well enough most of the time, until the day the rungs fell out 
from under the user.

If this is indeed only a prototype or and exercise, then you are in the 
right trying to just get something that works.  If you intend to have 
your project publicly accessible, then you need to be pragmatic in the 
other direction. Meaning if you have too severe a security hole, it 
*will* be exploited, and you will be sorry.

None of this is a rant at you BTW, just friendly advice that I've 
learned over the years, and I'm hoping you can learn it second-hand 
rather than the hard way.

>>>        The model that I am following right now uses ActiveX, and I would
>>> rather have something that works for non-IE browsers.
>> That doesn't solve the problem of SQL on client-side. Not in the least.
>>   You need to have a server-side process which only performs the SQL
>> that you have explicitly decided it can run.  You do this *only* by
>> using either prepared statements or properly escaping any user input.
>> Never ever ever execute any SQL which was constructed directly from form
>> submission.  Unless, of course, you're building a front-end interface
>> for the SQL engine itself, and have otherwise handled authentication and
>> authorization.
>
>       However it works, I want to remove ActiveX from the picture, and
> I do want good security.  I will see what node.js does for me.
I'm glad to hear it. ActiveX is not the right way for *any* solution IMO :-)

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

#15029

Daniel Pitts wrote on 12 jul 2012 in comp.lang.javascript:

> I like to suggest you consider either a PHP or Java back-end. Those are 
> both far more popular for server-side web-coding than JavaScript, 
> [..]

What does popularity have to do with it?

This NG is about Javascript.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#15031

On 7/12/12 10:31 AM, Evertjan. wrote:
> Daniel Pitts wrote on 12 jul 2012 in comp.lang.javascript:
>
>> I like to suggest you consider either a PHP or Java back-end. Those are
>> both far more popular for server-side web-coding than JavaScript,
>> [..]
>
> What does popularity have to do with it?
>
> This NG is about Javascript.
If someone posts a question about how to get JavaScript to perform a 
life-or-death procedure, what does the NG have to do with it? Part of 
discussing a particular solution is talking about considerations on why 
it might not be correct, and what alternatives exist.

PHP and Java are those alternatives. Since I've offended you by 
suggesting alternatives to the OPs question, perhaps you can provide 
reasons on why JavaScript is the better solution for server-side 
web-programming?

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

#15034

On Thu, 12 Jul 2012 16:28:07 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

>On 7/12/12 10:31 AM, Evertjan. wrote:
>> Daniel Pitts wrote on 12 jul 2012 in comp.lang.javascript:
>>
>>> I like to suggest you consider either a PHP or Java back-end. Those are
>>> both far more popular for server-side web-coding than JavaScript,
>>> [..]
>>
>> What does popularity have to do with it?
>>
>> This NG is about Javascript.
>If someone posts a question about how to get JavaScript to perform a 
>life-or-death procedure, what does the NG have to do with it? Part of 
>discussing a particular solution is talking about considerations on why 
>it might not be correct, and what alternatives exist.

     OP here.  Yes, even though I specifically said that I do not want
that, others might.  (Let us invoke what we could call the USENET
Pregnancy Rule.  "Every USENET poster is pregnant.  Remember, you are
posting for two (or more).")

>PHP and Java are those alternatives. Since I've offended you by 
>suggesting alternatives to the OPs question, perhaps you can provide 
>reasons on why JavaScript is the better solution for server-side 
>web-programming?

     I would prefer to stick with one language.  Among other things,
processing of escape sequences is easier with only one language in the
mix.

Sincerely,

Gene Wirchenko

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

#15036

Gene Wirchenko wrote on 13 jul 2012 in comp.lang.javascript:

>>PHP and Java are those alternatives. Since I've offended you by 
>>suggesting alternatives to the OPs question, perhaps you can provide 
>>reasons on why JavaScript is the better solution for server-side 
>>web-programming?
> 
>      I would prefer to stick with one language.  Among other things,
> processing of escape sequences is easier with only one language in the
> mix.

Though the engine might be the same, as is in the case of clientside 
Jscript inn IE, and serverside Jscript on an ASP-platform as used in 
Windows Server, the application is quite different, as the DOM does not 
exist serverside, and also other means of interface are quite different:

clientside [browser]:

var query = window.location.search; // and some apple splitting 
alert('blah'); // use window alert
document.write('blah'); // write to DOM-document
var myUrl = window.location.href;
 

serverside [ASP]:

var myApple = Request.form('apple');
// alert popups on a server are illogical
Response.write(myApple); // write to html-stream
var myPear = session('pear'); // session is a serverside thing
var myUrl = Request.ServerVariables('url');


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#15039

Daniel Pitts wrote:

> On 7/11/12 10:17 PM, Gene Wirchenko wrote:
>> On Wed, 11 Jul 2012 18:41:04 -0700, Daniel Pitts
>> <newsgroup.nospam@virtualinfinity.net> wrote:
>>> On 7/11/12 4:59 PM, Gene Wirchenko wrote:
>>>> Dear JavaScripters:
>>>>
>>>>        I have invested so much time in JavaScript that I would prefer
>>>> not to have a third language (besides JavaScript and T-SQL).

OMG.

>>>>        I would really appreciate some URLs to good reading on
>>>> server-side JavaScript: how to get going, reasonable examples,
>>>> security issues, et al.
>>> Search for Node.js, it is server-side JavaScript. Although limiting
>>> yourself to "no more than n languages" is an artificial limitation which
>>> may lead to sub-optimal implementations.
>>
>>       node.js?  Thank you.  I will be searching.
>>
>>       That might well be on the languages, but I want to get something
>> implemented.  It has taken me way too long to learn JavaScript.  "The
>> perfect is the enemy of the good." or words to that effect.
> I like to suggest you consider either a PHP or Java back-end. Those are
> both far more popular for server-side web-coding than JavaScript,
> although Node.js may be in the process of changing that.

Why is that relevant?  Use the best tool for the job that is available.  If 
that is Google V8 JavaScript, so be it.  It would even be on-topic here for 
a change.


PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

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

#15044

On Wed, 11 Jul 2012 16:59:49 -0700, Gene Wirchenko wrote:

>     I have invested so much time in JavaScript that I would prefer
>not to have a third language (besides JavaScript and T-SQL).  

Realise, however, that server-side JavaScript is very different, and
you'll be learning something new anyway. You might (probably would!)
find that learning something like PHP would be only as time consuming,
and lead to easier implementation and perhaps better results than
JavaScript on the server. There are other options of course, but if you
want to get going quickly and then grow into a language later, PHP will
get you there.

Now, two tools for server-side JavaScript that might be useful:

Node.js http://nodejs.org/

It's modern, developing, and very hip at the moment. So of course I
don't use it myself :)

On Linux, it is very easy to install and update from a package manager:

https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager

ASP/JScript

If you're running from a Windows server with IIS, you'll already have
access to Classic ASP which supports JScript. The doco is getting harder
to navigate as Microsoft moves away from the now ancient Classic ASP,
but it's mostly still up there. Start here for a scripting reference:

http://msdn.microsoft.com/en-us/library/ms524664(VS.90).aspx

Doco on the language:

http://msdn.microsoft.com/en-us/library/hbxc2t98(VS.84).aspx

Accessible utility objects are doco'd here:

http://msdn.microsoft.com/en-us/library/bstcxhf7(VS.84).aspx

>In my
>recent Web-searching, I have run into a lot of statements that using
>client-side JavaScript to access SQL Server is wrong, wrong, wrong --
>mainly about bad security -- and not much on how to use server-side
>JavaScript. [...]

Client-side SQL is bad. You can use client-side JavaScript to request
(by AJAX for example) data from a server-side script that executes the
SQL, but you don't want SQL directly sent over the Internet.

While we're at it, once you get your request from the Internet and want
to execute some SQL for it, remember Little Bobby Tables and learn from
him.

http://bobby-tables.com/
-- 
Ross McKay, Toronto, NSW Australia
"Let the laddie play wi the knife - he'll learn"
- The Wee Book of Calvin

[toc] | [prev] | [standalone]

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

csiph-web