I have a javascript web application almost totally rendered client side.
The data is exchanged between client and server using models through a REST interface, then rendered using client side templates.
I have now the need to conditionally render some parts of the UI (or execute some operations) based on the user role/permission (authorization is server side model based ACL).
What is the best way to communicate permission data from server to client, taking into account that:
The models exchanged may have other embedded models with their
specific permission
I need to know also READ and CREATE permissions on different models (so the model object is not yet available client side)
Should minimize REST calls and DB calls
Your client should present controls to the user based on information returned by the server on a per-request basis. If the response from the server includes some information intended to be used to perform an action, the client should take that hint and maybe enable a button or make it visible or something.
Using this approach, you can define your ACL in terms of resource/privilege -- this model + that HTTP method. When the server is about to return a representation of a resource, it can include any options the user should see for that resource by polling the ACL for all privileges the user possesses for that resource (or others, like children/descendant resources.)
I am not sure what your application requirements are or if you are currently using any javascript frameworks. I would look here. Addy Osmani is very big in the javascript community and has helped create this javascript framework. It looks like it has the ability to handle your question. Here is a quote from the main README
The Sandbox includes a permissions layer, allowing you to configure permissions for widgets such as whether a specific widget has the right to render to the page etc.
There are a number of other javascript frameworks as well that you could look into that would make handing page level security a lot cleaner and means you wouldn't have to rewrite a lot of the code. Another example is Backbone Marionette It has the notion of composite views that would make it straightforward to implement page level security.
Finally another option is to not transfer your security information at all. Your REST API could only provide the model information that they have access too. You would need to write your client side templates in a way that would appropriately handle "missing" data so to speak.
Related
Would there be any mechanism (at least theortical) which would allow to control which scripts are provided to a client? I have splited code into dynamically loadable parts using import('dynamically_loadable_file') but whenever is it called on a client, the file is served. I'd like to perform some security check whether does a user have permission to load the file. I thought of middlewares but those are only for HTTP and executable scripts are served through WebSockets.
Also, if it would be possible I would like to control content of the provided scripts. E.g. I'd like to add or "hide" some functions or variables to the script based on a user loading them. I guess something like dynamic compilation using AST would be required, or maybe there is/would be available something else. I guess that's another level but if there would be some content available on such ideas I'd be thankful.
Maybe it is not possible with meteor at all, so if this is possible wherever in JavaScript (node.js) world, it'd help too.
Thanks for ideas and explanations.
Most client-side protection mechanism can be surrounded with enough knowledge and the right tools.
The most viable solution to your problem would be to use a server side rendering (ssr) library for your current front-end engine.
With ssr your would solve to
allow to control which scripts are provided to a client?
perform some security check whether does a user have permission to load the file
scripts are served through WebSockets
control content of the provided scripts
add or "hide" some functions or variables to the script based on a user loading them
Because all your templates are rendered on the server and only the resulting data is returned to the client.
Some ssr packages for Meteor:
Generic: https://docs.meteor.com/packages/server-render.html
React: https://www.chrisvisser.io/meteor/how-to-set-up-meteor-react-with-ssr (guide with link to a boilerplate repo)
Vue: https://github.com/meteor-vue/vue-meteor/tree/master/packages/vue-ssr
The native Meteor Way
Besides this I would like to emphasize, that you can achieve most data handling through Publications and Methods.
Showing / hiding HTML elements on the client does not add any security if your data and logic are not secured on the server.
If you only publish the right data to the right user (for example using alanning:roles) then it does not matter which scripts you load.
Same goes for Methods: If you are very strict in who (use again alanning:roles) can call a Method then it does not matter, if a user can disable the Router and see all of the "hidden" areas on the client because all invalid actions are rejected server-side.
I want to create a Javascript widget that my users can put on their websites.
The widget is capable of creating audio, which in turn costs my users' money.
For the sake of illustration, let's say that every time a widget, placed on my user's site, is loaded by anyone on the internet (i.e. my users' users), I bill my user $1.
The widget is a Javascript code wrapped around an HTML audio player. The JS code makes a request to my backend API every time it is loaded, and upon receiving the response from my backend API, the player is constructed.
Diagram:
My concern is malicious usage by people who are not my users.
Let's say someone takes the widget's source code they found on a website that belongs to one of my users, and they put it on their site. They will, therefore, use my service but not pay for it. Instead, my actual user will pay for it (assuming I use a public API key as a way of distinguishing my users).
Usually, this is prevented by having a server-side library be responsible for any usages that might spend money. For example, I use Pusher as my WebSockets IaaS, and whenever I want to publish messages, I have to do it server-side, using their PHP SDK, with both private and public API keys.
In my use case, it's mandatory not to have a server-side library.
Question: how do I make sure that API requests I receive are legitimate?
I considered using the hostname where the widget is placed as a legitimacy measure. During the widget set-up, I could ask my users to whitelist certain (sub)domains and reject all requests that don't match the criteria, but this could be easily spoofed by, for example, a custom local domain or a CURL-crafted request.
I understand this may not be possible.
It seems like what you're asking is closely related to the topic of client side encryption. In most cases, the answer would be no, its not possible. However, in this case, it may be possible to implement something along the lines of the following. If you can get your clients to install a plugin (which you would build), you could encrypt your JS code after finishing it, and have your server serve this encrypted file. Normally, where this falls short, is that if you're sending an encrypted file, there needs to be a way for the client to decrypt it. This would require you to also serve an unecrypted JS file which would do the decoding, but by serving the unencrypted decoder you undo any security gained by encrypting your main JS file (the decryption file could be easily used to reverse engineer your encryption method/ just straight up run for people other than your intended users). Now, this is where having those API users (and the ability to communicate with them through means outside of server-client connections) comes in handy. If you build a decryption plugin, and give it to the API users (you could issue a unique decryption key for each user, but without server access implementing unique user keys would be very difficult/impossible), the plugin could then decrypt your served file in their browser, essentially guaranteeing that only users you have given the 'key' to can access your software. However, this approach has a few caveats. It implies that you trust your users enough that they wouldn't distribute the plugin (it would be against their intrest to distribute it anyway, as it could lead to higher chargers if people impersonate them). There are also probably a couple of other security concerns with this approach, however, I can't think of them right now. If any come to mind, I'll edit this post and add them.
apparently, I don't have enough reputation to comment yet, hence the post...
But in response to your post, I think that method seems much better than the one I suggested; I didn't realize you could control the API's response to the server.
I don't quite understand which of the following you mean:
a) Send a JS file to the user, with the sole purpose of determining if the player should also be sent (ie upon arriving, it pings the server with the client's API key/ url) and then the server would serve the file (in which case your approach seems safe to me, but others may find security problems with it).
or
b) Send a file with the JS and the audio player, which upon arriving, determines if the URL and API key are correct, and then allows the audio player to function normally (sending the API key to the server to track usage, not as a security feature).
If using option b, this would not improve security. If your code relies on security that runs on the client-side, and the security system was sent by the same means as the code, then almost without exception, the system designed is flawed and inherently unsafe.
I hope this makes helps, and if you disagree / have more questions, feel free to comment!
How about sending the following parameters from JavaScript widget to API backend:
Public API key (e.g. bbbe3b259f881cfc796f468619eb9d)
Current URL (e.g. https://example.com/articles/chiang-mai-thailand-january-2016-june-2016)
I will use the API key as a way of distinguishing my user and the current URL as a way of knowing which audio file to create (my widget will create an audio file based on the URL).
Furthermore, and this is crucial, I will have a user whitelist their domains and subdomains on my central site, where my users will get their widget code.
This is the same as what FB does for their integrations:
So if for example, my backend API receives the aforementioned sample URL, and the user has set up the widget to only allow URLs that belong to foo.com and bar.baz.com, I will reject the audio creation process and display an error.
Do you see any issues with this approach?
I have a client web application. The user clicks buttons, gives inputs, makes selections, etc... This is all done with Java using the Spring framework.
The client talks to another service that I have built in Java (with Vertx). This service talks to the database, handles caching, and the endpoints return values.
user navigates to web page--->client controller handles request mapping--->
--->request mapping uses controller method to return view--->
--->view's JS makes requests to service--->service returns model data
Now, I like the idea of control that Spring controllers offer. My client's pages use the Spring controllers to return views, and a small amount of model data.
However, what I am doing to call my service is: in my view's JS, I am making AJAX calls directly to the service. I mean, it works, and that is what was suggested for me to do, but I'm not sure if that is what I should be doing.
The alternative would be for my client to make JS calls to the client app's controller, and let the controller from my client app make requests to and receive responses from my service, then pass those responses back to my JS. I feel like this is probably the "cleaner" or "better" way to do this, but I am only about a year into programming with Java and don't know what the best way of doing this is. Essentially,
user navigates to web page--->client controller handles request mapping--->
--->request mapping uses controller method to return view--->client view's
JS makes requests to client controller--->client controller makes request
to service--->service returns data to client controller--->
client controller handles data and returns data to client view's JS
My gripes are that the JS exposes more than I would like it to in terms of the service's endpoints. Furthermore, I feel like using my client's controller to call the endpoints just seems... right.
I'd prefer input of experienced developers on what is right and/or wrong about these design patterns.
I've seen it successfully implemented both ways. Using a client controller is a fairly easy way of narrowing the exposed surface of the API (provided you lock-down access to the back-end services, otherwise you're just wasting your time). This method also allows you to turn the Client Controller into an adaptor to adapt the return values from the API into something more UI-centric (e.g. map codified values into text via an i18n file) and pare down any surplus data before it goes to the client.
However, there's an element of extra work or duplication as well as a performance overhead (hops, marshalling and unmarshalling).
If you ever suspect you're going to expose the underlying API or the client's usage of it is going to grow to the point where you've effectively created a shadow copy of your API, you should just put in place a robust Auth and Auth system to only allow calls from the appropriate places. This is not a trivial task, but would allow you to expose the API to other consumers.
The current and expected future usage of your API (but don't go all YAGNI on this!) should shape your decision. It may be appropriate to have the Client Controller layer doing filtering and shaping to avoid excessive client payload or not if you want the client to have a more transparent representation of your resources.
I am looking at express.js for the back end and JS on the client side.
My app is a single page Web App.
The server will only serve JSON messages and my question is about "routing" for express.
Is one supposed to use routing to connect the UI and the server side business logic?
How will that work with my single page app?
so lets say, the client makes an Ajax call to the server looking for a value in the database and there is server side script that provides the JSON back to the UI. How is this UI and node script relationship setup?
Can someone shed some light on this?
Single page apps are those that live on a single HTML document. This means that if you want to display some different content to the user, depending on the state of the application, you will need to do some DOM manipulation (cutting out and replacing certain elements of the current document with different HTML) in order to update the 'view' that the user sees. Excuse me if this is obvious to you, please don't take offense. I figured I'd start from here. Hang with me and I'll explain how your routing situation is going to play out (more or less).
URLs are composed of a few different parts, each of which informs the browser of a particular bit of information that is required in order to download the resource that the user is attempting to access. Typically the resources that you are looking for are off on a server somewhere and the browser knows this because of pieces in the URL like 'protocol' ('http:') and 'host' ('www.mydomain.com'), so it goes off to that server to find what you're requesting. There are also 'query' parameters in URLs which provide some additional information to the server regarding a particular action, like the search terms of a search query. After the query parameters, comes the 'hash'. The hash is where the magic of single page apps happens... eh, well, kind of.....
First a bit about the hash. When you add a '#' to a URL, the browser then interprets the information that comes after it to be some location (element) within the currently displayed document. That means, if you have an element with an 'id' of 'main' and you add '#main' to the end of the URL, like so: 'http: //www.example.com#main', the browser will 'scroll' (typically 'jump') to the beginning of that element, so that the you can see it. Be aware, though, that if you type 'http://www.example.com/#main' (with the hash separated from the URL by a slash) then you will force a complete page reload and the browser will attempt to find a file by the name '#main' on the server (I bet it doesn't find it).
The takeaway here is that the browser will not attempt to navigate away from the current document if there is a hash in the URL, the exception being of course the case mention above, and this is great because single-page apps don't want to navigate away from the page or request a new document from the server. (See how routing is different for single-page apps?)
Now, this whole thing about the hash isn't vital to single-page apps, as you could make one without dealing with it all. A bunch of click handlers and DOM manipulation is all you'd need really... But, that would mean that users will have no way of sharing links to particular views in your app. The URL would never change, and we would never be able to navigate to any particular view directly. We'd always be starting from the starting position of your app, which could easily be a very annoying situation.
If your single-page app is going to have different views, and you want users to be able to navigate directly to particular ones via bookmarks or links, then you will need to implement a form of routing on the front-end in addition to the routing that you'll need to implement on the backend (routing for data API, etc.), which means that you will need to make use of the hash.
I don't want to get into how different frameworks accomplish routing on the front-end, but it's basically a matter of updating the browser's address field when the user clicks a link, and watching the address bar to determine what the current URL is and loading the HTML that is associated with that URL into the DOM in the designated location in the document tree.
So, within a single-page app, you have one route on the server that deals with rendering the app HTML document (index.html), and you have routes that are responsible for dealing with the data of your app (creating new instances in the database, logging in and out, editing or destroying instances in the DB, and fetching data...) which are called via AJAX requests.
This is actually a fairly complicated situation in that HTML5 allows us to be able to forgo the hash (with the help of some link rewriting on the server) and also be able to use the 'back' and 'forward' buttons as if we've actually navigated away from the original document (which we haven't because we have only pointed the browser to the exact same URL, only with modified hash values, so no new page loads have occurred). Traditional site navigation and linking can be achieved by utilizing the browser's History API, which is available for IE beginning with version 10 (I believe), the rest of the big browser vendors were already on to it quite a bit earlier, so frameworks that leverage this technology will allow your users to navigate your app without the hash in the URL. Explaining this is a diversion and not necessary for understanding routing in single-page apps, but it is interesting and you'll have to learn it eventually anyway, probably..
AJAX should be used to request JSON from the server. AJAX requests will always hit your server because you don't include the hash symbol in AJAX requests (it would be ridiculous to do so because the hash is meant only for in-document browsing), so server-side routes must be responsible for exposing your data API (consider a RESTful one). While this is not their sole purpose in single-page apps, it is perhaps their most important one.
Soooo, to wrap it up, you will have two sets of routes. One on the client (as part of a client-side framework like AngularJS or EmberJS, the list goes on... I prefer Angular, but there is a fairly steep learning curve for that one.), and one on the server. When you think about 'server routes' think data API. When you think of 'page routing', remember that this all gets handled on the client, by the javascript that you delivered with the initial server response (this is the one and only necessary server-side route involved with rendering HTML to the browser, loading your 'index.html' and all of the necessary scripts and stylesheets, etc). You will use express.static middleware to serve static files, so you don't have to worry about assigning routes for that stuff.
EDIT A quick mention of AJAX implementation.
On the server, you will have routes similar those that Alex has provided as examples and you will make calls to those URLs from the client using whatever XMLHttpRequest (XHR) object is exposed by your framework or library of choice. It is now considered more or less standard and best practice for frameworks/libraries to implement these requests as Promises http://wiki.commonjs.org/wiki/Promises/A. You should read a bit about it on your own, but I might be able to summarize it by saying that it is an asynchronous operation analogous to 'try, catch, throw' in synchronous operations. You will instantiate a promise object and through it you will attempt to load data from the server, for instance, via GET request. Make sure that you have assigned functions to handle requests made to the URL that you made the request to (server-side route)! This object that you instantiate and subsequently make the request to the server through, promises to return the result of the request to you once it comes back from the server (no matter whether it was successful or not) If it is successful, it will call a function that you have written and will supply it with the data from the server. If it fails, it will call a different function, also written by you, and will supply it with the error object (or 'reason' for failure), so you can handle the error appropriately.
Hope that helped answer your question.
You only have to route requests you serve dynamically. Your HTML, CSS, JS are all static assets. So all you need to handling routing for is your data.
It sounds like you want a Restful API, which basically means that you have URLs for specific resources, and HTTP verbs for manipulating them.
Something like:
GET /books.json - Get all books
POST /books.json - Create a new book with properties passed in the body of the request
GET /books/123.json - Get book with id of 123
PUT /books/123.json - Update an existing book with properties passed in the body of the request
This blog post seems to show how to set this up in Express.
Once you have a sane API delivering JSON, you just make your AJAX calls use it based on what objects you want to fetch.
I have a service method written in ASP.Net WebAPI :http://diningphilospher.azurewebsites.net/api/dining?i=12
and JavaScript client gets the response and visualizes it here
But the nature of Dining Philosophers problem is I never know when the Dead-lock or starvation will happen. So Instead of having a request/response I would like to stream the data through service method and client side JavaScript read the data I assume JSON asynchronously. Currently several post directs me towards changing the default buffer limit in WebAPI so you get a streaming like behavior.
what other(easy or efficient) ways exist to achieve this above behavior.
You can return PushStreamContent from ASP.NET Web API and use Server Sent Events (SSE) JavaScript API on the client side. Check out Push Content section in Henrik's blog. Also, see Strathweb. One thing I'm not sure about the latter implementation is the use of ConcurrentQueue. Henrik's implementation uses ConcurrentDictionary and that allows you to remove the StreamWriter object from the dictionary corresponding to the clients who drop out, which will be difficult to implement using ConcurrentQueue, in my opinion.
Also, Strathweb implementation uses KO. If you don't like to use KO, you don't have to. SSE JavaScript APIs have nothing to do with KO.
BTW, SSE is not supported in IE 9 or lesser.
Another thing to consider is the scale out option. Load balancing will be problematic, in the sense there is a chance that the load will not be uniformly distributed, since clients are tied to the server (or web role) they hit first.