Archive for February, 2014

Welcome to Friday and the last day before the study break.

This week was really exhausted one, all the midterms and assignment deadline made it even more nervous. Anyways, my work in Open Source World holds me in excited mood. 🙂

For this release I completed a lot of new for me kind of bugs and also made a great progress with the final CSP implementation into Webmaker and components. A little bit later in this post about it.

The other thing is that I found some really useful articles related to the Content Security Policy:

  • Compatibility table for support of Content Security Policy in desktop and mobile browsers -> look here
  • Content Security Policy on Mozilla Hacks -> look here and Mozilla Wiki -> here
  • A lot more on CSP v1.1 (new version 🙂 ) standard on w3 -> look here

Another great news!

Content Security Policy has just recently updated to version 1.1 (February 11th, 2014), which has some new features, which will be really useful to use for my future implementation it to the mozilla components.

  • nonce — random sequence of symbols that you send through header;
  • If there is an unsafe-inline and nonce, then nonce turns off unsafe-inline;
  • only those inline scripts work which have attribute nonce with the same value as in the header
    var hood = require("hood");
    //declaring new attribute in header
    module.exports.addCSP = function(options) {
      return hood.csp({
        headers: [
        policy: {
          'default-src': [
          'script-src': [
            "nonce-eef8264c4994bf6409c51ac7c9614446" //'nonce' has value with random symbols
    <script type="text/javascript">
      alert("BLOCKED, because no 'nonce' attribute");
    <script nonce="22168992a8d57a5d3a64ca73bb9fc669">
      alert("BLOCKED, because 'nonce' value doesn't equal to one written in the Policy");
         //'nonce' is equal to one in the header
    <script nonce="eef8264c4994bf6409c51ac7c9614446">       
      alert("VALID, because 'nonce' attribute is equal to one in the Policy");
    <!-- VALID, because there is a 'script-src' with '' -->
    <script src=""></script>
    <!-- BLOCKED, because 'nonce' attribute is different -->
    <script nonce="22168992a8d57a5d3a64ca73bb9fc669" src=""></script>
    <!-- VALID, because 'nonce' attribute is the valid, even then the is not in script-src -->
    <script nonce="eef8264c4994bf6409c51ac7c9614446" src=""></script>
  • Specifying policy with metatag
  • Javascript API for getting and checking policies
  • DOM event about policy violation
  • New attributes: form-action, plugin-types
  • I will talk to Jon and Dave about these new features and how they can benefit.

Also I am thinking of implementing report-uri attribute to mozilla’s CSP, so that we will be getting all the information related to the policies violation and for easy check on the policy rules

Here is a small example of report-uri implementation

//inside CSP header declare report-uri
module.exports.addCSP = function(options) {
  return hood.csp({
    headers: [
    policy: {
      'default-src': [
      'script-src': [
      'report-uri': [  //report-uri attribute
        "/pathToFile/csp.jsx"  //path to report json file

And here is hoe the report-uri file looks like

    "csp-report": {
        "document-uri": "",
        "referrer": "",
        "violated-directive": "script-src 
        "original-policy": " all policies specified here ",
        "blocked-uri": " blocked urls will be here "

Pretty neat thing this CSP 🙂

The only one thing stops this implementation is this bug -> Mozilla CSP report-uri bug which is kind a problem. I would contact jbuck to get some info on that.

Lets get back to my bugs for this release. So I moved as close as possible to implement CSP on webmaker. Due to Jon Buckley’s vacation (hope is doing great 🙂 ), some of my bugs are on review stage, but this is not a problem at all, I have a lot of stuff to do for my next release. These are the bugs I fixed for this release:

  • Moving inline script to separate file -> bug 973120 Fixed and Landed,PR here
  • Remove inline script for quick-linking to a tag -> bug 973116 Fixed and Landed,PR here
  • Move google analytics snippet into a separate JS file -> bug 973119 Fixed and Landed,PR here
  • Move JS error tracking snippet -> bug 973112 On review and PR here
  • Starting point on CSP for Xray Goggles, adding ‘hood’ module, adding CSP to middleware.js and implementing it in app.’s commits -> here
  • Also I filed a bug for Xray Goggles -> here, which is related to future CSP as well. The bug is still not confirmed, but anyways, I am suggesting to find other related issues in Goggles, how we did with Webmaker, to make the whole CSP Implementation much more easier and straight forward.

This is pretty much it for this release.
Have a great weekend!


Good day!
Open Source Development is becoming more and more familiar to me. Thanks CDOT for that. 🙂
Lets get closer to my bugs for this release and what should be done by Friday, Feb 21st. During the last week I was assigned to some new bugs which are related to CSP implementation into Webmaker components(thimble, goggles, webmaker):

  • Moving inline script to separate file -> bug 973120
  • Remove inline script for quick-linking to a tag -> bug 973116 Fixed
  • Move google analytics snippet into a separate JS file -> bug 973119
  • Move JS error tracking snippet -> bug 973112

All these bugs should be resolved first, before I can start final CSP implementation into the webmaker components. That is why, once they will be resolved, I will start to work on this bugs:

Content Security Policy is a great feature that would be really beneficial to webmaker and maybe after could be implemented to other Open Source Projects. It is a standard and could be written in different languages. One more thing that I learned during my bug fixes is a data-* attribute that helps transporting variables from html file into separate .js file.
This is how it works:

In data-atr.html file

<!DOCTYPE html>
    <title>Testing Data-* attributes</title>
    <!--passing data here-->
    <!--you can pass any kind of data through the data-* attributes, really useful-->
    <script id="your-id" src="pathToFile.js" 
      data-anyVariable="I like to code"
      data-anyOtherVariable="That is how it works">

In pathToFile.js file

var first = document.getElementById("your-id").getAttribute("data-anyVariable");
var second = document.getElementById("your-id").getAttribute("data-anyOtherVariable");

//Now you can use variables from html
alert(first + "\n" + second);

I found a really good explanation and example here ->
See you later:)

Hello Friday!

It’s time to summarize my work for the last two weeks. My first part I described in my previous post, so I would like to give you new information on the bugs and features I am working on right now.
Honestly, I am becoming more and more supportive to the Open Source Development. 🙂

I continue my contribution to the CSP Implementation to the different webmaker components. Right now I’m helping with popcorn. The whole CSP feature was separated into the small bugs, to let the process goes more efficiently and easy to follow. I fixed these two bugs:

  • bug 965048 – changing Soundcloud protocols to https://
  • bug 965049 – changing Vimeo protocols to https://

This is a step to the CSP Implementation, I would be happy to be involved to the more difficult and more back end programming, either with CSP or pre CSP stages.

The other type of work I am working on, and right now waiting for the review and more info is the component. I found a bug on bugzilla -> bug 963305, that is saying that there should be a user profile page (e.g. shown inside the user profile page. I decided to implement that. So the steps are:

  • Add HTML so the user can see his/her profile page in text – Done
  • Set the profile link in account.js file, that adds a new class – Done
  • Create a new environmental variable and parse it to the login page – Done, waiting for review
    • Create a new var in .env and env.sample files
    • Parse var into page with nodejs’s habitat module -> more info on habitat module here and express module, locals method -> more info here. Basically requiring habitat module gives you access to the varName.get(exportedVarName);, method that parses the exported variable.
          AUDIENCE: env.get("AUDIENCE"),
          profile: env.get("PROFILE"),
          supportedLanguages: i18n.getLanguages(),
          listDropdownLang: i18n.getSupportLanguages()
        });//exported variable 'PROFILE' assigned to variable 'profile'
    • Assign parsed variable to the user profile page in text:
      $( ".wm-page").text( username + "{{ profile }}" );

      – where ‘profile’ is a parsed variable.

    • Show it on the profile page:
      <li><span class="field-label">{{ gettext('My profile') }}</span><span class="wm-page"></span></li>

Looking for more bugs and more involvement into Open Source Environment.
See you.

Welcome to Friday evening…The last day of January outside, and winter is still here…I am getting more and more familiar with OpenSource Development and Mozilla in particular, however much more ahead and much much more I want to get… Working on Content Security Policy (CSP) is still in the process, however some issues are still not resolved.

This week I learned a lot of new for me, in particular:

  • How to use bower. (My job was to package nav.css with bower)

    Bower is a package manager for the web. It offers a generic, unopinionated solution to the problem of front-end package management, while exposing the package dependency model via an API that can be consumed by a more opinionated build stack. There are no system wide dependencies, no dependencies are shared between different apps, and the dependency tree is flat. From ->

    • First step is to create a repo on Github with a nav.css file
    • Next is to give a tag to a commit. (Learned some about Versions as well) Also this article helps with version understanding -> About Versions Thanks Jon Buckley for the link.
    • After that, you have to edit bower.json file inside all required webmaker components, which are using nav.css
    • Change path inside html pages, which are using nav.css file, to bower package path
    • Check all the pages and test
    • If something wrong, or nav.css file is damaged, you will have to change it in your repo (change the version as well) and change version inside bower.json file as well, to make changes happen.
    • Commit all the updates and do the PR.
  • Squashing commits – basically, it is when you are fixing some bug and committing small things about the same problem. After such work, you end up with 10 commits, which are useless. Here is where commit squashing take place. It puts many commits into one. Here is how it works: git rebase -i HEAD~3 This example will squash last 3 commits. After calling this command Text Editor will be opened (vim, sublime, etc.) and you will have to specify some options. You can find good tutorial here -> Squashing commits
  • Looked through Google Map API. Started my own example of it.

Right now thinking of getting a bug more concerning js backend..Hopefully will find one soon. Also my thanks to Jon Buckley for his help and patience 🙂

See you..