hcoelho.com

my blog

Title only : Full post

Recoving data from Addthis

:

Long story short, Addthis is a tool that allows you to easily add social media follow and share buttons to your website; we wanted to detect when a user shares a page, follows our page, or comes from a post that was shared on social media. Luckily, Addthis offers a simple API to detect these actions: when you include Addthis in your page, it makes a global object in the window called "addthis", which can be accessed by any other script in the page.

Detecting shares

To detect shares, we listen for an event called "addthis.menu.share" on the addthis object, then we can recover the service (social media) the resource was shared on:

addthis.addEventListener('addthis.menu.share', service => {
    const serviceName = service.data.service;
    console.log(serviceName); // facebook, twitter, etc...
});

Detecting follows

This option was not described in the API, but to my surprise, it actually works!

To detect follows, we listen for an event called "addthis.menu.follow" on the addthis object, just like for shares:

addthis.addEventListener('addthis.menu.follow', service => {
    const serviceName = service.data.service;
    console.log(serviceName); // facebook, twitter, etc...
});

Detecting number of shares of a service

To detect the number of shares in one or more services, you can call the function addthis.sharecounters.getShareCounts, pass an array of strings with the names of the services, and a callback that will receive an array of objects (one for every service you passed) with the number of shares. Say you want the number of shares on 'facebook':

addthis.addthis.sharecounters.getShareCounts(['facebook'], shares => {
    const sharesNo = shares[0].count;
    console.log(sharesNo);
});

Detecting if the user is coming from a shared post

It is useful to know when a user is coming from a post that was shared on facebook, twitter, etc. To get this information, Addthis inserts a URL fragment similar to this one:

http://example.com/blog#AHb4gs1hwck.facebook

Where the last bit of the fragment is the name of the service.

Addthis offers another event listener to recover this information, and this is where things get weird: I really don't see why this should be an event, because it is not an event - it is a "constant" information that should be able to be recovered any time, just like the number of shares. Because of this, we decided that we would parse the information from the url ourselves with a snippet similar to this one:

const url = window.location.href;
const regex = /.+#.+\.([a-zA-Z0-9_-]+)$/;
const result = regex.exec(url);
const serviceName = result[1];

This Regular Expression extracts the last bit of the fragment.



Overall, it is a very easy API, but the documentation could be a lot better and some pieces don't seem to fit together well.

cdot addthis shell bash 

Making shell scripts for deployment on AWS

:

Long gone are the days which deploying a website meant simply uploading .php files via FTP to your favourite web host. Now, if you are using any of those new, fancy technologies such as Node.js, Docker, and Cloud Hosting, you will have to perform several tasks in order to put the new version of your website online. Luckily, these services often allow you to do this via command line - not that it makes things easier at first glance, but it allows us to automate these processes. Our application is built on Node.js, it uses 3 Docker containers (2 APIs and 1 Database), and they are all deployed as a single task on Amazon Web Services (AWS); in this post I am going to describe how our deployment currently done, and what I did to automate it.


1- Logging in

To make any changes on AWS, you first have to log in. For this, we use the command that they provided us:

aws ecr get-login

Run this in the command line and it will give you another command; copy and paste the new command, and you are logged in. Or, if you want to be lazy:

aws ecr get-login | bash -e


2- Building, tagging, and pushing the container repositories

For these tasks, AWS provides you the required commands - when you use their website to upload a new version of the repository, they will tell you to run commands similar to these:

docker build -t <name> . &&
docker tag <name>:latest ____________.dkr.ecr._________.amazonaws.com/<name>:latest  &&
docker push ____________.dkr.ecr._________.amazonaws.com/<name>:latest


3- Stopping the current tasks

For the new containers to be run, the current tasks will have to be stopped. There is no quick and easy way to do this, as far as I know, so this is what I did:

  • List all the current tasks running on the cluster
    aws ecs list-tasks --cluster default
    

This will give you a list of tasks in JSON format, like this:

{
    "taskArns": [
        "task1",
        "task2",
        "task3"
    ]
}
  • Extract the tasks

For extracting the tasks, I piped the output into two seds:

sed '/\([{}].*\|.*taskArns.*\| *]\)/d' | sed 's/ *"\([^"]*\).*/\1/'

This is the result:

task1
task2
task3
  • For every line (task), stop the task with that name

Now we can use the command provided by AWS: aws ecs stop-task. I just used a for-loop to go through every line and stop the task:

while read -r task; do aws ecs stop-task --cluster default --task $task; done


4- Wrapping up

With the basic pieces done, I wrapped them in a shell script:

#!/bin/bash


###############################################################################
# LOGGING IN
###############################################################################
login()
{
    aws ecr get-login | bash -e

    deployDatabase
}


###############################################################################
# DEPLOYING DATABASE
###############################################################################
deployDatabase()
{

    echo -e "Ready to deploy the database? (Y/n)"
    read shouldDeploy

    if [ "$shouldDeploy" = "Y" ];then
        echo -e "Deploying the database\n"
        cd ../database &&
        docker build -t <name> . &&
        docker tag <name>:latest ____________.dkr.ecr._________.amazonaws.com/<name>:latest  &&
        docker push ____________.dkr.ecr._________.amazonaws.com/<name>:latest
    fi

    deployAPI1
}


