Bringing back the scroll buttons to GMail

By Zoltán Nagy | Published: December 26, 2011

There’s been some noise on the ‘net about missing scroll up/down buttons in the new Google design. Note that this only affects the browsers based on WebKit (Chrome, Safari and some KDE browsers, to name a few). Here’s a way to fix that.

Why are the buttons gone?

As IE before, WebKit has introduced styleable scroll-bars. (Whether that’s a good idea or not is not the point of this article.) The new Google design uses this new feature in a lot of places. This has two effects: 1) the scroll-bars fit in nicely and 2) the scroll buttons are gone. The special CSS selectors provide a very detailed, if verbose, way for making sure the scroll-bars on the site match the design; there’s a great article explaining them at CSS-Tricks.

The solution

I haven’t managed to find a way to disable this feature in Chromium; there’s no way to disable these customized scroll-bars. The best solution I could find is creating visible elements via a user stylesheet where the buttons should be. We can do anything with them, but in this example we’ll just make simple gray boxes.

1. Find the file / text box for custom stylesheets

For Chrome (and Chromium) you’ll need to find a file. The changes will be applied as soon as you save it – there’s no need to restart the browser.

Windows:
%LOCALAPPDATA%\Google\Chrome\User Data\Default\User StyleSheets\Custom.css
(%LOCALAPPDATA% is usually C:\Users\username\AppData\Local, where AppData is a hidden folder)

Mac:
/Users/username/Library/Application Support/Google/Chrome/Default/User StyleSheets/Custom.css
Linux:
~/.config/chrom(e|ium)/Default/User\ StyleSheets/Custom.css

In Safari you don’t even have to leave your browser: you can create stylesheets in the Preferences → Advanced tab. Note that by default you’ll have to restart your browser for changes to take effect. Check out this Macworld hint if you want to work around that.

2. Add custom styles

Any CSS  you enter here will be applied to all pages loaded in the browser. The following snippet makes sure that the scroll up/left button at the start and the scroll down/right button at the end of the scroll-bar are visible as a gray box. It does not contain anything to apply it to only Google applications, but chances are that if you want the scroll buttons here, you’ll want them everywhere.

::-webkit-scrollbar-button:start:decrement,
::-webkit-scrollbar-button:end:increment {
  background-color: #ddd;
  height: 16px !important;
  width: 16px !important;
  border: 1px outset silver;
  display: block !important;
}

This is really unacceptable from a design perspective (read: it looks bad). It’s also ridiculous that we have to resort to hacks like this to have scroll buttons… Still, this is the only way I could come up with (other than disabling this extension in the Chromium/WebKit source and compiling).

Posted in Client, Desktop | Leave a comment

Mostly shiny: vector graphics with MVVM in the browser

By Zoltán Nagy | Published: December 13, 2011

I’d like to show you how to make two great libraries work together: Raphael and Knockout. I’ve built the basics of a purely browser-based application for creating simple graphs (as in “graph theory”). This article was supposed to be a longish explanation of how it all works, but unfortunately I’m really short on time.

  • The working example is here
  • And the docco-annotated source code is here

Some links and introductions are in order

Raphaël: ”a small JavaScript library that should simplify your work with vector graphics on the web”. It also includes a handy light-weight event framework called “eve” (yes, another one; yes, its good enough to exist). It’s a very useful common interface to SVG and VML (which is what IE supports instead of SVG).

Knockout: a library implementing MVVM for the browser, with dependency tracking and template support using jquery.tmpl.

MVVM: a design pattern that can be considered an alternative to MVC in some respects. The idea is that view-models (VM) and views (the first V) are bound once, and they automatically update anything connected to them when they change, while updating some kind of storage (the first M). The storage is neglected in the example, but it’s supported just fine by Knockout.

Posted in Client | Tagged , , | Leave a comment

Linux server security tips

By Zoltán Nagy | Published: December 6, 2011

