Blog Archives

Working around untrusted certificate errors in Express JS


A few very common fatal errors thrown by the request module for express while trying to access data from self-signed web servers are Error: DEPTH_ZERO_SELF_SIGNED_CERT and UNABLE_TO_VERIFY_LEAF_SIGNATURE

This is because of https://github.com/nodejs/node-v0.x-archive/pull/4023 which mandates NodeJS to validate a server’s certificate by default, which needless to say is how things should be in a production environment.

However, more often than none we tend to use self-signed SSL certificates in our development environments or even within internal networks.

Thankfully for such brain-wracking moments, two particular flags come to our rescue. Enter strictSSL and rejectUnauthorized. The way I personally like to use these flags, is to set defaults within my development environments as follows to bypass SSL validation hence, saving the day! 🙂

var request = require('request').defaults({
    strictSSL: false,
    rejectUnauthorized: false
 });

Please do note, that I do not recommend that you ever try this on your production systems without understanding the true implications of what disabling strictSSL and rejectUnauthorized means for you node server. By disabling these, you are essentially telling your server to skip validation of the requested server’s identity, which leaves your application in quite a vulnerable position.

Advertisements

Porting WordPress for WebOS to Firefox OS


Introduction to WordPress for WebOS

WordPress for WebOS was a web app which used the WebOS platform’s innovative “Cards” feature, which allowed users to quickly switch between managing, editing, and browsing content. WordPress for WebOS was built around Sliding Panels that enables users to easily switch between creating, editing and managing content.

The app allowed working with both WordPress.com and self-hosted blogs, notified users of new pending comments and had WordPress Stats built in using Jetpack for self-hosted blogs apart from using Sliding Panels to quickly move between new and existing content. It was also the first Open Source WordPress app to have a full visual editor, which made it easier than ever to format text, add links or embed media into a user’s posts and pages.

Recycling the Code

Even though the project is currently dormant, however, it’s repository still has the potential to serve as a precursor to future Web apps for WordPress, by providing a neat base model for future application developers.

The WebOS app was written using the Enyo.js JavaScript framework, which gives the application the flexibility of cross platform development using the same framework, as well as being extensible for future iterations due to Enyo’s modular design. This provides developers with the opportunity of reusing the existing code of the WebOS application for developing Web apps for newer platforms.

The rising popularity of web based applications along with significant advancements in the Enyo Framework also makes it easier to port the existing code for the web application to newer platforms such as Firefox OS.

Desired Outcomes from the Project during GSoC

  1. Upgrade the existing Enyo 1.0 based code to the Enyo 2.2 framework.
  2. Rewrite platform specific code such as app manifest and device APIs.
  3. Basic UI redesign to a responsive layout so as to support smaller device resolutions.

Aspects of Porting

There are two major aspects which need to be taken into consideration while rebuilding/porting the existing app on a Firefox OS:-

  1. The WebOS app was written using the Enyo.js 1.0 framework. This needs to be first updated to Enyo 2.2 framework for porting the app to Firefox OS.
  2. Given the fact that the WebOS app was last updated almost a year ago, the app itself needs some rework to get it up-to-date and at par with the latest WordPress mobile apps on other platforms like Android the latest facelift.

Development Methodology

A structured three step approach is proposed for the actual coding cycle as follows:-

  1. Identify the key differences between the architecture of an app developed on WebOS and that of one developed for Firefox OS.
  2. Based upon these observations isolate platform specific code and app specific code.
  3. From here on the actual implementation process begins and is categorized into two categories:-
    • Rewrite platform specific code such as app manifests and Web API interactions.
    • Modify and upgrade the base Enyo 1.0 code to Enyo 2.2, to include newer functionalities to bring the existing code base at par with the WordPress apps for other platforms such as Android as well as to support advanced features on Firefox OS for the Enyo 2.2 framework. This would include some basic UI redesign to cope with smaller screen resolutions on mobile handsets.

Bonus Objectives

Once the basic code upgradation is complete, the focus can be shifted towards added features based on time availability post completion of primary development objectives. Two major desirable additions would be as follows:-

  • UI redesign: Since the WordPress for WebOS app was primarily designed for use in tablets with comparatively higher screen resolutions, the application UI layout needs to be upgraded to a more responsive interface layout to support a variety of screen resolutions most of which are comparatively lower than that of tablets to extend support to smaller devices. A possible layout for lower resolutions can include an arrow button like the Android app to bring out the admin sidebar.
    [Note: While the project’s scope for GSoC would include some basic UI adjustments, further improvements to the UI would be a long term goal traversing the completion of the GSoC period.]
  • l10n: Localization is a bonus target which can be looked upon if time permits after the primary application development process. Currently the WebOS app supports 11 locales by itself by using JSON based l10n resources identified by the Enyo framework. This section would require a considerable looking into to improve the quality and performance of localized content for the Firefox OS app. The primary objective here would be to extend the current localization resources, however an alternate implementation can be done by using Gaia’s webl10n library if it shows a substantial performance (response/rendering time for localized Glyphs) and quality improvements over Enyo’s base l10n resource implementation.
    [Note: This is not a milestone for the project itself, however this is a support feature that needs to be kept in mind for future improvements.]
%d bloggers like this: