Front end (user interfaces)Facilitating the user‘s interaction with the SandS services and processes

I. Mlakar, D. Ceric, A. LipajValladolid, 17/12/2014

Overal GoalSpecification, design, development and deployment of user environment allowing users the engagement and interaction of with the SandS system (services and processes within different Sands layers).

The goals and requirements are achieved via the developed and deployed highly modular SandS front-end web-application

Specific requirements Providing access to SandS system (user registration and profiles)

Providing access to SandS services regarding recipes, and appliances

Task description via natural language (including speech)

Full circle communication over secured bi-directional communication channels

Front end as gateway between user and SandS system

PHP based web appliaction core,

Dynamic resources, loaded as required,AjaxLoader + JavaScript Loader, via url: index.php?class=domain&function=module

Static resources, loaded only upon refresh (page load), HTTPLoader, via url: index.php?main_page=page_title

Using latest web-standards CSS3, WW3C WebSokcets, WW3C Web Speech API, HTML 5

Stand-alone WebSocket Server, Php server, hybi10 protocol,

Full Communication circle

No data is stored by front-end

Dislocation: DI and front end do not share system resources;

Client-Side: ajax connectors (load without refresh), HTML5 WebSockets client (WWW3C compliant), HTML 5 Web Speech Client (WWW3C compliant)

Bi-directionality: front-end and DI can both trigger communication

User‘s Registration and Sign-in Web forms (functions, resources and

protocols) for registration, sign and update of user profiles

Communication between web GUI (client) and core (server) request/response based via ajax, HTTP.

Communication between front_end core and DI request/response based via HTTPS JSON.

Front-end acting as mediator between web GUI and DI

Appliance management Dynamic web forms & resources, functions

and protocols that allow users to: list, engage/remove appliances to/from their location

DI is source of information, front-end only serves as a mediator.

Recipes And Evaluation Starts with user action which loads dynamical

resources Task description by either typing or speech

recognition client (extended from Google Speech Recognition AP)

NLP module: extract the relevant parameters (POS tagging/matching) match them against an appliance.

Ajaxloader: load and populate the appliance dependent task specification form

Recipes And Evaluation (continued) Translated into DI compatible format and

transmit to DI via DI connector

Load recipes detail form. Refine and/or Confirm

Send to DI as JSON (location, recipe_id, appliance_id).

Upon completion of the recipe users may also evaluate its final outcome.

The DI returns the best-matching recipe as a JSON encoded object

Messaging Communication between DI and

web GUI in triggered by DI.

DI-listener service enabling cross-domain interaction (domain restricted)

If message and origin are verified they are dispatched to designated user-front-ends (receivers)

COMPONENTS: javascript WebSockets client, PHP WebSocket server, PHP WebSocket client, DI-Listener web service

Protocol: WebSocket hybi10 protcol

PHP WebSocketClient transmits verified message to WebSocket Server (connect, send, disconnect) (IP restricted).

Security XSF attacks (page encryption): via encrypted sessions through security token.

Token is renewed at each load, stored as $_SESSION parameter and HTML element. Upon data/action submission both are checked by HTTPLoader or AjaxLoader.

XSS attacks (server-side data validation): via incoming data sanitation process.

HTML sanitation removing/escaping HTML tags including <script> tags, remove escape sequences (e.g. '//'),

URL sanitation removing sequences starting with http, document., $(, etc.

POST/GET parameter sanitation prior processing exclude POST/GET parameter-names/values that contain certain black-listed constants (e.g. 'GLOBALS', '_COOKIE', '_ENV', '_FILES', '_GET', '_POST',…)

Security (continued)

Content Security Policy: .htaccess files are used to protect against unwanted snooping, file/folder permissions are set to read (CHMOD 644 for files and 755 for folders), server management via encrypted connections (SFTP (SSH FTP) for FTP access and PuttySecure command line connections)

Front-end/DI communication: secured via HTTPS, by using OpenSSL and self-signed SSL certificates. All the data exchanged between the entities is also sanitized

DI/Front-end cross-domain communication: secured via domain restricted HTTP. Only If the origin is verified the appropriate headers are set.

WebSocket hybi10 protocol: The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. We also implemented additional IP/domain restriction for accessing the message distribution service.

Thank You for your attention!