The obvious

  • Always keep your system up to date with security patches. No amount of configuration can save you if your version of sshd allows anyone born before 1970-01-01 to log in as root.
  • Always employ the Principle of least privilege: give users only the permissions they strictly need.
  • Check that your system doesn’t run a telnet daemon by default.
  • Use a firewall to close all unused ports manage ports available for local applications to listen on.[2] See ufw (Uncomplicated Firewall) for a simple iptables-based solution.

The less obvious

  • Disable administrative interfaces like PhpMyAdmin, the Nagios web GUI and cPanel when not used. You may also consider disabling the web-based interfaces of Cacti, Munin and friends; they should be password-protected at the least.
  • Even when you use them, they should be behind strict firewall rules[1] and HTTPS. A self-signed certificate will work just fine for the HTTPS part. The nginx manual has a simple procedure for setting this up here. The configuration options for apache are listed here (you might want to follow the key creation procedure from the nginx manual; it’s summed up rather nicely).

SSH

The goal of many attackers is to gain shell access to your box. Hardening your sshd configuration is an important step in preventing this. Everything you’ll find below is tested with OpenSSH. The configuration options must be added to the sshd configuration file, usually /etc/ssh/sshd_config. Changes to this file will take effect after you restart the sshd server or reload the configuration options with /etc/init.d/sshd reload (replace init.d with rc.d if needed :) )

Restrict remote login to users that really need it

Why:

Less users mean less targets, obviously. Specially, root never needs SSH access. Note that disabling login by setting the login shell to /bin/false prevents only a subset of the attacks handled by this solution.

How:

Use the AllowUsers and/or AllowGroups directives. Users not covered by either directive are not allowed to log in via SSH.

Example:

AllowUsers user1 user2 user3
AllowGroups group1 group2
PermitRootLogin no

Disable password authentication

Why:

Password based authentication is inherently less secure than the public-key alternative. You can find an easy to follow comparison at Rongchaua’s blog.

How:

  1. If you don’t have a GPG SSH[3] key yet, you’ll have to create one. See this GPG Quick Start guide On Unix-based systems ssh-keygen will create your SSH keypair after you answer a few simple questions[1], or see this guide for PuTTY on Windows.
  2. Once you have the private and public keys, paste the public key into the file $HOME/.ssh/authorized_keys on the server. OpenSSH is quite picky about the permissions of files, so make sure that only you can access it (“chmod 0600 $HOME/.ssh/authorized_keys“ should be good enough).
  3. Make sure you can log in without entering your login password. If you disable password authentication without setting this up correctly, you can lock yourself out of the system.
  4. Disable password login and other unsecure login methods:
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Force the usage of SSH-2

Why:

 The older protocol, SSH-1 is less secure, and all modern clients support the new protocol. Using only SSH-2 in sshd is also the default in modern servers[1].

How:

Protocol 2

Use a non-standard port

Why:

Running the SSH daemon on a random port requires little effort, for a little security through obscurity decreasing the number of attackers a bit[1].

Why not:

A decent port scan will usually still find the service. It might not be worth the effort; decide for yourself.

How:

The port number should probably be below 1024, because binding to these ports require root privileges, thus reducing the risk of port hijacking. Make sure you choose a port not already associated with an application (eg. by checking that it’s not in the nmap-services file).[1]

port $PORT

You can then log in via the command-line client using the -p switch:

$ ssh -p $PORT user@host

Take this a few steps further, and we get port knocking. It’s a technique not universally accepted as a useful solution in production environments. Setting up port knocking is out of the scope of this article, but there are plenty of resources out there.

Monitoring tools

The steps outlined above make it harder for an attacker to gain access to your system. It should be noted that this is far from being a complete guide on setting up a secure server; there are whole books dedicated to the topic for a reason.

Anyway, when a bad guy manages to access your system, you want to know about it, fast. Finding out about the problem from a request to stop brute-forcing another server does not qualify as fast.

fail2ban ”scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.” This will stop brute-force attacks, but not DDoS attacks. Dealing with denial of service attacks is still not a completely solved issue; see this article for some of the problems and solutions.

