Mobile App Development With CORs

Mobile App Development with CORs

The ability to build apps from your desktop or local server is a huge plus for developers using their own debug tools, test suites, etc. With our latest Version 1.0.4 release, we now support these use cases plus the ability to run apps from outside of your DSP and still enjoy the flexibility of our REST API.

Simply log in to your DSP and click on the System Config menu item on the left hand side. On the System Config screen you’ll see the CORS Access options. Setting * will allow you to work from your desktop or anywhere. You may also use your localhost server, or another DSP or remote server you wish to have access to your data or service. Having the allowed verbs checkboxes enforces another layer of access control by locking down the entire DSP to use only the verbs checked for CORS. A future release will have CORS Access specifiable per application.

To use CORS without logging in, you’ll also have to allow for Guest Access, and create a Role for guest user access. This way you can limit any guest access to only database tables or services you see fit.

If you’d like to pass authentication instead of having a guest role, consult our Swagger API docs here for the latest API call for logging in a user (see the /user/session POST request). That POST will return a session_id that you can pass as a new header called X-DreamFactory-Session-Token with all your future API requests. You will also need to include the API name you created with your application as X-DreamFactory-Application-Name if you haven’t already.

We’ve also added live data through a new publication / subscription framework.

We’re using Faye running on Node. Check here for the Faye documentation as well some good advice on security.

Need to see it working? Here’s a Plunker showing our Angular Todo Application using CORS and PubSub to talk to our demo server.

To see pub/sub working on it’s own, try this real time chat app on Plunker

Enjoy! And as always, if you have any questions, please contact us!

Dream Factory Services Platform

 DreamFactory Services Platform (DSP) was designed from the beginning to be a very secure way for an enterprise customer to host mobile applications. This blog post covers security benefits on the server side and at the client, and towards the end we discuss the advantages of our user roles and permissions system.

From the server side, you can install a DSP on your own cloud computer or data center. The DSP software package includes a complete LAMP Stack with PHP and a dedicated MySQL database that can be installed on any Linux virtual machine. This allows a company to use the same deployment and management practices for a DSP that they are already using for other applications. They can monitor usage, make backups, control cost, configure firewalls, and deploy applications with familiar tools and systems.

The open source nature of the DSP code base is also designed for security. An open source product has "many eyes" on the code base. We have signed up for third party security audits as well. DreamFactory Software has a team of engineers adding new features and looking for security problems on a regular basis. The latest version of the software is available from us at various cloud marketplaces. Since we are not hosting your application, there is no risk of DreamFactory losing your data. You do not need to worry about how we manage our data center, or how we keep your data separate from other customers.

There are aspects of the service architecture that also lend themselves to security. The service architecture has a single point of entry, so all service calls pass through this gateway. We have written the code in the latest version of PHP, the most widely used web programming framework in the world. The use of PHP helps with issues like buffer overrun attacks. The SQL interface completely decomposes and recomposes all query strings to prevent SQL injection attacks as well.

When a user signs on to a DSP they receive a session ID, which is securely managed as a browser cookie in an HTML5 application, or as a transient local variable in a native application. All network transactions are conducted over HTTPS, thus adding the security capabilities of SSL/TLS to standard HTTP communications. The DSP also implements cross-origin resource sharing (CORS) support and a white list that controls which domains can use the platform. This enables any website or domain to use the platform services if desired. By default CORS support is turned off and the services are only available from the originating host.

The DSP service interface enables automated or manual data synchronization with other databases or external partners as needed. A special user role could be created for the DSP that grants access only to required database objects. This allows an enterprise to construct a "data firewall" where sensitive data can be moved in or out of the DSP as needed. This data is exposed to mobile users, so even if the DSP database is compromised, there would be no way to gain access to the master database.

From the client side, each DSP comes with a complete and comprehensive services palette. This makes your mobile application somewhat future proof: there is no need to re-engineer the backend services for every new feature at the client. Our user management features are also very extensive. Single sign-on, user roles, guest users, open registration, password resets, email services, email templates, and password hashing are all carefully implemented.

One special security feature for users is that administrative updates to user roles and permissions are instantly reflected in the current session. For example, if a user is inactivated his session becomes invalid immediately. This provides a more secure environment for people entering or leaving the company and for lost devices or security breaches.

Each DSP also contains some high level security features for controlling which users see which data, services, and applications. This is very useful for segmenting the user base with different roles. The information that a sales or marketing person might see can be different from a project manager or company executive. This capability implements a higher level of security that prevents accidental data loss or disclosure of sensitive information.

Multiple applications can be hosted on a single DSP, and the administrator can create user roles to control which users see which applications. For example, a project manager would see a Gantt chart application, individual contributors would see a project calendar, and executives would see a report generator. The entire suite of visible applications can be adjusted based on appropriate user interest and role.

