So we're developing a web application in Symfony2 (brief editorial: Symfony2 is freaking awesome) along the lines of an SOA. All data is farted back and forth between our jQuery powered frontend and the Symfony2 backend formatted a la JSON, and therein lies the rub.
Symfony2 provides for a robust security system, but it seems to hinge on the "Security Layer" intercepting form submissions and using the form-encoded POST data to process an authentication attempt. This is problematic for our application because we use JSON exclusively. From where I'm standing, using JSON for every single request and response except authentication is... the sheet of the bool, frankly. Bad smell, bad juju, whatever you call it.
Now, Symfony2 allows for the creation of event listeners that hook into a series of events related to the lifecycle of a request and the consumate response. We use one of these hooks to decode the JSON that comes in with every POST request so that the relevant controller only ever has to worry about working directly with a php array and not do any decoding or de-serializing or whatever.
So the crux of our issue is that the "Security Layer" expects that form-encoded POST data that it gets from a form submission (generally on a page that the backend served in the first place). We're set up to feed it a PHP array created from JSONified data. So what do? Should we:
Create a custom authentication service that is built to deal with an array made from le JSON?
Tweak our request hook to check the target uri of each request and subsequently massage the request's JSON into the form-encoded string the "Security Layer" expects?
Tweak the "Security Layer" so that it can work the the JSON turned php array?
It's fairly simple to create your own authentication provider. You can follow this cookbook article and modify it slightly to handle your JSON request instead of the WSSE used in that example.
Related
We are developing a chatbot to handle internal and external processes for a local authority. We are trying to display contact information for a particular service from our api endpoint. The HTTP request is successful and delivers, in part, exactly what we want but there's still some unnecessary noise we can't exclude.
We specifically just want the text out of the response ("Response").
Logically, it was thought all we need to do is drill down into ${dialog.api_response.content.Response} but that fails the HTTP request and ${x.content} returns successful but includes Tags, response and the fields within 1.
Is there something simple we've missed using composer to access what we're after or do we need to change the way our endpoint is responding 2? Unfortunately the MS documentation for FrwrkComp is lacking to say the very least.
n.b. The response is currently set up as a (syntactically) SSML response, this is just a test case using an existing resource.
Response in the Emulator
Snippet from FwrkComp
Turns out it was the first thing I tried just syntactically correct. For the case of the code given it was as simple as:
${dialog.api_response.content[0].Response}
So i want to develop a simple web application, which will basically be a basic form which on submission will allow to make an external api request. So are there any application designers that can allow to do that with minimalistic code. Appian for example has an interface/application designer that lets you drag and drop a UI interface and build a workflow, make api calls externally or to a database. So like that are there any other apps that allow to do something similar (make api calls/build ui easily/store in databse)? Any other suggestions are also welcome!
It heavily depends on the API as well as the kind of task you´re trying to achieve.
Here´s just a few examples and considerations. (All the below supposes that we´re talking about Web-Based APIs).
If the API requires authentication of some sort and the user authenticates himself: A simple HTTP file with JavaScript to send the request will do the job
If the API requires authentication but you authenticate for all the users: You will need a backend application that does the API request since you need something secure where you can put your Auth-Details for the API. Classic PHP or NodeJS in combination with a served HTTP file for the form itself would work without any JavaScript (depends on the API definitions)
If the API does not require authentication maybe a simple HTML form would work
If you want to write to a database you can have a look at something like https://directus.io/. They allow building a database with a UI and they automatically generate a Web-API which you can then feed by your forms. If the end-user is known to you Directus actually allows users to log in and fill the database with forms that you can visually design but this is rather for employees entering data into an internal database than customers submitting their contact data to you
From my personal experience, all the UI-Tools that promise to integrate with REST APIs make it really hard to do so since every API is different and there is no real standard for them.
Is it possible to validate if an HTTP request originated from the client as GET, but was intercepted in between and converted to POST, or vice versa?
It is one of the security validations that is required as part of the project I am working on, but not getting enough clue about it. One of the way we thought of using as validation is to check if it is a GET request with a body than it could be POST. But that is just one case. Also if a POST is changed to GET by forging the request, I believe the data in the body can also be removed.
edit: Added more information about application and the intercepter
It is a regular Java web application developed using Struts with JSPs on the client side. The request from the web pages are being intercepted using Burp Suit Proxy to change the payload in the request.
I have developed a front-end interface using Aja(AngularJS) and HTML5. Right now, I send an HTTP get request to my backend server which returns some data based on the GET parameters.
Since the URL is exposed in the Javascript file, I believe anyone could just use the URL to create there own API to fetch the data. How can I prevent such things ?
One way I could think of is that now instead of directly sending the request to the backend server, an application server could be used (hosting the HTML as well). The Ajax request would then be sent to this server (PHP script ?) which would in turn forward the request to the backend server and return the result to the UI. To prevent 3rd party services, I can disable cross origin requests on my application server.
Is this the correct way to solve my problem or are there better ways to do this? I am concerned that this would unnecessarily create another hop (internal though) for requests.
Note: The backend is running Apache Tomcat
In APIs that are not open to the world the user has to authenticate first in order to use it, see for example https://stripe.com/docs/api#authentication or http://dev.maxmind.com/geoip/geoip2/web-services/ -> Authorization
(I'm not familiar to RESTFul, please correct me if my concept is wrong)
In RESTFul architecture, we map every action to an URL. If I click "post a article", may it's actually URL http://example.com/ and some data action=post&content=blahblah.
If I want to post, but not refresh the whole web page, I can use javascript's XMLHTTPRequest. I post it and then get it's content and insert it to a div in my page. These action is all asynchronous.
Then I know there is something named WebSocket and it's wrapper socket.io. It use "message" to communicate between client and server. When I click "post" the client just call socket.send(data) and wait for server's client.send(data). It's magical. But how about URL?
It's possible to use the two model both without repeating myself? In other word, every action has it's URL, and some of them can interact with user real-timely(by socket.io?)
Moreover, should I do this? In a very interactive web program(ex. games), the RESTFul is still meaningful?
You're defining a handler for actions that map to REST over http. POST and GET generally refer to update and query over an entity. There's absolutely no reason you can't just define a handler for generic versions of these CRUD operations that can be used in both contexts. The way I generally do this is by introducing the concept of a 'route' to the real-time transport, and mapping those back to the same CRUD handlers.
You have a session, you can impose the same ACL, etc.
+---------------------------------+
| |
| BROWSER |
| |
+--+--^-------------------+---^---+
| | | |
| | | |
+--v--+---+ +--v---+---+
| | | |
| HTTP | | SOCKET.IO|
+--+---^--+ +--+---^---+
| | | |
+--v---+------------------v---+---+
| |
| ROUTING/PUBSUB |
+-+--^-------+--^-------+--^------+
| | | | | |
+-v--+--+ +-v--+--+ +-v--+-+
| | | | | |
| USERS | | ITEMS | |ETC |
+-------+ +-------+ +------+
ENTITY CRUD HANDLERS
I posted this on my blog recently:
Designing a CRUD API for WebSockets
When building Weld, we are using both REST and WebSockets (Socket.io). Three observations on WebSockets:
Since WebSockets are so free-form, you can name events how you want but it will eventually be impossible to debug.
WebSockets don’t have the request/response form of HTTP so sometimes it can be difficult to tell where an event is coming from, or going to.
It would be nice if the WebSockets could fit into the existing MVC structure in the app, preferably using the same controllers as the REST API.
My solution:
I have two routing files on my server: routes-rest.js and routes-sockets.js
My events look like this example: "AppServer/user/create".
I use forward slashes (“/”) to make the events look like routing paths.
The first string is the target (~”host name” if this actually was a path).
The second string is the model.
The third string is the CRUD verb: i.e. create, read, update, delete.