ossec is “an Open Source Host-based Intrusion Detection System. It performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.” Chances are it will pick up the side-effects of most intrusions. Be sure to configure at least the notification address where alert emails are delivered, even if you leave other options on their default.

 IANAD

(I am not a disclaimer. Oh wait, yes I am.)

I’m not a system administrator by training. All of this information can be found online; this is only a collection that I hope may come in handy for someone. Let me emphasize that you don’t necessarily get a secure system just by following these instructions. That said, I’ve listed all the security measures I’ve taken to protect the server running this blog at the time of writing; this setup is good enough for me. Still, the server has no sensitive information, and I’m not a sysadmin.

Update: Coming out and stating that this is the setup I use is not acceptable from a security perspective. I accept the risk, and the potential fun it will bring. What I really want to say is: I eat my own dogfood. Even if stating this makes said dogfood less tasty for me.

[1] Thanks to kdorf for pointing this out in this comment on reddit
[2] Thanks to ngroot for pointing this out in this comment on reddit
[3] Thanks to mowrawn for pointing this out in this comment on reddit

Posted in Server | Tagged , , | 2 Comments

Proposal: a community-powered collection of PHP best practices

By Zoltán Nagy | Published: November 29, 2011
Scott Griepentrog kindly rented a domain to use for this purpose and set up a publicly accessible Google Sites page. All that’s missing now is great content (actually, maybe not, if you’re from the future). You can find the wiki at http://phpfu.org

Why?

We all know the old argument on why PHP is often seen as a “bad” language: the barrier of entry is low, so lots of people will write PHP code without learning the fundamentals. However, the arguments usually stop there. Known fact, there’s nothing we can do. But maybe there is?

What?

Let me be clear: I don’t want to teach design patterns to everyone who makes a worship site for their dog. What I’d like to see, and what I’m really missing, is a central repository of best practices for solving common middle to high-level problems. Ideally in a wiki format. What would this bring to the table? It would tell you that is, indeed, thoroughly solved, and also how it’s done. It can also be thought of as a FAQ of sorts, or a collection of best practices (emphasis on best).

Yes, Google is usually your friend. What Google doesn’t do is code review of blogs and tutorials. Let me give a trivial example: I’ve googled really hard when I needed to implement a secure authentication scheme. What I found was tens of “simple login script with PHP and SQL”. What I finally ended up with is basically what Phpass is doing – dynamic and static salts, bcrypt, you know the drill. It’s not as extensible or general, but the theory (and probably the security) is there. What I didn’t know was that Phpass existed. My Google-fu must have been weak that day or something.

I just looked until I found something good enough and went with it. I feel this is characteristic of a lot of development, and not always a bad thing. On the other hand it takes real experience to know what’s good enough, and this experience can come at a high price (especially when considering security).

So what would this proposed wiki say on the topic of secure password storage?

Probably something like: “Use Phpass”. There, it’s not that complicated. Probably include a few good samples of using it, and we’re golden. A full framework-independent example of a complete secure authentication scheme would be killer. Mention OpenID as a full-fledged alternative, probably.

Yes but this still assumes that the developer who needs the information realizes that s/he needs it!

Indeed. However, by making it explicit that such-and-such information can be found here, it’ll be constantly at the back of the developers mind. If it’s easy to reach, maybe we’ll start looking even when we have a full solution in mind. You know, just in case. We can do that now, but (a) making sure we don’t miss a good resource because it’s three pages down in DuckDuckGo and (b) making it really quick to check on a topic instead of reading several articles can only be a good thing.

Why is it that only PHP need such a resource?

This is a valid question. I’m pretty sure some languages/frameworks already have this (probably called a manual or somesuch). It’s usually the documentation of a framework, so of course the documentation of PHP-the-language can’t be expected to contain these things.

Why doesn’t this exist already?

I can probably be convinced that not even PHP needs this. Or is there such a site out there already, and I just missed it? If there isn’t, why not? Is it redundant, not worth it? Does everyone just go with “good enough”?

