spidermonkey for server-side? (new to list)
Peter Michaux
I'm new to the list. I have been learning JavaScript browser scripting
for about a year and now am getting frustrated by the difference in
programming languages between client and server. I think it would be
much better if they were the same and since the browser has to be
JavaScript then why not the server?
I have also been using Ruby on Rails for server development over the
past year and a half. It is very good but wrapping JavaScript in Ruby
generators seems wasteful. The Ruby implementation is in C and allows
for easy extension of the language through libraries written in C. Is
this possible with spidermonkey?
Has anyone written a JavaScript server-side framework like Ruby/Rails,
Python/TurboGears, Perl/Catalyst, and PHP/Cake? Even if just some
pieces exist like an ORM and MySql binding I'd like to check that out.
Is there a reason that JavaScript hasn't caught on for general
server-side scripting yet?
Should I be considering Rhino over Spidermonkey for any reason? Are
both projects equally healthy and have a need to survive?
Thank you,
Peter
Peter Wilson
Hello Peter,
I've not used any of the frameworks you've mentioned, although I've taken a look
at PHP.
All my development over the last 4 years has been using server-side JavaScript,
using the Mozilla SpiderMonkey implementation. It's it 'C', blindingly fast and
very flexible.
The system I use is called Whitebeam, and I'm also part of the team that develop
Whitebeam, so of course am a little biased. That said I've developed just about
every kind of application you can imaging from e-commerce sites to networking
sites to community sites on on-line magazines (take a look at
http://www.gadgetspeak.com - all the functionality you'll see is server-side
JavaScript)
Although I don't do it often, passing data from the server to client side
JavaScript is trivial. Build your data-structure. 'toSource()' into a script tag
and off you go.
Whitebeam includes bindings to the PostgreSQL open source database. Details at :
http://www.whitebeam.org/library/guide/TechNotes/postgres.rhtm
IMHO PostgreSQL is streaks ahead of mySQL and is released under a much more
flexible license.
Whitebeam also provides a framework layer in between the database and the SS
JavaScript tht abstracts a whole load of data storage if your SQL is a little
rusty - things like the GadgetSpeak site mentioned above are implemented using
the 'catalogue' and 'membership' abstractions built into Whitebeam without any
dedicated SQL being written. It beats having to work out how to query
hierarchical database structures in SQL.
Whitebeam itself is Open Source and distributed under the BSD license, the same
as PostgreSQL, and is written in 'C' and 'C++'. My own servers are handling
hundreds of thousands of requests each day and not breaking into a sweat.
From my point of view, irrespective of Whitebeam, JavaScript is a fantastic
server-side language and significantly more well thought out than PHP (IMHO). If
you want to go do your own thing SpidrMonkey itself is great (although I'd like
to see more frequent 'official releases'!)
If you want more information then let me know.
Pete
--
http://www.whitebeam.com
Peter Wilson
Joshua Levy
Hi Peter,
Yes, I agree, using JavaScript server side has real advantages.
>> Has anyone written a JavaScript server-side framework like Ruby/Rails,
>> Python/TurboGears, Perl/Catalyst, and PHP/Cake?
On the Java platform, another server-side Javascript framework that has
been around for some time -- and deserves to be better known -- is
Helma:
http://helma.org/
It is a full-featured framework, with its own templating, ORM, etc.
A newer, more Java EE-flavored effort is Phobos:
https://phobos.dev.java.net/
Cheers,
Joshua
--
View this message in context: http://www.nabble.com/spidermonkey-for-server-side--%28new-to-list%29-tf2571744.html#a7182705
Sent from the Mozilla - JavaScript Engine mailing list archive at Nabble.com.
Franky Braem
> Hi,
>
>
> Has anyone written a JavaScript server-side framework like Ruby/Rails,
> Python/TurboGears, Perl/Catalyst, and PHP/Cake? Even if just some
> pieces exist like an ORM and MySql binding I'd like to check that out.
>
wxJS has an Apache module, which allows you to write dynamic webpages
with JavaScript. wxJS has also a sqlite module. MySql binding is planned.
Franky.
Marcello Bastéa-Forte
technical preview release, so very much alpha at this stage)
http://marcello.cellosoft.com/projects/alt/
Marcello
James Duncan
> Has anyone written a JavaScript server-side framework like Ruby/Rails,
> Python/TurboGears, Perl/Catalyst, and PHP/Cake? Even if just some
> pieces exist like an ORM and MySql binding I'd like to check that out.
This is a completely blatent piece of self-promotion, but we have a
SpiderMonkey based product called Zimki which provides a server-side
JavaScript development environment. We are providing a service similar
to Amazon's Elastic Computing Cloud (EC2) product, only further up the
stack. Essentially you just worry about building your application in
the framework, we host, mangage, scale and backup your system, and you
pay for it on the basis of the computing resource you consume (although
in honesty we're not charging for it yet because we're still figuring
out how much an operation in the SpiderMonkey VM should cost). The
whole platform is going to be released as open source in the middle of
next year, to ease fears about lock-in and such. The URL is in my sig
below.
To depart from the advertising, Wikipedia has relatively long list of
server-side javascript products at
http://en.wikipedia.org/wiki/Server-Side_JavaScript.
> Is there a reason that JavaScript hasn't caught on for general
> server-side scripting yet?
I think we're starting to see the same progression of JavaScript to the
server side that Java took a long time ago. Keep in mind that 10 years
ago we had much less of an idea as to how dynamic languages could offer
advantages on the server side. All the technologies you mentioned have
added to our understanding of how to build large-scale web systems in a
robust manner using dynamic languages.
Regards,
James.
--
James A. Duncan
http://www.fotango.com | http://www.zimki.com | http://www.whoot.org
Bart Guijt
I started a SourceForge project called 'rhinocomponents'[1] (for the
lack of a better name ;-)) but reflects exactly what it is: Components
which wrap some typical J2EE resources available on the Java platform
in the Rhino runtime.
It also includes a little JUnit TestCase[2] which helps testing Rhino
components (which implement the Scriptable interface).
I have components for JDBC[3], HTTP[4], WSDL/SOAP(rpc-enc)[5] and also
Jakarta POI[6] (Excel spreadsheets). Next in queue is XSLT which
leverages the E4X capabilities of Rhino. In the future I'd like to
design JTA support.
Unfortunately, no convenient ZIP file for download yet. You can
checkout the CVS repo which is pretty much ready to run out-of-the-box
(it includes jars, Jetty, HSQLDB, testcases etc.).
[1] RhinoComponents - http://sf.net/projects/rhinocomponents
[2] JUnit TestCase - http://tinyurl.com/sz85l
[3] JDBC example (tests) - http://tinyurl.com/y4w5sa
[4] HTTP example (test) - http://tinyurl.com/yaq3qe
[5] WSDL example (test) - http://tinyurl.com/yb7n7v
[6] POI example (test) - http://tinyurl.com/yjqr6y
Cheers,
Bart Guijt
> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
Tei
[..]
> Is there a reason that JavaScript hasn't caught on for general
> server-side scripting yet?
a* Not supported by default for Apache
b* JS is type unsafe. Typecast everywhere only make your code hard to read.
c* Object() changes are global
d* Math can be complex, and "+" is overloaded as add and concatenate.
e* Is not Classes based but Object based.
a,e => automatically unpopular
b,c,d => hard to make big apps right
Lack of pularity of tools, like MySQL bindings are also important.
(but seems there are bindgs.. http://www.whitebe... )
Maybe I am a idiot, but to me Javascript is hard serverside, and PHP
is easy serverside <-- I admit that this make non-sense, but is true.
Maybe because PHP is dumb, and JS is powerfull in a Perl-ish way.
Even Perl is not soo popular nowdays serverside *because* is soo
flexible and powerfull in a way that make writing big apps hard.
Theres also the thing about installlation. How can you install JS
serverside? I can do "apt-get install php" but will "apt-get install
js" do it?
Peter Wilson
> On 3 Nov 2006 15:22:54 -0800, Peter Michaux <peterm...@gmail.com> wrote:
> [..]
>> Is there a reason that JavaScript hasn't caught on for general
>> server-side scripting yet?
>
> a* Not supported by default for Apache
organisation. Do you mean 'is available as an Apache module'?
> b* JS is type unsafe. Typecast everywhere only make your code hard to read.
So is PHP - so type unsafe isn't a hinderance to web-application development.
> c* Object() changes are global
That's an implementation detail and only true if the server side implementation
makes it so. Of course it shouldn't!
> d* Math can be complex, and "+" is overloaded as add and concatenate.
Not sure what you mean by this? Why is it more complex than PHP? It's generally
easier to read than PHP.
> e* Is not Classes based but Object based.
Again - to a large extent PHP is. It doesn't need to be class based. Java is at
the opposite extreme - *very* type safe, class based and to be honest not used
for web development outside of large enterprises.
>
> a,e => automatically unpopular
> b,c,d => hard to make big apps right
I've written very big server-side applications in JavaScript. Like any language
and any large application you have to have some discipline.
>
> Lack of pularity of tools, like MySQL bindings are also important.
> (but seems there are bindgs.. http://www.whitebe... )
I'll come onto Whitebeam in a moment
>
> Maybe I am a idiot, but to me Javascript is hard serverside, and PHP
> is easy serverside <-- I admit that this make non-sense, but is true.
> Maybe because PHP is dumb, and JS is powerfull in a Perl-ish way.
> Even Perl is not soo popular nowdays serverside *because* is soo
> flexible and powerfull in a way that make writing big apps hard.
As you imply that is a personal point of view. I've used PHP a little and
*really* dislike it. The code tends to degenerate into blocks of unstructured
text with PHP script intermingled with HTML markup. Of course with discipline
that doesn't have to happen!
>
> Theres also the thing about installlation. How can you install JS
> serverside? I can do "apt-get install php" but will "apt-get install
> js" do it?
Whitebeam : you mentioned this above. It does actually answer several of your
points:
a) It is an Apache module. Currently it's a source distribution that you build
yourself. In the next (imminent!) release there will be Linux RPMs available.
c) "Object changes are global". In whitebeam each page generation has it's own
global object. Do what you want to it, the changes won't effect other concurrent
page executions. That will actually be true of any of the server-side uses of
JavaScript. Without that you can't use it server side.
Changes to the 'system' classes (Object, Array, and Whitebeams own classes) are
restricted to a page execution and don't effect other pages (obviously!).
Whitebeam is also mature - it's been in production environments for over 5 years
now. I personally have written very large applications on behalf of both large
organisations and branches of UK government who have been more than satisfied.
It's also pretty well documented (http://www.whitebeam.org) and complete.
From a scalability point of view - Whitebeam is designed to transparently work
across a load-balanced array of servers.
Why is PHP so popular? My thoughts - it has nothing to do with the language! :
1) It was in the right place at the right time. The only people pushing
server-side JavaScript at the time were Netscape and they wanted to charge for
their solution. Personally the language looks like it was dragged from the ark.
2) Wide range of libraries. In many ways this has made PHP a sprawling
uncontrolled mess of interface APIs, but if you want to do something server
side, chances are there is a function you can call to do it for you.
We'd like to add some of that functionality to Whitebeam - over time it'll
happen, but it'll be in a more structured way.
3) It was free when other solutions required you to pay.
4) Hosting companies were persuaded it was safe to add to hosting environments.
There were probably a fair amount of marketing work to get that to happen.
Whitebeam has been available open-source since 2001(ish) - but being techies
without budget we didn't have the kind of skills, the time or the expertise to
counter that. Still don't!
Whitebeam doesn't have bindings with mySQL - we preferred a real database so
opted for PostgreSQL, which has a much nicer licensing model (again BSD) and
which in out experience offers excellent performance and a very rich and
complete implementation of SQL, which mySQL is still trying to match.
If you want server-side JavaScript it's already available. It's free under a BSD
style licenses to do with as you want. It's not controlled by a single organisation.
Best regards
Peter Wilson
Architect - Whitebeam (http://www.whitebeam.org)
http://www.yellowhawk.co.uk
Issac Goldstand
server-side javascript Apache module. One reason I didn't go with it is
simply because it seemed too similar to the very evils of PHP that you
mention below: all tag/template based, with mixed JS and HTML code. I
didn't want to target myself at producing primarily XML-based output,
and though Whitebeam doesn't force you to output (at least, it doesn't
look like it does), the template-based approach wasn't what I wanted. I
didn't want users to think in terms of embedded code. I was thinking of
a more Perl-like interface of pure code, with helper modules that could
be used to generate/parse HTML (or XML, or whatever).
[As an aside, the most important reason I turned away from Whitebeam is
that the XML parsing features scared me overhead-wise; I wanted a
SpiderMonkey interpreter embedded in Apache, which would extend
appropriate parts of the Apache/APR APIs, offer me extensibility (think
Perl XS modules, or PHP extensions), try to give me the best performance
I can expect and have no mandatory extras (except for libapreq which
people have been talking about stuffing into the Apache core anyway). I
also looked at and discarded Franky Baem's mod_wxjs for the same reason
(external dependency on wxWidgets) and because it's C++, and my boss
wants pure C, though I did model some of our server-side objects based
on his API]
In the end I wrote my own module (currently named mod_js) which runs .js
CGI scripts (embedded, not as external processes). I tried to take the
best bits of my experience as a user/developer in ASP.Net, Perl/mod_perl
and PHP in the API. I currently have a basic prototype (which, being
that I still don't consider myself anything beyond novice as far as the
SpiderMonkey API is concerned, can probably use a good rewrite once it
gets fleshed out more) and I think there's a very high chance I can get
it released to the community if there's sufficient interest (though it
might take some few weeks of red-tape before that happens)
Issac
Peter Wilson
back then?
I also think that some of your issues are due to us needing to simplify the
message somewhat. Whitebeam does include JavaScript in XML markup, but you don't
really have to use it beyond a trivial example:
-----
<rb:script>
rb.page.write("<html><head><title>My page</title></head><body><h1>HELLO
WORLD</h1></body></html>");
</rb:script>
-----
You can put all your JavaScript into separate files and just include it into a
file that does nothing else:
-----
<rb:script src="myjavascriptfile.js"/>
-----
I think the PHP model generates more of a mess because it doesn't require the
source page to be value HTML - it's just plain text. No structure. If you're
writing HTML web pages then it's nie to be able to open your pages in an HTML
editor. Whitebeam lets you do everything in a well formed HTML/XML formed page.
That structure is also very important in separating function from appearance
which you mention. Because Whitebeam effectively has a server-side DOM
implementation you can do some interesting things (note: you don't have to!) You
can have JavaScript code in a separate file that does some very similar things
to client side DOM code.
---------
var tableTag = rb.xml.root.select('//table[@id=resultTable]')[0];
for (var r=0;r<rset.length;r++){
// Create a new result row
var rrow = rset[r];
var newRow = new XmlTag(tableTag,'tr');
// And output the columns for this row
for (var c=0;c<rrow.length;c++) {
// And now create the columns
var newCol = new XmlTag(newRow,'td');
var datum = new XmlText(newCol,rrow[c]);
}
}
---------
That can then be used with a skeleton HTML file:
<html>
<head>
<rb:script src="codeabove.js"/>
</head>
<body>
<table id="resultTable">
</table>
</body>
</html>
You can't do that in PHP - the source code is flat, plain text. There is no
structure beyond the PHP script.
Then 'template' model you mention is probably mis-named. Generally the
'templates' encapsulate some very common structures that are generally difficult
to do in a SQL database or that you really don't want to write time and again.
Examples are a hierarchically directory structure where you can search any
depth, from any node.
Another example is the centralisation of session data in such a way that your
application can run on a single server or multiple servers without you worrying
about where the session data is held.
For inexperienced users the templates provided a very safe mechanism for getting
rich site applications quickly and safely - things like SQL injection are not an
issue.
For hosting companies, it's trivial to build a big hosting environment, with
replicated database and provide that to lots of customers with minimal admin
overhead.
There are examples of people using the raw Postgres interface to write their
application logic directly in SQL
Speed-wise Whitebeam uses the SpiderMonkey engine. The HTML framework is all
written in C and C++ so it's fast.
If anyone would like to help us clear up the Whitebeam message, or understand
more about what Whitebeam to see whether we're worth supporting then please do
get in touch.
Best regards
Peter Wilson
Architect - Whitebeam (http://www.whitebeam.org)
http://www.yellowhawk.co.uk
Issac Goldstand
Peter Wilson wrote:
> Thanks for taking a look at Whitebeam Isaac, I think we exchanged a few messages
> back then?
Very possible.
>
> I also think that some of your issues are due to us needing to simplify the
> message somewhat. Whitebeam does include JavaScript in XML markup, but you don't
> really have to use it beyond a trivial example:
>
> -----
> <rb:script>
> rb.page.write("<html><head><title>My page</title></head><body><h1>HELLO
> WORLD</h1></body></html>");
> </rb:script>
> -----
>
> You can put all your JavaScript into separate files and just include it into a
> file that does nothing else:
>
> -----
> <rb:script src="myjavascriptfile.js"/>
> -----
>
> I think the PHP model generates more of a mess because it doesn't require the
> source page to be value HTML - it's just plain text. No structure. If you're
> writing HTML web pages then it's nie to be able to open your pages in an HTML
> editor. Whitebeam lets you do everything in a well formed HTML/XML formed page.
>
Right, but that's exactly what I was trying to keep away from. We
didn't want to feel like we were "wrapped" in anything, nor did we want
to wrap anything ourselves. Like "classic" CGI programs, we wanted to
completely separate our code from any outputted markup. Frankly,
something like Netscape's old LiveWire.
That's very cool! However, since the application that we're shipping
our mod_js with does its own internal XML transformations with a
customized engine, I'm not entirely sure we wouldn't need to rewrite
that to work with our application's API anyway :-/
>
> Then 'template' model you mention is probably mis-named. Generally the
> 'templates' encapsulate some very common structures that are generally difficult
> to do in a SQL database or that you really don't want to write time and again.
> Examples are a hierarchically directory structure where you can search any
> depth, from any node.
>
> Another example is the centralisation of session data in such a way that your
> application can run on a single server or multiple servers without you worrying
> about where the session data is held.
Not sure I understood the previous two examples. Can you elaborate?
> For inexperienced users the templates provided a very safe mechanism for getting
> rich site applications quickly and safely - things like SQL injection are not an
> issue.
>
> For hosting companies, it's trivial to build a big hosting environment, with
> replicated database and provide that to lots of customers with minimal admin
> overhead.
>
> There are examples of people using the raw Postgres interface to write their
> application logic directly in SQL
>
> Speed-wise Whitebeam uses the SpiderMonkey engine. The HTML framework is all
> written in C and C++ so it's fast.
Right. I only evaluated SpiderMonkey-based projects.
>
> If anyone would like to help us clear up the Whitebeam message, or understand
> more about what Whitebeam to see whether we're worth supporting then please do
> get in touch.
I think our current plan is going to flesh out our own implementation
some more at this point, and ensure that it's initial design meets our
own internal goals (a JS interpreter with extensions for customizing our
applications).
Once we get it to a more mature stage, if we see that it attracts
interest, I think I'd personally like to step back and try to work with
other projects (Whitebeam, mod_wxjs, others) to see if we can figure out
where each of us has its strengths and weaknesses and see if and how we
can help one another out.
Issac
Peter Wilson
It would actually be trivially easy to give Whitebeam the option to run
un-encapsulated JavaScript. It could still create an empty DOM tree to allow
behaviour like that below.
You could then choose to load an HTML file - or any other kind of file and parse
that in JavaScript to generate your output.
The approach then is to have the script as the primary mechanism for generating
output. In many applications vast chunks of the script become repetitive print
statements. If you are generating HTML missing an end-tag in an appropriate
place can be difficult to track down.
Of course if you're generating lots of different formats, with very few HTML
pages, then this may be the best solution. If you're mainly generating CSV or
RTF files for example.
Most web applications however are generating predominantly HTML or XML - so an
approach like Whitebeam makes a lot of sense.
Oh well :-(
>
>> Then 'template' model you mention is probably mis-named. Generally the
>> 'templates' encapsulate some very common structures that are generally difficult
>> to do in a SQL database or that you really don't want to write time and again.
>> Examples are a hierarchically directory structure where you can search any
>> depth, from any node.
>>
>> Another example is the centralisation of session data in such a way that your
>> application can run on a single server or multiple servers without you worrying
>> about where the session data is held.
>
> Not sure I understood the previous two examples. Can you elaborate?
>
Templates are like libraries - they aren't visual templates, which I think these
days people think of by 'template'. Think of them as libraries.
For session management - Whitebeam does this all for you. You can extract
session data within a page with :
var mySessionData = rb.page.session.read();
and write back any changes with
rb.page.session.write(mySessionData);
The data is stored outside of the Apache application and is accessible from
multiple front-end web servers. Irrelevant if you only have one server, but in
my environment for example I have a number of front-end servers with a
load-balancer in front of them Regardless of which server fields a particular
page request I need it to get the correct session data.
The database templates provide abstractions for common structures - often
difficult for a SQL novice to sort out - and then you have to debug them. One of
the most general is the 'catalogue' that allows you through a function calling
interface to create an 'n' deep array of categries, attach items to any branch
(or any branches) and do searches.
All of the SQL is debugged and hidden in the template (which you can't get to -
it's all encapsulated) and you don't need to write and SQL to search/modify the
structure.
If values are passed from Apache - you don;t have to worry about SQL injection
attacks. i.e. on a web form for name on a badly written application someone
could type:
"pete' UNION SELECT * FROM accounts WHERE ''='"
A common way of dealing with this in a PHP application would be to generate a
SQL string by inserting the field value into a bigger string. If you don't
escape the data you can end up sending :
SELECT * FROM searchTable WHERE keywords LIKE '{field}';
with the example above you end up with
SELECT * FROM searchTable WHERE keywords LIKE 'pete' UNION SELECT * FROM
accounts WHERE ''='';
That would probably create an application error, but using that carefully a
hacker can get all sorts of information from your database.
>
>> For inexperienced users the templates provided a very safe mechanism for getting
>> rich site applications quickly and safely - things like SQL injection are not an
>> issue.
>>
>> For hosting companies, it's trivial to build a big hosting environment, with
>> replicated database and provide that to lots of customers with minimal admin
>> overhead.
>>
>> There are examples of people using the raw Postgres interface to write their
>> application logic directly in SQL
>>
>> Speed-wise Whitebeam uses the SpiderMonkey engine. The HTML framework is all
>> written in C and C++ so it's fast.
>
> Right. I only evaluated SpiderMonkey-based projects.
>
>> If anyone would like to help us clear up the Whitebeam message, or understand
>> more about what Whitebeam to see whether we're worth supporting then please do
>> get in touch.
>
> I think our current plan is going to flesh out our own implementation
> some more at this point, and ensure that it's initial design meets our
> own internal goals (a JS interpreter with extensions for customizing our
> applications).
>
> Once we get it to a more mature stage, if we see that it attracts
> interest, I think I'd personally like to step back and try to work with
> other projects (Whitebeam, mod_wxjs, others) to see if we can figure out
> where each of us has its strengths and weaknesses and see if and how we
> can help one another out.
That would be great. I'd love to see JavaScript adopted more widely on the
server. Particularly with the rise of AJAX, having JavaScript both ends of the
application makes a lot of sense.
Pete
Tei
> Whitebeam doesn't have bindings with mySQL - we preferred a real database so
> opted for PostgreSQL, which has a much nicer licensing model (again BSD) and
> which in out experience offers excellent performance and a very rich and
> complete implementation of SQL, which mySQL is still trying to match.
Everybody know that PostgreSQL is better. But that decision limited
your users to already users of Postgress. That most LAMP users are
not.
Anyway I think I will download that Whitebeam stuff and test. Because
seems interesting.
Issac Goldstand
Right - but if I understand correctly, you'll still need the DOM to be
built-in to all scripts, which isn't always necessarily appropriate.
Again, I don't think there's a "right way" or "wrong way" to do things,
but different approaches will be right for different people.
Understood. Maybe call them "modules", "includes" or "extensions"
instead, to make understanding more intuitive for newbies?
> The database templates provide abstractions for common structures - often
> difficult for a SQL novice to sort out - and then you have to debug them. One of
> the most general is the 'catalogue' that allows you through a function calling
> interface to create an 'n' deep array of categries, attach items to any branch
> (or any branches) and do searches.
>
> All of the SQL is debugged and hidden in the template (which you can't get to -
> it's all encapsulated) and you don't need to write and SQL to search/modify the
> structure.
>
> If values are passed from Apache - you don;t have to worry about SQL injection
> attacks. i.e. on a web form for name on a badly written application someone
> could type:
> "pete' UNION SELECT * FROM accounts WHERE ''='"
>
> A common way of dealing with this in a PHP application would be to generate a
> SQL string by inserting the field value into a bigger string. If you don't
> escape the data you can end up sending :
> SELECT * FROM searchTable WHERE keywords LIKE '{field}';
>
> with the example above you end up with
> SELECT * FROM searchTable WHERE keywords LIKE 'pete' UNION SELECT * FROM
> accounts WHERE ''='';
>
> That would probably create an application error, but using that carefully a
> hacker can get all sorts of information from your database.
Even with templates you could still be vulnerable to a such an attack.
The only way around it is to properly escape strings, or to use
placeholders in your SQL, but the latter is database-server specific
(MySQL and PostgreSQL both support them IIRC)
I'd personally love to see JavaScript implemented on top of Parrot
(http://www.parrotcode.com/) I think that would close the gap between
server- and client- side code even more. I'm not a VM person, but I
wonder how much would be involved to merge/integrate the Tamarin code
base with Parrot...
Issac
Peter Wilson
No - there would be a stub in the apache module dispatching HTTP requests -
basically a root object but the cost is neglibilble. In your JavaScript though
you send output using:
rb.page.write(string)
or
rb.page.fwrite(fmt,p1,p2...)
for 'printf' like formatting.
You can also stream output directly to the client bypassing all request
buffering using
rb.page.writeraw(string);
Agreed. Need to work on that. Don't think the term is helping us very much!
Sort of - except it is the job of the templates to do that for you. You just
pass over the raw strings and the underlying template code does all necessary
escaping or parametized SQL (depending on the template and what strategy it
uses). This makes it much easier for newbies not to have to worry about all
this. Even for us less than newbies it's one less thing to worry about on top of
everything else!
Not a VM person either. I've been using SpiderMonkey for going on 7 years now
and although it has some quirks, I'm kind of used to the worst of them. Tamarin
worries me a little that there may be problems mapping the JavaScript API. But
we'll see! One side effect for those that think server-side JavaScript should
have the option of being more strongly typed is that Tamarin could bring
JavaScript 2 functionality.
>
> Issac
Tei
[..]
> Sort of - except it is the job of the templates to do that for you. You just
> pass over the raw strings and the underlying template code does all necessary
> escaping or parametized SQL (depending on the template and what strategy it
> uses). This makes it much easier for newbies not to have to worry about all
> this. Even for us less than newbies it's one less thing to worry about on top of
> everything else!
>
I will drop here some random ideas:
wrong:
code =sprintf( "SELECT Name FROM users WHERE ID = %d", IdUser);
right:
SQL.Add( "SELECT Name FROM users WHERE ID = :IdUser ")
code =SQL.SetParameter( "IdUser", IdUser);
wrong:
name = "Oh'Hara";
code = sprintf("Enter your name: <input name='name' value='Mr %s'>", name);
right:
name = "Oh'Hara";
form.name.value = name;
code = form.toHTHML();
I bet 90% of mine bugs are errors with unescapped data :(
Anyway I think thats whats E4X is what for :DD, a universal way to
avoid escaping problems.
fch...@netbeans.jp
The approach you suggested looks interesting. From a users standpoint, is
it a big hassle? Further more, SQL.SetParameter() probably needs to
differentiate between an int value and a String value(to determine if
quotes/escaping is required).
David Fu
--
firecat server-side javascript webserver
http://firecat.nihonsoft.org
http://blog.netbeans.jp/roller/page/fchoong
> On 11/28/06, Peter Wilson <pe...@yellowhawk.co.uk> wrote:
> [..]
>> Sort of - except it is the job of the templates to do that for you. You
>> just
>> pass over the raw strings and the underlying template code does all
>> necessary
>> escaping or parametized SQL (depending on the template and what strategy
>> it
>> uses). This makes it much easier for newbies not to have to worry about
>> all
>> this. Even for us less than newbies it's one less thing to worry about
>> on top of
>> everything else!
>>
>
> I will drop here some random ideas:
>
> wrong:
> code =sprintf( "SELECT Name FROM users WHERE ID = %d", IdUser);
>
> right:
> SQL.Add( "SELECT Name FROM users WHERE ID = :IdUser ")
> code =SQL.SetParameter( "IdUser", IdUser);
>
> wrong:
> name = "Oh'Hara";
> code = sprintf("Enter your name: <input name='name' value='Mr %s'>",
> name);
>
> right:
> name = "Oh'Hara";
> form.name.value = name;
> code = form.toHTHML();
>
> I bet 90% of mine bugs are errors with unescapped data :(
>
> Anyway I think thats whats E4X is what for :DD, a universal way to
> avoid escaping problems.
Peter Wilson
It doesn't matter how you do the escaping. Both Postgres and mySQL provide an
escape function which is then generally mapped into the development environment
API. So for example you end up with :
code = "Select Name FROM users WHERE ID='"+dbase.escape(IdUser)+"'";
Parametarizing the values is just another way - as long as the SQL is also
suitably escaped.
Pete
--
Peter Wilson
On this last point - I'm not sure I see the connection between escaping and E4X?
That's only applicable to XML rather than anything universal.
Mike Shaver
>
> Peter Wilson wrote:
> > -----
> > <rb:script>
> > rb.page.write("<html><head><title>My page</title></head><body><h1>HELLO
> > WORLD</h1></body></html>");
> > </rb:script>
> > -----
> >
> > You can put all your JavaScript into separate files and just include it into a
> > file that does nothing else:
> >
> > -----
> > <rb:script src="myjavascriptfile.js"/>
> > -----
> >
> > I think the PHP model generates more of a mess because it doesn't require the
> > source page to be value HTML - it's just plain text. No structure. If you're
> > writing HTML web pages then it's nie to be able to open your pages in an HTML
> > editor. Whitebeam lets you do everything in a well formed HTML/XML formed page.
> >
>
> didn't want to feel like we were "wrapped" in anything, nor did we want
> to wrap anything ourselves. Like "classic" CGI programs, we wanted to
> completely separate our code from any outputted markup. Frankly,
> something like Netscape's old LiveWire.
Netscape's LiveWire was basically encapsulated-in-markup as well, as
far as I recall from building more apps than I should have with it,
and then working with the SSJS team at Netscape when I was part of the
Netscape SpiderMonkey team for a handful of years. You could put
additional JS files onto the jsac command line, but if you wanted to
generate output you pretty much needed to have a .html file with
<server> tags in it. I honestly think it's better to do what
whitebeam does here and express the dependencies in the file itself
rather than having to chase down "someone forgot to fix a Makefile"
problems that may well only manifest in ill-tested error paths. (Yes,
I'm reliving my own horror stories here; please bear with me!)
Classic CGI did a very bad job of separating code from generated
markup, since you had would be using something like cgilib.c or CGI.pm
and would have to effectively inline your markup generation in your
code. You could wrap some templating sugar around it, but you still
had pretty savage controller-view coupling unless you made it your
life's work.
> That's very cool! However, since the application that we're shipping
> our mod_js with does its own internal XML transformations with a
> customized engine, I'm not entirely sure we wouldn't need to rewrite
> that to work with our application's API anyway :-/
Do either of you use E4X at all on the server side? I always thought
it'd be pretty handy there, but of course it came about 5 years too
late to help me with my last server-side JS application. :)
Mike
Peter Wilson
We've just included a more recent version of SpiderMonkey into Whitebeam. I
think we're now using the version tagged 'FIREFOX_1_5_0_7_RELEASE', which
includes E4X so I don't have any live E4X application code right now. I will do
very shortly!
I think there are two places where E4X server-side can be useful. The first is
building structures for external use. Generally RSS feeds and constructing
XML/RPC or SOAP requests and decoding responses. The second is interacting with
the server-side DOM.
My current RSS code is a little like the old CGI model where I have lots of
string-cats to build the XML structure. If you miss a closing tag it can be a
real pain finding the problem. That code will definitely be replaced (very
soon!) with E4X.
Interacting with the server-side DOM is more problematic because there isn't a
defined 'C' API with which to do that. It would be nice to be able to use E4X to
have a handle to a portion of the server-side tree and then use E4X to do some
processing. You can do that but at the moment it will go through a 'toString'
from the Whitebeam DOM and then be re-parsed by E4X. E4X would have it's own
tree so changes would not affect the underlying XML objects in the page.
>
> Mike
Pete
--
Georg Maaß
> b* JS is type unsafe.
it is not unsafe, it auto casts following well known rules.
> "+" is overloaded as add and concatenate.
this is well known from all the C family languages and is possible,
because JavaScript is typed not untyped.
> e* Is not Classes based but Object based.
It is not Object based but prototype based, and may support classes too
depending from the language version. So it its more rich than all the
static langues.
> a,e => automatically unpopular
a is wrong and people with java thinking have no idea of webservice reality.
> b,c,d => hard to make big apps right
completly nonsence, because exactly this technic makes it possible to
solve big problesm with small and smart applications.
> Maybe I am a idiot
sure
>, but to me Javascript is hard serverside, and PHP
> is easy serverside
No, PHP is very confused. Its objects are strange. They are neither real
classes nor prototype based but just stupid.
It is less easy to get a server with JavaScript support already
installed than to get just as LAMP. But if you have a server with
JavaScript running there, your life is much easier than using PHP.
> Theres also the thing about installlation. How can you install JS
> serverside? I can do "apt-get install php" but will "apt-get install
> js" do it?
This is the real problem. The easiest way to circumvent that is to use
IIS with JScript or JScript.NET if you like classes.
Jeff Walden
> It doesn't matter how you do the escaping. Both Postgres and mySQL provide an
> escape function which is then generally mapped into the development environment
> API. So for example you end up with :
> code = "Select Name FROM users WHERE ID='"+dbase.escape(IdUser)+"'";
>
> Parametarizing the values is just another way - as long as the SQL is also
> suitably escaped.
The difference is that if the API only allows for .SetParameter-style interaction (even better if typed), you cannot possibly shoot yourself in the foot with it. If you have to ensure you've called an escape function when constructing the string query, however, you can. The reason this is a problem is that if you're reading a book on SQL, it's possible that it ignores escaping, and thus you might not know you're shooting yourself. If there's no raw API but only a .SetParameter API, however, lack of knowledge can't harm you. (It might take longer to learn the mapping between raw SQL and the API, but it's a one-time cost for the benefit of not being able to introduce injection attacks and the like, assuming the implementation of the API is correct.)
Just as a note, this particular line of discussion is no longer particularly JS-related -- might be worth continuing elsewhere if there's more to say.
Jeff
Peter Wilson
> Peter Wilson wrote:
>> It doesn't matter how you do the escaping. Both Postgres and mySQL
>> provide an
>> escape function which is then generally mapped into the development
>> environment
>> API. So for example you end up with :
>> code = "Select Name FROM users WHERE ID='"+dbase.escape(IdUser)+"'";
>>
>> Parametarizing the values is just another way - as long as the SQL is
>> also
>> suitably escaped.
>
>
> The difference is that if the API only allows for .SetParameter-style
> interaction (even better if typed), you cannot possibly shoot yourself
> in the foot with it. If you have to ensure you've called an escape
> function when constructing the string query, however, you can. The
> reason this is a problem is that if you're reading a book on SQL, it's
> possible that it ignores escaping, and thus you might not know you're
> shooting yourself. If there's no raw API but only a .SetParameter API,
> however, lack of knowledge can't harm you. (It might take longer to
> learn the mapping between raw SQL and the API, but it's a one-time cost
> for the benefit of not being able to introduce injection attacks and the
> like, assuming the implementation of the API is correct.)
You are right. However there are plenty of pitfalls to dropping down to a raw
SQL interface for inexperienced developers. Escaping is one of those issues. The
Whitebeam encapsulation allows to write very complex applications with no SQL at
all.
You can choose to use raw SQL if you are confident/experienced in it's use. You
can also disable SQL in the Apache configuration if you don't have that
experience, or you're an ISP that wants to allow a feature rich application
environment without exposing a low-level database API.
From an ISPs point of view you can deliver a robust, rich shared programming
environment to less experienced users. You can have a single database, with
replication and load-balanced front-end servers. You can differentiate yourself
from the fairly basic single server hosting systems generally available in the
PHP world and offer clients a large enterprise type resilient hosting
environment and, *as a plus*, they get to use a well designed, mature, open
development language in JavaScript.
If you want to encourage people that have some client-side JavaScript skills to
adopt server-side functionality what better than to give them the language they
already use?
Taking those same people and encouraging them to adopt two new languages (PHP
and SQL) is quite a barrier.
>
> Just as a note, this particular line of discussion is no longer
> particularly JS-related -- might be worth continuing elsewhere if
> there's more to say.
Possibly, but it is interesting :-) and looking at the Mozilla newsgroups, none
of them address server-side technologies, which is a pity. SpiderMonkey is
supremely well suited to such an environment.
>
> Jeff
Tei
> Tei wrote:
[...]
> > I bet 90% of mine bugs are errors with unescapped data :(
> >
> > Anyway I think thats whats E4X is what for :DD, a universal way to
> > avoid escaping problems.
>
> On this last point - I'm not sure I see the connection between escaping and E4X?
> That's only applicable to XML rather than anything universal.
>
Yes. E4X output can't be SQL, because SQL don't follow XML rules.
Is not a universal solution, yo need another one for SQL.