Thinking about RIA
The idea has long been matured and overgrown with experiments, and so I decided to share my thoughts with Habr in order to get a kick in the right direction or get a boost of energy for the further realization of my ideas.
I like JavaScript as a very concise and beautiful scripting language. I used it often, and I still use it to automate some of my tasks. The disadvantage is manifested only in the fact that often there are not enough objects and methods to accomplish the goals. But in this case I was rescued by samopisnye COM objects. For full applications, a user interface is required. HTML is very convenient to use as a simple interface for small applications. All this is in Windows since version 98 and is called - HTA (Hypertext Application).
The disadvantage of an HTA is that I need several files to execute such an application, the HTA file itself, images for the interface, and COM objects with the necessary non-standard functionality. Moreover, COM-objects must be registered in the system, which makes it almost impossible to create easy-to-use applications.
')
Now, if all this is packaged in one file and run it with a special application. It is possible to do this as follows: all the necessary files: html, css, pictures and the script itself are saved in a zip file, and all frequently used objects and methods are implemented directly in the executing application. This application is a kind of framework with the necessary functionality. All this was implemented by me and received the name JSA - JavaScript Application.
But then "Ostap suffered ...". And what if the application interface is placed on a web server and from there download the script of the application itself. The HTML interface accesses the functions of my framework and performs the necessary actions. For example, we write an application - Resizer Pictures, load the application from the server, and all the work is done on the user's computer. Those. we do not need to upload the image to the server and then download it back, all this will generally increase the speed of the application. This is similar to the now fashionable extensions for browsers like Google Gears. However, in this case, the security issue is acute. If you allow the script from a remote server to run on a user's computer, then it’s not far from Trojans.
Therefore, I came to the conclusion that we must separate the HTML interface and the code of the application itself with access to unsafe functions. The HTML interface accesses application functions through a special object, in which the application script describes only the most necessary high-level methods. The application script itself is packaged and digitally signed so that attackers cannot replace it on the server.
What we get in the end. On the user's computer, a small framework application is installed that can download a packaged and signed script from a web server that, when launched, opens a window with an HTML interface that is also located on the web server. In my case, since I used the WebBrowser ActiveX interface to implement the HTML, and as the execution system for ActiveScript scripts, the executable file turned out to be quite small, about one megabyte.
What benefits can a developer get from such an application creation scheme? First, there are many options for monetizing such applications, for example, advertising and flexible management of it, because the interface is loaded from the web server, you can dynamically change advertising announcements or give access to the application for SMS using the simple SMS lock method. Secondly, we can easily update the application on the server and it will be updated immediately for all users. Thirdly, we have complete statistics on the use of our application, by simply analyzing server logs.
All this is similar to Adobe AIR or Java FX, but in my case a very small framework (1 Mb) turned out and the idea of placing the interface on the server, and not included in the application itself, gives certain advantages.
I like JavaScript as a very concise and beautiful scripting language. I used it often, and I still use it to automate some of my tasks. The disadvantage is manifested only in the fact that often there are not enough objects and methods to accomplish the goals. But in this case I was rescued by samopisnye COM objects. For full applications, a user interface is required. HTML is very convenient to use as a simple interface for small applications. All this is in Windows since version 98 and is called - HTA (Hypertext Application).
The disadvantage of an HTA is that I need several files to execute such an application, the HTA file itself, images for the interface, and COM objects with the necessary non-standard functionality. Moreover, COM-objects must be registered in the system, which makes it almost impossible to create easy-to-use applications.
')
Now, if all this is packaged in one file and run it with a special application. It is possible to do this as follows: all the necessary files: html, css, pictures and the script itself are saved in a zip file, and all frequently used objects and methods are implemented directly in the executing application. This application is a kind of framework with the necessary functionality. All this was implemented by me and received the name JSA - JavaScript Application.
But then "Ostap suffered ...". And what if the application interface is placed on a web server and from there download the script of the application itself. The HTML interface accesses the functions of my framework and performs the necessary actions. For example, we write an application - Resizer Pictures, load the application from the server, and all the work is done on the user's computer. Those. we do not need to upload the image to the server and then download it back, all this will generally increase the speed of the application. This is similar to the now fashionable extensions for browsers like Google Gears. However, in this case, the security issue is acute. If you allow the script from a remote server to run on a user's computer, then it’s not far from Trojans.
Therefore, I came to the conclusion that we must separate the HTML interface and the code of the application itself with access to unsafe functions. The HTML interface accesses application functions through a special object, in which the application script describes only the most necessary high-level methods. The application script itself is packaged and digitally signed so that attackers cannot replace it on the server.
What we get in the end. On the user's computer, a small framework application is installed that can download a packaged and signed script from a web server that, when launched, opens a window with an HTML interface that is also located on the web server. In my case, since I used the WebBrowser ActiveX interface to implement the HTML, and as the execution system for ActiveScript scripts, the executable file turned out to be quite small, about one megabyte.
What benefits can a developer get from such an application creation scheme? First, there are many options for monetizing such applications, for example, advertising and flexible management of it, because the interface is loaded from the web server, you can dynamically change advertising announcements or give access to the application for SMS using the simple SMS lock method. Secondly, we can easily update the application on the server and it will be updated immediately for all users. Thirdly, we have complete statistics on the use of our application, by simply analyzing server logs.
All this is similar to Adobe AIR or Java FX, but in my case a very small framework (1 Mb) turned out and the idea of placing the interface on the server, and not included in the application itself, gives certain advantages.
Source: https://habr.com/ru/post/64213/
All Articles