User roles also control what database objects are visible. This enables people to use the same application in different ways. For example, some people might see all data as read only, while others have the rights to create or delete data. The application can detect these permissions for a particular object at runtime and make various options available or inactive as needed. This capability also allows information to be hidden from certain groups. For example, individual sales people might not have access to salary information, while this data might be available for managers or executives.

Roles have the ability to enable or disable individual services as well. This controls access to 3rd party services that have been integrated with the DSP. One popular service is BLOB storage, these are binary documents stored locally on the DSP server or remotely in S3 or Azure. Each service can specify the external credentials to the service and also the access root of the folder tree. This enables each user role fine grained access to multiple document repositories.

The services have another useful capability. Various URL parameters and HTTP headers can be specified in the service object. This information is entered by an administrator and securely stored on the DSP server. Once the user enters their single sign-on credentials, they have controlled access to these external services as enabled by their user role. This capability removes the need for the client application at runtime to store any master credentials to external services. Another benefit of this architecture is that external services can be activated, deactivated, or redirected without changing client software.

Deploy,Manage and Monitor Your Own Applications

Deploy, manage, and monitor your own applications

Every DSP features a comprehensive and unified services palette. This approach reduces the need for rewriting and redeploying the services platform when new client side features are needed. We provide very carefully written features for user management, single sign-on, open registration, and guest accounts. If a user leaves their iPad on an airplane an administrator can instantly kill their session. We provide programmable CORs support so that your services can be exposed to foreign web sites, or you can run all the applications off the originating host depending on your security policies.
At a higher level, each DSP provides detailed administrative permissions for users by role. The administrator can control application visibility, CRUD access for SQL and noSQL data, CRUD access for BLOB storage by folder tree, and REST access to external services with credential hiding. This allows the admin to limit user information by role, further enhancing system security.

A Symfony Request in Action¶

Without diving into too much detail, here is this process in action. Suppose you want to add a /contact page to your Symfony application. First, start by adding an entry for /contact to your routing configuration file:

• YAML

  1 2 3 4

  # app/config/routing.yml contact: path: /contact defaults: { _controller: AcmeDemoBundle:Main:contact }

• XML
• PHP

This example uses YAML to define the routing configuration. Routing configuration can also be written in other formats such as XML or PHP.

When someone visits the /contact page, this route is matched, and the specified controller is executed. As you'll learn in the routing chapter, the AcmeDemoBundle:Main:contact string is a short syntax that points to a specific PHP method contactAction inside a class called MainController:

1 2 3 4 5 6 7 8 9 10 11 12

// src/Acme/DemoBundle/Controller/MainController.php namespace Acme\DemoBundle\Controller; use Symfony\Component\HttpFoundation\Response; class MainController { public function contactAction() { return new Response('<h1>Contact us!</h1>'); } }

In this very simple example, the controller simply creates a Response object with the HTML <h1>Contact us!</h1>. In the controller chapter, you'll learn how a controller can render templates, allowing your "presentation" code (i.e. anything that actually writes out HTML) to live in a separate template file. This frees up the controller to worry only about the hard stuff: interacting with the database, handling submitted data, or sending email messages.

Symfony2: Build your App, not your Tools.¶

You now know that the goal of any app is to interpret each incoming request and create an appropriate response. As an application grows, it becomes more difficult to keep your code organized and maintainable. Invariably, the same complex tasks keep coming up over and over again: persisting things to the database, rendering and reusing templates, handling form submissions, sending emails, validating user input and handling security.
The good news is that none of these problems is unique. Symfony provides a framework full of tools that allow you to build your application, not your tools. With Symfony2, nothing is imposed on you: you're free to use the full Symfony framework, or just one piece of Symfony all by itself.

Standalone Tools: The Symfony2 Components¶

So what is Symfony2? First, Symfony2 is a collection of over twenty independent libraries that can be used inside any PHP project. These libraries, called the Symfony2 Components, contain something useful for almost any situation, regardless of how your project is developed. To name a few:

• HttpFoundation - Contains the Request and Response classes, as well as other classes for handling sessions and file uploads;
• Routing - Powerful and fast routing system that allows you to map a specific URI (e.g. /contact) to some information about how that request should be handled (e.g. execute the contactAction() method);
• Form - A full-featured and flexible framework for creating forms and handling form submissions;
• Validator - A system for creating rules about data and then validating whether or not user-submitted data follows those rules;
• ClassLoader - An autoloading library that allows PHP classes to be used without needing to manually require the files containing those classes;
• Templating - A toolkit for rendering templates, handling template inheritance (i.e. a template is decorated with a layout) and performing other common template tasks;
• Security - A powerful library for handling all types of security inside an application;
• Translation A framework for translating strings in your application.

