Categories
Social Media Technology

Facebook’s astonishing fail

update

I did find a reference to this type of behavior…from 2010.

What I suspect happened is some very old security code accidentally got compiled into the Facebook server app, in relation to the company’s new security feature, and I just happened along when it was exposed.

Either that, or I stumbled into a time vortex.

earlier

I treated myself to a new smartphone today. Among the apps I loaded was Facebook. I had copied my password from Dashlane and was ready to go, when I ran into something new:

Facebook’s new security system.

To prove I am who I am, Facebook displayed a set of images, each with a set of names, and asked me to pick the person who matched the image. OK, this ought to be good.

The first was an obviously 30+ year old photo of a chubby baby. So who is it?

I’d have a hard time recognizing one of my own baby pictures, much less the folks on Facebook. Especially considering many people, such as myself, don’t even use photos of themselves as their Facebook profile pictures. So, next image, please.

The next showed a cartoon strip, with a square around one of the panels. The security question then asked who the image was. I can tell you that it isn’t Barbara Schmitz or Nanny Baker.

The third showed an image I did recognize: Mr. Presidential Candidate Rand Paul. Which means it wasn’t Kevin Stamps or John Doppler.

The thing that saved me was when another photo of a woman looked like Sarah Barnett. Thankfully, Sarah also had a conference pass around her neck with “Sarah Barnett” printed on it. But by that time, I’d taken too long or missed too many images, or some such thing, so I had to start over.

Facebook…you’ve taken “being completely unaware of how people use your web site” to a level never before heard of, or seen. And then you exceeded it by using your complete lack of understanding to form the platform for your new security system.

Categories
JavaScript Writing

JavaScript Cookbook 2nd Edition: Live and Personal

JavaScript Cookbook cover

The second edition of the JavaScript Cookbook just went live at O’Reilly. If you’re wondering why I haven’t been writing about technology as much lately, it’s because I was saving all my tech writing mojo for the book.

We went a somewhat different path with the second edition. I spent a lot less time on syntax, and a lot more on JavaScript in use. When I wrote my first book on JavaScript, in the dark ages that was the mid-1990s, syntax was about all you had with JavaScript. Now, JavaScript is everywhere. It’s the programming language that ate the world.

Well, nibbled the world. JavaScript is still that friendly, approachable language, even with the new ECMAScript additions. JavaScript has never roared; it’s meowed and purred its way into our lives. Good kitty. Nice kitty. Here, have a closure.

In the new edition of JavaScript Cookbook, I covered JavaScript in the browser, and re-visited our old friends (Ajax and the JS objects), yes. But I also spent a considerable time covering JavaScript in the server, in the cloud, and in our mobile devices. The only environment I didn’t cover is the open source hardware, DIY, wearable world, and that’s because I feel these need more preliminary introductions to the environment, so you don’t do something like fry your new Raspberry Pi. Or Computer. Or shirt.

I will never join with those who are critical of JavaScript. I have always had fun with this language. There’s just so much you can do with it.

Categories
Browsers

It’s just a tool

I gather that Mozilla has named some marketing person as interim CEO as they search for a replacement who would be acceptableeffective.

I don’t care, really. Mozilla is an organization that provides support for Firefox, a tool I use. I’m using Firefox because it is the browser that irritates me the least at this time. I used Chrome previously, but stopped when yet another unexpected-and-suddenly-appearing design change made it marginally unusable.

I appreciate the hard working souls who work on the browsers and the specifications that form the basis for the technology implemented in the browsers—most of whom don’t work for Mozilla, or Google for that matter. Most of them don’t get paid for their work, either.

If anyone deserves passionate support, it’s the people who labor on the technology that goes into my browser. Anything else is just organizational politics benefiting some corporate entity.

In the meantime, I use Firefox. I don’t do so because of loyalty or because of some cause. It’s just a tool.

Categories
Technology Weblogging

Web Server 101 for Ghost

update

I disabled the Ghost weblog because I don’t want to maintain two different weblogging software applications, and Drupal is my primary weblogging software.

The configuration listed here was sound and reliable for well over six months.

—-

Recently I installed Ghost on my server. Ghost is a Node.js weblogging tool that you can host yourself or have another organization host for you.

It’s not a complicated application to install. There’s even a How to Install Ghost web site, with handy instructions for installing Ghost in various environments.

Take my environment, which is Ubuntu Linux hosted on a Linode VPS. You could order a brand new VPS, but chances are your server is already set up, and you’re just looking to install Ghost.

