I've recently programmed a REST web service API that allows another website to sign-up for my website remotely.
I've programmed all the necessary validation and filtering in to the API.
My question is, should I now ensure that my own registration form uses the web service API when handling user registration?
The form itself already has the very same validation, but it would seem to be that it would be best if there is only one method that is ultimately responsible for validation/filtering.
That solution doesn't seem to be the best, either, though because I am now making a REST client to touch my own web services API from the exact same website.
The last solution that comes to mind is to put the validation on my user model, and throw an exception up the web services API when validation is triggered. Are there any downsides to this solution?
One of the major benefits of REST is to define a interface that a remote client can access easily with the minimum amount of coupling between client and server. This is very useful when you do not control the client. This allows you to evolve your server interface without breaking existing clients.
The REST interface should really just be a thin layer over your validation and registration logic. In theory it should be easy for you to re-use that logic in your own website without going through the REST api.
Your website is not on a remote machine and you have control over both the client and server portion so you are not gaining anything by going through the REST interface.
Related
I am tasked with a web application project involving a lot of dynamic design.
I am going to build a RESTful API with Node.js with token-based authentication, and initially I thought about building another Node.js application for web-based UI, but now that I have a basic design of the API, I was wondering if it is feasible to implement all of the UI logic with JavaScript on the browser?
It would involve a HTML page, which has JavaScript that will GET/POST data from the API, and update the DOM accordingly, furthermore, I would save authentication token in cookie, and the JavaScript in browser would do everything ranging from login to updating/deleting/creating all kinds of data through the RESTful API.
I haven't heard anything quite like this, is there any security concerns? Off the top of my head, the API server would get tremendous amount of requests if attacked.
Regardless of the amount of traffic or code, the security concern is the same.
Is anything sensitive being sent to the browser?
Is any request to the server not being validated?
That's pretty much the extent of the security. Any attacker can craft any bombardment of requests to any API, regardless of how complex the client-side code for the application is.
Assume that client-side code might not execute at all. Assume that you have no control over the client-side code. Assume that every request reaching the API must be validated. Assume that any input coming to the API can't be trusted. Etc.
Basically there are no additional security concerns which wouldn't exist in any of the simplest web applications.
We have web applications that we build internally (server side exposes web-services that are called from client side JS).
We also required to expose our code functionality in REST API.
I wonder - should I also start to use the REST API also for the web application that I build internally?
Originally, the REST architectural style declares that the REST is stateless (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3). This results in consumers\clients that keeps the state in the client side.
It works well for "rich" clients (mobile applications, etc...) that are built to save the state in their side. But... is it the same for web applications?
Is it good to have server side that expose itself in REST API, and the client side calls those REST API directly?
I see some pros, and some cons.
Pros:
Unified interface - our server side exposes it's API only in one way (REST), for the web application, and for general purposes API
Easy to expose services that we use internally to be used by external users.
Cons:
As said above - browsers are not built to save cache in the client side.
If I have the possibility to use state - why not? It improves performance (less back and forth), and ease on development.
Once we expose the internal API to customers, it restricts us to be very careful with the changes.
Any hints\recommendations?
This is an extremely common and powerful architecture, especially when coupled with heavy front-end clients like AngularJS or EmberJS. The state in that case is held on the client, and passed to the server only what's needed to complete whatever interaction (API call) they're making. It's really clean and scalable, in my experience.
A couple things you need to figure out / handle. Login & "session" info. In general, session stuff doesn't get done on a REST service ,so you have to account for that in various ways. Login is generally done by acquiring a token from the server (e.g. a JavaScript Web Token) and then passing that on further requests. You end up handling expiration on your own.
Using single REST server for all your applications will enable you reuse of the server.
Regarding sessions, in Kaltura we use login to return an encrypted string that holds the user id, his session type (admin/user) and the session expiration, once the client received that session string it will use it for any future API call.
This architecture enable us to save additional information on that session string without keeping a copy of it on the server.
For more API REST server guidelines, see my blog: http://restafar.com/create-new-rest-server/
I'm designing an architecture where the web interface is a client (developed using a front-end js framework) and all requests are routed to several webservices.
All communication will happen using standard HTTP responses and JSON entities.
Now I'm facing the authentication mechanism.
My service will, of course, have several users, and I need to restrict access to users' resources.
Users will 1) signin to the web client (/admin) and then 2) the client-side js will perform several AJAX requests on webservices on user behalf.
Should I create a persistent session between the client/server and then pass some reference alongside each request or authenticate each single request using a stateless approach? How could I authenticate the web-client requests for the current user without adding too much overhead or complexity to my system?
I'm looking at passport-local and passport-localapikey but it's not very clear to me if I should authorize my client or the user itself (meaning should I have only one pair of credentials for all users when performing web-service request or one pair per user?)
A simple example (explained I don't need to copy-paste code) would be very appreciated. At this stage I'd prefer the solution introducing less complexity but granting a good security in order to be able to set it up very quickly.
PS. I could also take into account creating a distinct service handling authentication in order to create a common API to be shared between client and server, but that seems a bit over-engineering to me.
Thanks,
If you're already using Express as a framework for Node.js, you can use it's built in session handling. It is capable of using any sort of session store including memory, redis, mongo, etc.
There's a good example here: http://blog.modulus.io/nodejs-and-express-sessions
I am currently working on a single-page web application. The web app will make calls to a REST-like API for authentication and data storage. We are currently in the middle of securing the application, and have worked out a strategy securing the site so only registered users can gain access. But one thing we also want to do is securing the API from others to write their own applications, or access it in any other way than through our web application. The problem from my view is that the API will be open for everybody and not only for my web application.
Anyone who knows how to do this, or who can point me in the right direction. Because right now, don't have a clue.
Considered using certificates and validation?
Your API should only be accessible, if the session of the client is authorized. That's pretty much anything you could do.
There are complex approaches like using client- and server-side encryption or something really basic: render a secret in your webpage that validates the user again on every request.
You could check the headers, where the original request comes from. And so on...
But as most of that is public in a users browser, anyone could read it and adopt it in a third party app.
So save yourself and the people that really want to do a third party app some time and provide a public API :)
Simplest way will be to use OAuth 2.0 ( supports both authentication and authorization) which you need.
Also ensure you secure the data on wire using TLS (HTTPS) and any of the options below
1. HTTP Digest
2. OAuthn 2.0
3. Certificates ( Shared secret)
Stick to HTTPS+Oauth2 for now.
You could lock down your you API to accept requests from known IP's. Also depending on how your network infrastructure is designed, your web application can sit in a DMZ and your API on an internal network accessible only by servers in your network, one of which will include your backend API (This article here info https://www.digitalocean.com/community/tutorials/5-common-server-setups-for-your-web-application has some tips). For better security, a secure network design in addition to an application security framework implementation like OAuth2 and HTTPS (mentioned above). For API's, I've found that resource based authorization works better than role based authorization. Lastly, constant review of your security setup is vital as things change all the time. A good approach to this is Threat Modelling described by OWASP here https://www.owasp.org/index.php/Application_Threat_Modeling
I need to develop/design Coldfusion Web Service which uses few object calls and functions.
What is good source of samples to develop in terms of OOP?
What is best way to secure the web service?
how to authenticate external/internal users, any sample?
FYI, This web service is going to be used by multiple department.
thanks
A
OOP examples are all over the web. I don't have any handy, so I'll skip that part, and go straight to authentication and security.
First, authentication. There are several possible answers depending on what kind of users you are authenticating. For example, if you are authenticating users connnecting via a 3rd parth tool -- like a desktop or phone app posting to Twitter -- I would say that OAuth is a good solution. There is a good library for both publishing and consuming OAuth integrations at oauth.riaforge.com. If you are looking for someting lighter weight, we used a simple token creation scheme for a webservice that was only consumed by partner services. Basically, the partner service sends what amounts to a username and password pair, a token is created with a "last used" timestamp, and every time the webservice interacts after that, we do a check against the token store.
Security is, similarly, very dependent on your end goals. However, there are a few basic principles I've always tried to follow. First, build your basic CFCs as you normally would for constructing your objects. Entry points should be public, helper functions private, etc. This includes building an object to handle whatever authntication model you choose. On top of that, build your public API. These should all simply be access functions. They are called by outside applications, call the security object, then call the appropriate objects and methods to achieve the goal of the call. This way, you never have to bake the security layer into your base functionality calls, but you also have an easy way to include security. Remember, a single API call does not have to reflect a single base call -- you can build more complex routines if needed.
So, to recap.
Authentication
OAuth
Temporary Token Generation
Security
private/public (not remote) base layer
private/public (not remote) authentication layer
remote API layer