Each and every one of these components is decoupled and can be used in any PHP project, regardless of whether or not you use the Symfony2 fram

The Full Solution: The Symfony2 Framework¶

So then, what is the Symfony2 Framework? The Symfony2 Framework is a PHP library that accomplishes two distinct tasks:

1. Provides a selection of components (i.e. the Symfony2 Components) and third-party libraries (e.g. Swift Mailer for sending emails);
2. Provides sensible configuration and a "glue" library that ties all of these pieces together.

The goal of the framework is to integrate many independent tools in order to provide a consistent experience for the developer. Even the framework itself is a Symfony2 bundle (i.e. a plugin) that can be configured or replaced entirely.
Symfony2 provides a powerful set of tools for rapidly developing web applications without imposing on your application. Normal users can quickly start development by using a Symfony2 distribution, which provides a project skeleton with sensible defaults. For more advanced users, the sky is the limit.

ework. Every part is made to be used if needed and replaced when necessary.

The Symfony Application Flow¶

When you let Symfony handle each request, life is much easier. Symfony follows the same simple pattern for every request:

Incoming requests are interpreted by the routing and passed to controller functions that return Response objects.

Each "page" of your site is defined in a routing configuration file that maps different URLs to different PHP functions. The job of each PHP function, called a controller, is to use information from the request - along with many other tools Symfony makes available - to create and return a Response object. In other words, the controller is where your code goes: it's where you interpret the request and create a response.t's that easy! To review:

• Each request executes a front controller file;
• The routing system determines which PHP function should be executed based on information from the request and routing configuration you've created;
• The correct PHP function is executed, where your code creates and returns the appropriate Response object.

The Journey from the Request to the Response¶

Like HTTP itself, the Request and Response objects are pretty simple. The hard part of building an application is writing what comes in between. In other words, the real work comes in writing the code that interprets the request information and creates the response.
Your application probably does many things, like sending emails, handling form submissions, saving things to a database, rendering HTML pages and protecting content with security. How can you manage all of this and still keep your code organized and maintainable?

The Front Controller¶

Traditionally, applications were built so that each "page" of a site was its own physical file:

1 2 3

index.php contact.php blog.php

There are several problems with this approach, including the inflexibility of the URLs (what if you wanted to change blog.php to news.php without breaking all of your links?) and the fact that each file must manually include some set of core files so that security, database connections and the "look" of the site can remain consistent.
A much better solution is to use a front controller: a single PHP file that handles every request coming into your application. For example:

/index.php	executes index.php
/index.php/contact	executes index.phpNow, every request is handled exactly the same way. Instead of individual URLs executing different PHP files, the front controller is always executed, and the routing of different URLs to different parts of your application is done internally. This solves both problems with the original approach. Almost all modern web apps do this - including apps like WordPress. Stay Organized¶
/index.php/blog	executes index.php

Using Apache's mod_rewrite (or equivalent with other web servers), the URLs can easily be cleaned up to be just /, /contact and /blog.

Symfony was created to solve these problems so that you don't have to.
Inside your front controller, you have to figure out which code should be executed and what the content to return should be. To figure this out, you'll need to check the incoming URI and execute different parts of your code depending on that value. This can get ugly quickly:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// index.php use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\Response; $request = Request::createFromGlobals(); $path = $request->getPathInfo(); // the URI path being requested if (in_array($path, array('', '/'))) { $response = new Response('Welcome to the homepage.'); } elseif ($path == '/contact') { $response = new Response('Contact us'); } else { $response = new Response('Page not found.', Response::HTTP_NOT_FOUND); } $response->send();

Solving this problem can be difficult. Fortunately it's exactly what Symfony is designed to do.

Symfony also provides a Response class: a simple PHP representation of an HTTP response message. This allows your application to use an object-oriented interface to construct the response that needs to be returned to the client:

1 2 3 4 5 6 7 8 9

use Symfony\Component\HttpFoundation\Response; $response = new Response(); $response->setContent('<html><body><h1>Hello world!</h1></body></html>'); $response->setStatusCode(Response::HTTP_OK); $response->headers->set('Content-Type', 'text/html'); // prints the HTTP headers followed by the content $response->send();

New in version 2.4: Support for HTTP status code constants was added in Symfony 2.4.

If Symfony offered nothing else, you would already have a toolkit for easily accessing request information and an object-oriented interface for creating the response. Even as you learn the many powerful features in Symfony, keep in mind that the goal of your application is always to interpret a request and create the appropriate response based on your application logic.

The Request and Response classes are part of a standalone component included with Symfony called HttpFoundation. This component can be used entirely independently of Symfony and also provides classes for handling sessions and file uploads.