###############################################################################
# DEPLOYING API 1
###############################################################################
deployAPI1()
{

    echo -e "Ready to deploy API 1? (Y/n)"
    read shouldDeploy

    if [ "$shouldDeploy" = "Y" ];then
        echo -e "Deploying API 1\n"
        cd ../api1 &&
        docker build -t <name> . &&
        docker tag <name>:latest ____________.dkr.ecr._________.amazonaws.com/<name>:latest &&
        docker push ____________.dkr.ecr._________.amazonaws.com/<name>:latest
    fi

    deployAPI2
}


###############################################################################
# DEPLOYING API 2
###############################################################################
deployAPI2()
{

    echo -e "Ready to deploy API 2? (Y/n)"
    read shouldDeploy

    if [ "$shouldDeploy" = "Y" ];then
        echo -e "Deploying API 2\n"
        cd ../api2 &&
        docker build -t <name> . &&
        docker tag <name>:latest ____________.dkr.ecr._________.amazonaws.com/<name>:latest &&
        docker push ____________.dkr.ecr._________.amazonaws.com/<name>:latest
    fi

    stopTasks
}


###############################################################################
# STOPPING CURRENT TASKS
###############################################################################
stopTasks()
{
    echo -e "Stop the current tasks? (Y/n)"
    read shouldDeploy

    if [ "$shouldDeploy" = "Y" ];then
        aws ecs list-tasks --cluster default | \
        sed '/\([{}].*\|.*taskArns.*\| *]\)/d' | sed 's/ *"\([^"]*\).*/\1/' | \
        while read -r task; do aws ecs stop-task --cluster default --task $task; done
    fi

    echo -e "Done"
}


###############################################################################
# STARTING POINT
###############################################################################
clear

echo -e "Are you sure you want to deploy on AWS? This cannot be undone. (Y/n)"
read shouldDeploy

if [ "$shouldDeploy" = "Y" ];then
    login
else
    echo "Not deployed"
fi

cdot aws shell linux 

Tonight on Animal Planet: SSL Certificates

:

This is something very important that I never really understood: how to use SSL certificates. They are extremely important if you are maintaining a Web Application, but I never really bothered to read about it - it was the secure elephant in my room. But now I finally got the motivation (pure pressure and necessity) to research about it, and this is what I learned:

SSL certificates are supposed to make your website more secure (duh), and they do this by ensuring:

  1. Encryption - your data will be encrypted, which is good!
  2. Data integrity - your data will not be broken, which is good!

It also has some nice side-effects:

  1. Green address bar - your address bar tuns green, which is good! I mean, your visitors will know that your website is secure. If you do financial transactions or collect important information, your website will be a lot more attractive with that pretty, green bar for your users.
  2. Prevents attacks - since your data will be encrypted, it will be (almost) impossible to steal it with "man in the middle"attacks. This is good too.
  3. Boost in ranking for searching engines - Google, for instance, will rank your website better if you use HTTPS. This is probably good.

HTTPS certificates are not free, and since you have to pay for them, you probably should think about your priorities: do you really need HTTPS in your blog that nobody reads? Probably not. Do you need HTTPS in a website with financial transactions? Probably yes.

So, first of all, how do you get a certificate? Simple. Follow these steps:

Step 1: pick your certificate type

An Overview of the Basic Types of SSL Certificates Available
Certificate Type Types of Sites Features
Extended Validation (EV) * eCommerce
* Sites collecting personal info
* Sites where user trust is paramount
* 2048-bit encryption
* Green Bar to provide top-of-the-line trustworthiness
* The type used by web giants like Twitter, banks, etc.
* Issued in 3-5 days
Organization Validation (OV) * eCommerce
* Sites collecting personal info
* Verified that the site is a registered government entity
* 128-, 256-, or 2048-bit encryption
* Issued in about 24 hours
Domain Validation (DV) * Testing Sites
* Internal Sites
* Non-eCommerce Sites
* Very affordable
* Issued almost immediately

In addition to the 3 main types above, we also have:

Multi-domain certificates

If you need to secure multiple domains, but only want one certificate: you can have up to 100 domains in your certificate, and if you get another domain, you can just add the domain to it.

Wildcard certificates

With these, you can secure your website, as well as any subdomains. They can be both DV or OV, but not EV.

Step 2: buy the certificate

There are several websites where you can buy certificates. Sometimes your own hosting company will offer this service. The price and speed for issuing the certificate will vary.

Step 3: install the certificate in your website

This will depend on what host you are using - they will have their own methods to apply the certificates. If you are using Node.js, you will probably have to use it directly in the .js file that creates the server.

Step 5: update links and images

Make sure all links in your website point to an https route instead of http. Do the same thing for images, CSS, scripts, and so on. It is also a good idea to redirect the traffic coming from any http route to the https route.

Source: http://www.hostingadvice.com/blog/choosing-ssl-certificate-made-easy/

cdot ssh ssl