You have to install Node.js first, of course. Then you download the Ghost source code, and install the application, using the following steps:

mkdir -p /var/www/
cd /var/www/
wget -O ghost.zip https://ghost.org/zip/ghost-latest.zip
unzip -d ghost ghost.zip
cd ghost
npm install --production
cp config.example.js config.js

Next you edit the configuration file, changing the default IP and port values to ones that allow people to access your new Ghost weblog:

host: '[your Linode public IP]',
port: '80'

Lastly, start that puppy up:

npm start --production

 

Now, you’re all set, good to go, blasting full ahead on all cylinders…

…right for that wall that is about to hit you, hard, in the face.

A reality check on that environment

Let’s back this sweet scenario up to, oh, step 1: your environment.

True, you could be installing Ghost in a brand new environment with nothing else installed. Chances are, though, you’re installing Ghost in an existing system that is already running a web server. Chances are also good the web server you’re running is Apache, which is running on port 80, the same as your new Ghost installation.

So what happens when you try to run Ghost on the same port you’re using with Apache?

If you try to start the application withnpm, you’ll get an almost immediate error response signaling that an unhandled error event has occurred, and to contact the Ghost author. If you try to start the Ghost application via another tool, such asforever, you may not see an immediate problem at the command line, but if you access the Ghost site via a browser, you’ll get a 503 “Service Temporarily Unavailable Error”.

You’re getting an error because you can’t run both web services at the same port. You then have two options to run your Ghost weblog. Option 1 is to shut down Apache or install Ghost on a machine where Apache is not installed, and then you can run Ghost at port 80. The second option is to find a way to get Apache (or other web server) and Ghost to co-exist.

Let’s take a look at that first option: running Ghost in a stand alone environment at port 80.

Running Ghost in a Stand Alone Environment

If you don’t have Apache installed, or no other web service running at port 80, you could follow the steps I gave earlier, and you might expect Ghost to start. You might, but you could be in for a surprise.

If you try to start Ghost with a line such as the following:

npm start --production

You’ll most likely get an error. If you try to start Ghost up directly, using Node, you’ll find that the error is EACCES, “permission denied”. The reason why is that port numbers below 1024 are what is known as privileged ports, requiring root permission. When you tried to start up Ghost as a normal user, you lacked the permissions to start the service.

You might be tempted to use sudo to start the Ghost application:

sudo npm start --production

And yes, Ghost should be alive and well and running on port 80. But this command just triggered a visceral response from security minded web developers, because now Ghost (which is currently in beta development and unlikely to be hardened) is now running with root privileges. Not even Apache, hardy veteran of the web wars that it is, responds to web requests with processes running with root privileges.

Behind the scenes, when you start Apache as root, it spawns a worker thread that handles a web request. This worker thread runs with the privileges of a non-root user, typicallywww-data. If you’re running a Linux server, you can issue the following command and see that one Apache process is running as root, while other child processes are running as the Apache user (www-data).

ps -ef | grep apache

Other web servers, such as Nginx, operate under the same principle.

So, what do you do if you want to run Ghost at port 80?

Well, you can start Ghost up on port 2368 (the default port) and then go where most folks don’t dare to go by tweaking iptables to redirect port 80 to port 2368, or something similar. Bottom line, though, is you just don’t run Ghost as a stand alone web server/application, period.

In an issue thread at github the architects behind Ghost have stated that they see Ghost as an application, not web server. As such, they don’t recommend that people run it directly, as a web server. Instead, they recommend using Ngnix or Apache as the web server, and then reverse proxy to Ghost. Both Nginx and Apache are hardened from a security perspective, and both do a better job providing other services the Ghost folks won’t be providing.

The Ghost folk recommend using Ngnix,and you can use Ngnix as reverse proxy for both Apache and Ghost if you’re hosting Apache applications. For myself, I don’t need the extra level of complexity or the performance boost that Ngnix can provide for static files, so I decided to go with Apache as reverse proxy. I’ll cover the steps I took, but first, let’s return to that running instance of Ghost.

Running Ghost Forever

My Ghost weblog is currently running at Shelley’s Toy Box. Shelley’s Toy Box is my hack and trash domain where I’ll try new things. I thought about getting a separate VPS for it, but can’t really afford it at this time, so I’m making do with a virtual host for now.

Ghost is running at port 2368, the default. Yes, this means you could also access the Ghost weblog at http://burningbird.net:2368, and completely bypass Apache doing so, but we’ll get to that in a little bit. For now, I have started Ghost usingforever:

