I have an angular app on a node js server. On another machine, I have an API server. My dilemma is how to communicate with the API server. The first approach is to send all my AJAX calls directly to the API server. The downside of this approach that the client will see how I send the requests to the API, including the secret key I send in the headers. This means I will have to work harder to secure my API. The other approach is to send my requests to my node js server, and then forward them to the API server. The downside of this approach, however, is increased latency, since it will require two serial HTTP requests. I would love to hear from you what you think is the best way to handle this.
Thanks.
First approach, and you "have to work harder to secure your API". I recommend JWT autthorization.
The most popular and reliable solution for this widely followed architecture style (Front End App to Backend API Server) is OAuth.
OAuth is very easy to setup and use with Angular Js.
As far as AJAX calls are concerned, if your application entails this behavior make sure your API is enable with CORS capability.
Related
I used Riak(http://basho.com/riak/) as rest service and Angular on client. When I try to use method "PUT" then first request is OPTION, but Riak doesn't know how to properly respond for this.
I found some clients but all of them are made to run on server, not sure about Node.js client like this http://riak-js.org/
Can I make it working from web client?
Maybe Riak was not meant to work with web clients directly, then I'll try something else.
I don't know about Riak, but the OPTIONS request suggests that you're trying to perform a cross-domain request (Angular running on domain "aaa.com", Riak on domain "bbb.com", although it can also even be just a different subdomain or port number).
My guess is that Riak doesn't support CORS, in which case you need to look for an alternative (a simple server-side proxy might be all that you need, although please consider the security impact of exposing Riak directly to browsers).
I have found js gui client for Riak https://github.com/basho/rekon, but it works directly from riak, that's not what i wanted but maybe i can use same solution also, or make proxy on server
I'm new to both angular and web api, I've worked previously on asp.net web forms and java jsp's my question is since angular is pure js framework and web api is used for Http services ,if we build web applications using both these technologies how can session management be handled, can we create session in web api controllers ? If we can, since webapi (REST) is stateless does it violate the principle of REST statelessness , please clarify
Thanks
Angular and WebAPI do not change how to track session in web applications. Usually, this is done with a cookie that is sent with every request. Since cookies follow domains, Angular requests will always send in the cookie (just like they did before).
To answer each of your questions:
can we create session in web api controllers?
Yes, we can access session through HttpContext.Current.Session.
does it violate the principle of REST statelessness?
REST (Representational State Transfer) doesn't have a principle of statelessness. HTTP is a stateless protocol. REST says that calls to the server (using HTTP verbs etc.) should progress state of the application.
I don't have the reputation to comment in response to him yet, but David Tyron seems to be misunderstanding the term "stateless" in this context. Obviously, both the API and the UI using it have to maintain and progress data that can be properly labeled a state, but in the context of RESTful APIs, "stateless" is usually specifically referring to the fact that the API doesn't keep track of the client's state.
The idea behind this is that each request to the API must include all of the necessary UI information to perform the required action. In other words, each call must happen in isolation and independent from each other.
Sessions absolutely violate this principle, though it's probably the most common thing that is used that prevents something from being 100% RESTful.
(On a related note, Cookies still count as stateless since the client is the one responsible for storing that data.)
Here is my scenario:
I am going to build a AngularJS webapp which requires to interact with multiple cross-domain server. There are two approaches:
Make all the requests from client side - From my understanding AngularJS enable us to build a rich client and make REST call to server to obtain data. However for this approach I have to handle CORS issue.
Moving those call to server side (Node.js) - Node.js makes all the calls to cross-domain server. It exposes REST API for AngularJS to request Node.js to make those calls.
Which approach is suitable for my scenario? Are there any criteria that can guide me to use which approach?
Those cross-domain resources are not maintained by me. I have no way to control their ways to provide resources. Also at least one of the resources does not support CORS. At this moment I config a proxy to handle those call.
When it comes to interacting with cross domain, you options are using either CORS or JSONP if supported by target server.
In case not the only viable option is to proxy the request through your own server.
You can make everything proxy through your server but that would require effort and time to implement.
I don't see any harm in doing the normal CORS or JSONP way for server that support it and use the proxy approach when the underlying infrastructure does not support it.
I am creating a web application using GAE/GWT. Front end GUI is a web client and the server is a RESTFUL server both running in GAE in different domains.
I am using json with padding to communicate with the server but discovered I won't be able to send a PUT/POST/DELETE request.
My application will be used to mainly used to query data (query: 85% of cases, modify data: 15%). All requests will be authenticated.
I am considering the following options.
1) For querying use JsonpRequestBuilder, for modifying create a proxy in the web client server side and hit the REST service through this proxy. Use GWT RPC to communicate to this proxy.
2) Make every request as a GET request in my REST service (including those that modify data) and use jsonp directly from web client.
I would prefer option 1) but option 2) seems less work to do.
Should 1) be my preferred option ?
Are there any problems with 2) given all my requests will be authenticated. ?
Is there any other easy approach to solve this problem ?
Regards,
Sathya
The simplest solution is to use CORS which allows you to send requests two different origins. But it is not so widely spread (check caniuse), so if you have to support IE8-9, it will not be enough for you.
In your case I would try to implement dual solution (e.g. CORS + server proxy). If browser supports CORS - send the request directly to the target server, if it doesn't - send request via proxy.
Sorry to ask but what is the advantage to have your client running on a different domain ? From what I understand your client's server will do nothing ...
If you are not the "owner" of the REST backend, maybe this backend should developp an authorization system for third party applications, like oauth2.
Then your application can talk backend to backend with a secured connection. You can use scribe to do that on your backend.
I am sending HTTP requests from GAE to MongoLab in the form of:
https://api.mongolab.com/api/1/databases/rival_testdb/collections/testCollection?apiKey=someKey
If this request was coming directly from client side, I would be very concerned. But since this request is coming from inside a servlet in GAE, is this a security concern? How could I make this more secure if possible?
I would like to use MongoLab if possible, but their API only allows for putting the API key directly in the requesting URL. So I am stuck using a URL like the one above for all API requests.
As long as you can secure the API key on the server you should be good. You do not have to worry about it being sniffed on the network as all the communications are over HTTPS thus encrypting the request string and the apiKey along with it.
-will
This is a valid concern for most public services.
Specifically for MongoLab, this discussion is present over here: https://support.mongolab.com/entries/20269612-REST-api-permissions-and-security-best-practice and it does not look like the security additions that they are talking about has been released in public.
Do check out to the link.
Having said, I am assuming that the only way that you are accessing the Mongolab API is from within your GAE Application? That at least makes it more difficult for anyone to sniff out the url from your application.
A good solution would be for MongoLab to allow a HTTP Header to be inserted before your make the REST call. Here you would some ID that identifies that it is your GAE App. And then MongoLab should be doing a check for that before permitting the call to do its work.