Is this feasible? Let’s start one!

PS.

Phpass being the bestestest password storage solution is not the point of the post. Feel free to name alternatives. Also, most of this rant is based not on any statistical data, only my “gut feeling”.

Posted in Server | Tagged , | 7 Comments

Node.js, Express and CoffeeScript

By Zoltán Nagy | Published: November 26, 2011
The solution oultlined here uses the compiler Connect middleware, which was removed in Connect 1.7 (and therefore in newer Express.js versions). The new alternative is connect-assets.
Thanks to Marcel Miranda for pointing this out.

I’ve been working on a moderately complex hobby project for a while using Node.js and CoffeeScript. This is the first of a few posts on what I’ve learned so far. This time: using CoffeeScript on the client- and the server-side and auto-compiling client side scripts on the fly with Express.

The goal of the project is, by the way, to illustrate some common algorithms in the browser. You can check it out at GitHub: https://github.com/abesto/algo, or see a running version at http://algo-abesto.dotcloud.com. The blank area next to the controls is where you can draw your graph.

Server side

The theory is simple: CoffeeScript code is equivalent to JavaScript code. Node.js can thus be programmed in CoffeeScript. In practice, things turn out to be just as simple: write your code in CoffeeScript, use the file extension .coffee, and use coffee app.coffee to start your application. Even require works out of the box. You can see an example here (using Express)

Client side

This section assumes you’re using the Express web framework.

Express has support for compilers, and a compiler is shipped for CoffeeScript. Setting up the paths is not well documented, unfortunately. Here’s how it works: for each compiler you’ll specify a src and a dest folder, without a trailing /. The request path sent by the browser is appended to this.

http://localhost:9000/js/foo/bar.js will map to the source file src/foo/bar.coffee and the compiled file dest/foo/bar.js. If the compiled file doesn’t exist or is older than the source file then it will be (re)compiled. If there’s an error during compilation, then the browser will receive a 500 error.

What will NOT be done is:

  • Express won’t remove the compiled file if the source file is removed
  • Express won’t create any missing directory structure. If dest/foo doesn’t exist, then Express will return a 404 error to the browser. If you know how to work around this, please write a few lines :)

Note: this was originally posted to a previous version of this blog on 01. November 2011.

Posted in Client, Server | Tagged , | 4 Comments

Sup + GMail on Arch Linux

By Zoltán Nagy | Published: November 21, 2011

“The goal of Sup is to become the email client of choice for nerds everywhere.” It sure became my email client. Setting it up is quite straightforward once you have it figured out, but it takes some time if you haven’t used a similar setup yet.

Installing on Arch Linux

I don’t know if this is really because I run Arch, but I had to make some changes before Sup installed. First install the dependencies via gem install. Make sure you use ncursesw instead of ncurses. This supports wide (multi-byte) characters, and more importantly Ruby 1.9.x (what you’ll find in the Arch repos).

  1. Get the Sup source with $ git clone git://gitorious.org/sup/mainline.git sup-mainline
  2. Then edit the Rakefile:
    • require "sup-files" => require "./sup-files"
    • require "sup-versions" => require "./sup-versions"
    • s.add_dependency "ncurses" => s.add_dependency "ncursesw"
  3. Finally make gem, and gem install pkg/sup-999.gem.

After that you should have a working Sup installation. However, that’s not too useful, if Sup doesn’t know where to find your mail.

Incoming mail: offlineimap

OfflineIMAP is what it says on the box: you can access your mail even when offline. It will keep an offline copy of your mail in mailbox format, perfect for consumption with Sup.

Example OfflineIMAP setup for GMAIL ($HOME/.offlineimaprc):

[general]
ui = Noninteractive.Quiet
accounts = main

[Account main]
autorefresh = 5
quick = 10
localrepository = main-local
remoterepository = main-remote

[Repository main-local]
type = Maildir
localfolders = /home/abesto/mail