forever start  -l forever.log -o out.log -e err.log index.js

If Ghost crashes and burns,forevershould start it back up. However, if the server, itself, gets re-booted, Ghost isn’t restarted. Luckily, since I’m running Ubuntu, I can use Ubuntu’s Upstart to re-start Ghost withforever.

I created a simple file named ghost.conf in /etc/init, with the following text:

# /etc/init/ghost.conf
description "Ghost"

start on (local-filesystems)
stop on shutdown

setuid your-userid
setgid your-grpid

script
    export HOME="path-to-ghost"
    cd path-to-ghost
    exec /usr/local/bin/forever -a -l path-to-logfiles/forever.log --sourceDir path-to-ghost index.js

end script

Now when my system re-boots, the Ghost weblog restarts. And it restarts as my non-privileged user thanks to thesetuidandsetgid.

Using Apache as reverse proxy

Apache has a good description of forward and reverse proxies, but simply stated, a reverse proxy allows web users to access both Apache and Ghost in our servers, seemingly on the same port 80.

I’ve not used Apache as a reverse proxy before, so this is new territory for me. After going through variations that left my server crawling on its knees, I found a routine that seems to work well, or at least, not work badly.

First, I had to enable bothmod_proxyandmod_proxy_http:

sudo a2enmod proxy
sudo a2enmod proxy_http

I’m not turning on forward proxying, so didn’t uncomment any of the lines within the proxy.conf file in Apache’s mods-available subdirectory.

I already have several virtual hosts configured, so it was a simple matter of creating another for Shelley’s Toy Box. In the settings, I turnProxyRequestsoff, just because I’m paranoid (it shouldn’t be on), and then add myProxyPassandProxyPassReversesettings:

<VirtualHost ipaddress:80>
    ServerAdmin shelleyp@burningbird.net
    ServerName shelleystoybox.com

    ErrorLog path-to-logs/error.log
    CustomLog path-to-logs/access.log combined

    ProxyRequests off

    <Location />
            ProxyPass http://ipaddress:2368/
            ProxyPassReverse http://ipaddress:2368/
    </Location>
</VirtualHost>

I specify my ip address for the virtual host, because I have used two IP addresses in the same server in the past, and may again in the future.

Once I enable the site and reload Apache, I’m good to go.

a2ensite shelleystoybox.com
service apache2 reload

The only issue left is the fact that people can also access the Ghost weblog directly using other domains and the 2368 port (i.e. http://burningbird.net:2368). Since I’m running Ubuntu and am using iptables, I add the following rule:

iptables -A input -i eth0 -p tcp --dport 2368 -j DROP

This prevents direct access of port 2368, while still allowing Apache to proxy requests to the port. I maintain it between boots using iptables-persistent. However, it is modifying iptables, so you have to balance modifying iptables against people accessing the site via another site domain and direct access of the port.

Ghost as Weblog

Ghost is an important addition to the Node.js community because weblogging software appeals to a broad range of interests and experience levels. That latter is particularly important because we’re now seeing with Ghost the issues people face when running a Node.js web application, particularly in a world where Apache is so ubiquitous. Ghost is a learning experience, and not just for the Ghost developers or users.

Having said that, at this time I don’t recommend Ghost for people who are only looking for a weblogging tool. Ghost is still in the early stages of development and lacks much of the basic functionality we’ve come to associate with weblogging software. However, if you’re interested in Node.js development and are looking to get in on the ground floor of a weblogging application (before all the complex bells and whistles are added), Ghost can be a fun and educational alternative to Drupal or WordPress.

Whatever you do, though, don’t run Ghost with root privileges. It’s no fun to get your butt bitten off.

Categories
Books JavaScript

JavaScript, not a ‘real language’

Simon St. Laurent and I have been discussing that exciting upcoming conference, DHTMLConf.

Party like golden sparkles following the mouse cursor is cool again!

If you’re going to JSFest, how can you not go to DHTMLConf? This is a conference celebrating a time when all of the technologies we take so seriously now, were fun!

Simon is going, and is taking along a copy of his old Dynamic HTML book he managed to find. That made me dig around online for anything on my old books, including my Dynamic HTML book (1998), as well as my earlier (1996) JavaScript How-To.

I had to laugh when I saw the marketing blurb attached to the JavaScript How-To book at Amazon:

JavaScript is the ultimate in web eye-candy. It is not a real programming language such as Java, and it isn’t really essential for web site development, but it sure is a lot of fun for tinkerers.