Is it safe?

[denis_mantsevic]

As I understand JS code drived by Mozilla Rhino => JS code has full access to all services(example: java.lang.System.exit).
I can create a new page (example: /blabla/i-am-hidden-url) and write simple JS controller: java.lang.System.exit(0); (yesss. it work)  If I make request to:  /blabla/i-am-hidden-url server will shutdown. I think - AEM should block "dangerous"(not only java.lang.System.exit) API in JS. JS should only prepare/convert data before rendering.

Thank you

[Jörg_Hoh · Accepted solution]

Hi,

yes, you can do that. And besides system.exit() there are a lot of ways to bring down your server. Memory exhaustion, endless loops, artifical deadlocks...

The question is: do you trust your developers not to implement such code? And are your tests enough to reveal such code if they get in by accident? There is not way to guarantee it besides testing and codereviews. Limiting the API will it just make harder, but it won't prevent it.

Jörg

[kautuk_sahni]

Hi Denis Mantsevich

Mozilla Rhino => JS is server side scripting language. Rhino converts JavaScript scripts into classes. Rhino works in both compiled as well as interpreted mode. It is intended to be used in server-side applications, hence there is no built-in support for the Web browser objects that are commonly associated with JavaScript.

There are no ways by which a client side scripting language can shutdown the server.

Background

Web development is all about communication. In this case, communication between two (2) parties, over the HTTP protocol:

·         The Server - This party is responsible for serving pages.

·         The Client - This party requests pages from the Server, and displays them to the user. In most cases, the client is a web browser.

·         The User - The user uses the Client in order to surf the web, fill in forms, watch videos online, etc.

Each side's programming, refers to code which runs at the specific machine, the server's or the client's.

Basic Example

1.       The User opens his web browser (the Client).

2.       The User browses to http://google.com.

3.       The Client (on the behalf of the User), sends a request to http://google.com (the Server), for their home page.

4.       The Server then acknowledges the request, and replies the client with some meta-data (calledheaders), followed by the page's source.

5.       The Client then receives the page's source, and renders it into a human viewable website.

6.       The User types Stack Overflow into the search bar, and presses Enter

7.       The Client submits that data to the Server.

8.       The Server processes that data, and replies with a page matching the search results.

9.       The Client, once again, renders that page for the User to view.

Programming

Server-side Programming

Server-side programming, is the general name for the kinds of programs which are run on the Server.

Uses

·         Process user input.

·         Display pages.

·         Structure web applications.

·         Interact with permanent storage (SQL, files).

Example Languages

·         PHP

·         ASP.Net in C#, C++, or Visual Basic.

·         Nearly any language (C++, C#, Java). These were not designed specifically for the task, but are now often used for application-level web services.

Client-side programming

Much like the server-side, Client-side programming is the name for all of the programs which are run on the Client.

Uses

·         Make interactive webpages.

·         Make stuff happen dynamically on the web page.

·         Interact with temporary storage, and local storage (Cookies, localStorage).

·         Send requests to the server, and retrieve data from it.

·         Provide a remote service for client-side applications, such as software registration, content delivery, or remote multi-player gaming.

Example languages

·         JavaScript (primarily)

·         HTML*

·         CSS*

·         Any language running on a client device that interacts with a remote service is a client-side language.

_{*HTML and CSS aren't really "programming languages" per-se. They are markup syntax by which the Client renders the page for the User.}

I hope this will help you.

Thanks and Regards

Kautuk Sahni

[denis_mantsevic]

I know how it's works :-). I mean backend JS controllers.(data-sly-use="myC.js")

Expand full API for JS developers - I think it isn't a good practice. My opinion: Professional devs will write on Java(faster and flexible), JS necessary for preparing data before rendering (for low-level devs).

[kautuk_sahni]

Hi  Denis Mantsevich

Something that I believe:-

·         I think many people like server side JavaScript, because they can stay in one language. They use JavaScript on the server as well on the client, instead of using another language (like Java, PHP or Ruby). Also, a lot of web programmers are familiar with JavaScript (because they use it on the client), so they understand it well.

·         JavaScript can also be easier as Java. If you have just a small project, Java could be a lot of overhead compared to JavaScript. Some things like callbacks could be very elegant in JavaScript.

·         Also, new frameworks like Node.js make it attractive to use this language. As long as there wasn't any server side framework, you simple couldn't use JavaScript on the server. But the language has evolved well today.

·         I think the performance of JavaScript depends also on the server. I'm not sure of this, but as far as I know, JavaScript could be (just in time) compiled, too. Google's chrome is doing something like that. Also, performance isn't such a big thing on most websites, because the performance is mostly IO to a database. The actual creation of an HTML page is very simple and no big thing. And: PHP is also interpreted and used on many sites. Ruby is significant slower then Java, but Ruby on Rails is very popular. So performance seems not so important. It's more about how "nice" and elegant the language is.

And apart from that I came across a link:- http://www.infoworld.com/article/2883328/java/java-vs-nodejs-an-epic-battle-for-developer-mindshare....

It would be good read. 🙂

Thanks and Regards

Kautuk Sahni

[denis_mantsevic]

But you are don't use NodeJS. Under the hood you are using Rhino (really slower than NodeJS).

"If you have just a small project" - I think AEM for large projects. For small projects possible to use small CMS(drupal, wordpress).

I agree - JS can be on the server side. But Its effects must be limited