Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Although currently still in the planning stages of implementation for our company website, we are considering different methods and technologies that successful at addressing scalability, performance, and security (as in people can't steal or easily reverse engineer our financial algorithms) concerns.
According to several posts here on stack overflow, it appears that since we have already completed a good deal of algorithms via Java for our desktop applications, accessing these algorithms via Java Servlets and JSON requests (as can be seen here and here) online might be a good choice, as it would save considerable time and money by not having to rewrite them in a different language.
Before moving forward however, I would like to know if the time and money saved by this approach would be worth it in the long run, and specifically, is accessing (java methods and array data) via JSON and Javascript both secure and scalable, compared to say rewriting all of them in straight javascript? Also, is support for applets and servlets ubiquitous, or is it possible that a good chunk of our user base would not be able to have access our website without having to download additional plugins?
In the ideal situation (minimizing learning new technologies), I would like to use technologies involving HTML5 canvass and JavaScript for all of the graphical stuff, but also be able to access small data via java algorithms (which will return an array with less than 100 indexes), however eventually on a large scale in terms of number of simultaneous users (no logins).
Is this a good option in terms of speed, compatibility, and security, or is there perhaps something that we overlooked?
Sounds like you're describing a fairly common architecture of web apps.
The client side is in HTML/CSS/JS and is responsible for presentation and UI related logic and the backend does the heavy lifting. The communication between the two is done via HTTP requests, probably asynchronous (AJAX) to REST endpoints your server provides.
This is a proven method in terms speed,compatibility and security. Pretty much every website out there uses something like this.
To get started you'll need a REST server running, I recommend using Dropwizard which allows you to setup a RESTful server fairly quickly and easy. Although if you have special scalability requirements you might want to look at other frameworks.
Here's an example of how an REST endpoint looks like in Dropwizard.
#GET
#Timed
public Saying sayHello(#QueryParam("name") Optional<String> name) {
return new Saying("Hello " + Name);
}
The name variable is being sent from the client side (JS/AJAX) and then you have a standard Java function where you can do whatever you want. Finally you return some kind of result (Saying) and parse the result on your client side.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm concerned about javascript security as client can view and edit code, I know to overcome this we can use ajax calls to run critical process on server. But recently I was going through parse cloud code, a part of it runs on server. I would like to know if that's the answer to javascript security concerns and is it safe?
Is Parse.com server-side Javascript safe?
Server side Javascript is relatively safe. In the case of Parse.com (I am not very familar with their systems) it appears to accept client-side data. Client side data is always unsafe. That being said, you can make it safe by parsing it (pun not intended) to ensure anything potentially dangerous is stripped out before running it.
The safety in this system then, is dependent on how well you write your code.
Is server-side Javascript safe?
Related to the above, server side Javascript CAN be safe, provided it is written in a secure manner. IE, only data is passed and any data that needs to be secure remains on the server and is only updated by the server.
For example if you are updating game score (taken from some parse.com examples) instead of sending the server the score to update, send it the action that triggers the score update and let the server resolve the action and add to the score. This is safe. Sending the score itself is not, as the score can be manipulated by the client.
Is Parse.com client-side Javascript safe?
Absolutely not. The client is in the hands of the enemy - you can never ever ever trust the client not to manipulate their data and/or the code that generates it.
The onus is on you, the developer, to make sure that your data is being handled and processed only by a system that cannot in anyway be manipulated by the client.
So, is parse.com safe?
Echoing everything that I have already said, parse.com is as safe as you make it. It simply depends on how well you engineer your application.
Is server-side Javascript the answer to security concerns?
Server-side anything is inherently more secure then client side. Is it a one stop fix for all security concerns? No. There are still plenty of dangers in bad coding (IE: SQL Injection) or even open ports (IE: Email forwarding through a web server). Thus there are two aspects to this sort of approach, securing the server and securing the code. These are usually divided up to people of an appropriate skill (developers should not be asked to close ports on the servers, for example, unless there is no one else to do it and you have run out of bananas for the trained monkey).
However, not everything can be run on the server. For example, capturing client input and drawing elements to the screen are two things that the client side will just have to accept. This is where it is on you to decide the needs of your system.
Take our example above about posting score to the server via action instead of score number, it is inherently more secure then sending the score, but it is still not totally secure when sending an action because the player could easily spoof the system to send repeated actions.
You COULD develop some logic to see if the action is allowable, or some even crazier logic to decide if the action rate of a player is Human, but then you could just never let anyone report their score to the server and THAT would be the most safe and also result in a not-very-fun-game.
It's always a calculated risk to decide what areas of anything you can and can't secure and what aspect it will have on the application (or Game - I use game because parse.com examples used game) in question.
Further StackOverFlow Related Reading
There are some good notes here about the particular vulnerabilities of Javascript Injection:
Javascript security risks?
This one speaks directly to client-side/server-side validation:
JavaScript: client-side vs. server-side validation
There are some notes here about 'how-to' minify and obfuscate code:
How can I obfuscate (protect) JavaScript?
Regarding obfuscation in Javascript, see here for lots of notes about how unsafe it is (especially in the comments):
Hardest-To-Reverse JavaScript obfuscator
If you are really concerned about your javascript, then you can
1) collect your JS routines in a single JS file and minify it using js compress which will make it hard to read and understand.
2) scramble/obfuscate your JS code using JS scrambler which will make it a little more difficult for the cracker to crack your JS
However, considering the vast array of tools available on the web, in my opinion, JS can be compromised any time by the cracker who has a malicious intent. This can be compensated by imposing strict security protocols on the server side.
Hope it helps!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
instead of doing all your server operations via the POST method token ( and the content type set to json ).
I've done some research here and I am referring to the method tokens mentioned in the ietf document.
https://www.rfc-editor.org/rfc/rfc2616#section-5.1.1
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
I don't see the benefit of using all the other server type requests. I know they are used, particularly what spurned this interest was Backbone's use as seen here:
var methodMap = {
'create': 'POST',
'update': 'PUT',
'patch': 'PATCH',
'delete': 'DELETE',
'read': 'GET'
};
These properties are eventually passed to the xhr open method which you can read about in the links I posted above.
Actually the MDN article has pretty much no information while the W3 articles seems a bit esoteric.
What you've described is an application design philosophy called Representational State Transfer (REST). The philosophy is much more encompassing than just using multiple request methods. It also covers the idea that each type of data needs its own URL, how that URL should be logically structured and what should belong to query parameters and what should be a URL path. REST is one of the earliest ideas related to Semantic Web - the idea that websites should be easily readable to machines as it is to humans (or to put it another way, the idea that the website should be easily understandable to developers as it is to regular users).
You can read the original paper describing REST here: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
REST is actually just one chapter in the whole paper. The paper describes what a web architecture should ideally look like.
Do you need REST?
The short answer is of course no. Technically speaking you're allowed to do whatever you want that works. Indeed, back when ideas of REST was first introduced there were no easy way to do PUT and DELETE requests on some browsers. So people stuck to GET and POST and the HTTP spec was updated specifically to make GET and POST have RESTful meaning.
The HTTP specification recommends that GET only be used for indempotent operations (requests with no side effect) while POST should be used whenever a request causes something to change in the server. But developers have been using GET to update databases due to easy debugging because you can just construct the query in the URL entry field in your browser. The RESTful way is to only allow POST requests to update the database (or save anything to file).
What's the advantage?
The advantage is to essentially allow developers to treat the web as an API. Allowing machines to read webpages allows for things like mashups, creating mobile apps as front-ends etc.
A good API or library is consistent. A consistent API is easier to use, easier to remember and doesn't require the developer to look-up documentation too often. REST attempts to provide this consistency by giving real meaning to the types of request. Therefore if you see PUT request you don't have to guess what it's doing.
As such, as a programmer, it is to your advantage to not only be RESTful as much as possible but also convince as many other programmers as possible to create RESTful websites. If all websites are RESTful, writing scripts to do smart things with online data becomes much easier.
On the other hand, as a programmer, you also have the freedom to disagree with other people's ideas.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Most traditional MVC frameworks include their own templating solution (Jinja2, Mako, etc). If one decides to use one of those new ui frameworks such as angular or backbone, they seem to encourage the use of front end templating solutions.
Is there any difference in performance? What are the pros and cons of going either way? Are there issues in ie or other browsers when using some of theses js templating solutions?
My take on this is simple, really.
Use a server side templating engine when you want to template the structure of a site. Use a client side templating engine when you want to template the data of the site. And there is nothing wrong at all with using both, as long as they don't have a large amount of competing tokens.
A VERY common example of this is using ASP.Net MVC to manage the bulk of a site structure using the razor template engine, and using a JavaScript client library such as Angular.js to simplify the data structures on the individual pages.
Depending on the situation, one major factor can be a significant change in bandwidth usage.
For example, my newest project includes the ability to have colour codes in chat (and other places). These codes look like:
`1blue `2green `3yellow `4red `bbold on `Bbold off `b`iBold Italic...
I could parse this server-side and return:
<span style="color:blue">blue </span><span style="color:green">green</span>...
But see how I only did two words and I'm already going longer than the source text! Instead, I chose to implement the parser in JavaScript, on the front-end. This takes a lot of processing off of the server (which would otherwise have to parse this stuff for every single user) to the client (where only one user is being dealt with).
It also had the advantage that I could implement a live preview just by plugging in to the same parser, but that's irrelevant here.
Additionally, client-side templates can be cached, further reducing the amount of data that needs to be sent. This can be particularly beneficial to mobile users, who may not have unlimited data (those poor people... I weep for them... not really)
Personally, given the choice, I'd strongly recommend client-side templating (although in my usual style, I would shun all pre-made solutions and make my own XD I'm weird like that) for a variety of performance reasons. Obviously, the major downside is "no JavaScript = no website", but I'm fine with that since the entire site relies on JS...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
There are a lots of new frameworks, technologies coming up. And it's becoming so hard to follow up all of them. One of the thing that confuses me is client side frameworks. I heard that Angularjs,Backbone,Knockout,jsviews,knockback, SPA... are the most popular right now.But I can't understand how does the security concept applies? If we take an example of querying a table form database it's now possible to make queries from client side database, by specifying table name and fields and etc... So if it works that way, than everyone else can write another query and get all other information. I am pretty sure that I am missing something very important here, and it doesn't click my mind. So please can anybody explain me where can I start learning those primitives.
I really appreciate, and I am really eager to learn but I am searching it wrong way I guess.
Whatever the framework used, the security matter will still the same, and very similar to mobile apps:
which data can you afford to be handled in an untrusted environnement
which treatment can be applied in an untrusted environnement
By "untrusted environnement" I mean the browser itself. You have to understand that any code executed in the browser can be corrupted by a medium/good JS developper.
Data security suffer the same threat: giving access to data from your client means that you do not control anymore who is using it.
Once you've dealt with this simple matter, it became easier to decide what must stay on server side, and what can be deported to client.
That said, there are various ways to make data/algorithm steal more difficult:
Obfuscation that comes with minification
Double data validation (forms for example): both client and server side
Authentication protocols, like OAuth
Binary over webSockets, instead of plain json and ajax call...
The browser sandbox imposes some limitations, but mainly to protect the local computer from damages due to malicious JS code. It does not protect your code nor your data from being seen and manipulated by the user itself.
I am using angular for some of my projects. I haven't used other frameworks , but in angular you usually consume an API to get the data. You don't query your database directly. So, the responsability of securing your data is more in you API (Backend) than in your angular client.
You can use OAUTH, or other security method that you want to make your api safe.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Similar to this question; When to use JavaScript template engines? but not quite.
Is it practical to make full sites (e.g. skip static HTML and PHP processing and just send JavaScript with HTML templates for client side rendering) in client-side JavaScript with a template engine such as handlebars? Or, are template engines only useful when it comes to re-usable template sections?
You have half of the the answer, which is re-use, but you can get that on the server-side. To me the other half is as follows:
Allow front-end developers to handle all the interactive development in JS and HTML, almost without knowing JS for simple templating needs.
For web applications the UI rendering on the server slows or limits the interactions/experiences one can design, or at least limit performance. Why does the server have to know and understand the User button clicks? The browser is powerful enough to handle the button clicks.
It pairs nicely with REST services. The browser knows how to request the data and determine the user context.
More complex web server side design. State is a very complex thing to manage across clusters and nodes. Not that you can't but why should you? Especially as for most modern web applications (web 2.0 and all that jazz) the whole point is the browser doing more, handling button clicks, sorting data, etc. Guess what all that is user state. So the browser already has a lot. So why distribute that state across a cluster of servers adding latency, dependencies, etc. I have a no HTML in the application server policy.
Change control. When you write PHP and embed HTML snips in everything things end up tightly coupled. It reduces flexibility of use case changes.
Separation of concerns, forcefully. Many developers are tempted to do business logic in the view. Simple templates help reduce the likelihood of this. One could easily construct an argument against all non-templating based approaches, JS or server-side but that is not the question at hand.
If you are going to build a mobile app you want and need services that avoid presentation markup. So never generate HTML in the application server or else your app will only speak one language. People might shout server side MVC will help, but not for off-line, different access patterns, etc.
There are some performance, device detection, 'dumb phone' reasons to generate html server-side, but then write it off of the services which your JS web app use. Let that be the exception. Even better write it in JS on the server-side and re-use the business functions and logic on both.
I use a JavaScript template engine when I make one-page web-apps (with backbone.js for example).
In any other case, I would not use a JavaScript template engine.
The reason for this is, that if I create an application in anything other than JavaScript-only (PHP, Rails etc.), I like having the templates done on the server rather than at the client.