[Repository main-remote]
keepalive = 60
type = Gmail
remoteuser = name@gmail.com
remotepass = password
nametrans = lambda foldername: re.sub ('^[gmail]', 'bak',
    re.sub ('sent_mail', 'sent',
    re.sub ('starred', 'flagged',
    re.sub (' ', '_', foldername.lower()))))
folderfilter = lambda foldername: foldername not in '[Gmail]/All Mail' and foldername not in 'Sent mail'

Running offlineimap will now start fetching your emails from GMail. You’ll obviously want to run it automatically; refer to the ArchLinux wiki for how to do this. Another idea is running offlineimap in the before-poll hook.

If you use IMAP folders to categorize your mail on the server (GMail labels, anyone?) you’ll have to tell sup to look in these additional folders. A simple startup.rb hook to do this:

dirs = `ls ~/mail | grep -v bak`
dirs.each do |d|
  uri = "maildir:/home/abesto/mail/#{d}"
  unless SourceManager.source_for uri
    source = Maildir.new uri, true, false, nil, [LabelManager.label_for(d)]
    SourceManager.add_source source
    log "Added source #{uri}"
  end
end

Outgoing mail: ssmtp

ssmtp gives a sendmail alias, and sends mails via an SMTP server. Beware: the configuration is system-wide (needs some extra work in multi-user environments with environment variables, if usable at all).
Even attachments will work just fine. I didn’t test signed/encrypted attachments.

msmtp is a slightly more complex, but similar tool, that uses per-user configuration.

Example ssmtp config (/etc/ssmtp/ssmtp.conf):

#
# /etc/ssmtp.conf -- a config file for sSMTP sendmail.
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=name@gmail.com
# The place where the mail goes. The actual machine name is required
# no MX records are consulted. Commonly mailhosts are named mail.domain.com
# The example will fit if you are in domain.com and you mailhub is so named.
# Where will the mail seem to come from?
#rewriteDomain=y
# The full hostname
hostname=my_hostname

AuthUser=name@gmail.com
AuthPass=password
FromLineOverride=YES
mailhub=smtp.gmail.com:587
UseSTARTTLS=YES

This will make ssmtp send everything (even cron-generated error reporting mails) through GMail.

Filters, labels, notifications, etc.

Sup provides a convenient hook system. You can write scripts in Ruby that will be executed with certain variables (functions, really) set for you. A list of available hooks can be found at the Sup wiki. One useful thing you can do is filter messages in the before-add-message hook. A simple but complete lib to help with that can be found at GitHub: javcius/sup-filters.

GnuPG

You can use gpg-agent for signing and encryption. A simple way to ensure that there’s always exactly one gpg-agent running can be found at the Arch wiki. Make sure you source /etc/profile.d/gpg-agent.sh in your shell init script (.zshrc, .bashrc, …) if you won’t run Sup in a login shell.

Tweak those labels!

Sup comes with sup-tweak-labels, that lets you modify message (thread? I’m not sure) labels based on queries. For query syntax, check out the Sup README. For example, the following line will mark all messages coming from “joe” at any mail provider as read, remove them from the inbox and add the label nsfw.

sup-tweak-labels -q 'from:joe' -r 'inbox,unread' -a 'nsfw' --all-sources

Update 2011/05/14: Florian Unglaub (f dot unglaub at googlemail dot com) wrote an improved version of the startup hook. It adds “a little bit more ruby action to get a nice source URI and label tag without any need to rename things in offlineimap and grep for it.”

Dir[ENV['HOME']+'/mail/*'].map do |d|
  uri = "maildir:"+d
  log "Processing source #{uri}"
  unless SourceManager.source_for uri
    source = Maildir.new uri, true, false, nil, [LabelManager.label_for(File.basename(d))]
    SourceManager.add_source source
    log "Added source #{d}"
  end
end

Update 2011/01/13: Adding the line SourceManager.save_sources to the startup hook below will have two nice nice effects. Sup will have less work to do on startup, and you can use the sources with all the sup-related tools (like sup-tweak-labels).

Posted in Desktop | Tagged , , | Leave a comment