ProgBlog

Friday, October 11, 2013

Workaround for problem with fieldset border in IE 10

I discovered a problem with the visual appearance of a page using a fieldset tag in Internet Explorer 10.

Here's a small HTML page that illustrates the problem:


<html>
<body style="background: blue;">
<fieldset style="width: 500px;">
<form>
 <legend>This is my form</legend>
 <p>Enter some text: <input type="text"></p>
 <p><input type="submit" /></p>
</form>
</body>
</html>

Here's how the page renders in IE 10. Note the wide, misaligned right border.

The border looks normal, however, in the other browsers I tested: Chrome 30.0.1599.69 m and Firefox 24.0.

I found a simple workaround, which is to explicitly set the border style for the fieldset tag:


<fieldset style="width: 500px; border: 1px solid white;">

This cleans up the border like so:

And it continues to look fine in Chrome and Firefox.

Of course, you could do the same thing in a CSS file if you prefer:


fieldset {
 border: 1px solid white; 
}

Sunday, September 29, 2013

Mod_security causes sporadic "No data received' error on website

I recently received a report from our headquarters office that our corporate website was down. I tried accessing it from my home office and had no problem, but a few minutes later, I too saw the error. In Chrome, it manifested as a "No data received" message. Clicking the "More" button revealed the further description "Unable to load the webpage because the server sent no data" and the error code "ERR_EMPTY_RESPONSE".

I soon discovered the problem was sporadic. Sometimes I was able to view the site's homepage, sometimes not. Sometimes I was able to log in to the site's Wordpress admin page, sometimes not. Sometimes I was able to save changes to a post in Wordpress admin, sometimes not. There didn't seem to be any pattern to which pages produced the error or when.

The site uses WordPress and is hosted on a GoDaddy shared server. Several people have complained about similar problems with WordPress recently (such as here and here), but didn't offer any real solutions.

I contacted GoDaddy support. Their first move was to enable error logging for my hosting account. That led nowhere: although I replicated the problem several times while logging was enabled, and although we waited several minutes for log data to be recorded, nothing showed up in the logs. The support tech concluded that no errors were being logged because the requests were being blocked before reaching the layer where logging would occur.

His next move was to run some tests on GoDaddy's firewall and the servers behind it. These tests showed that everything was operating normally.

After some thought, he concluded that mod_security was to blame. He mentioned that WordPress has recently been the target of a lot of hacking, and that GoDaddy had therefore stepped up security measures, deploying mod_security. Mod_security was mistakenly identifying some, but not all, attempts to access the site, from both headquarters and my home office, as hostile. While we assumed that users in other locations weren't affected, we had no way of knowing.

The tech suggested some workarounds, including clearing cache and cookies, and using a private browsing sessions. Neither of these helped any of the affected users. The one suggestion he offered that did work was to wait.

He indicated that once mod_security identifies a request as hostile, it blocks the sender's IP address for 90 seconds. This explains the sporadic, now-it's-up, now-it's-down nature of the problem. He also indicated that, if several requests from the same IP are flagged as hostile, the duration of the blockage becomes longer. He wasn't able to tell me a formula for how long we needed to wait. I ended up waiting several hours before trying again. At that point, the problem had resolved itself, and it hasn't resurfaced, three days later.

We really have little control over the situation. Because it's a shared hosting account, we don't have access to mod_security settings, or to network and server logs that might help with troubleshooting. The tech indicated that upgrading to a dedicated or virtual dedicated server would give us greater control. So far, we've decided not to upgrade, since it would increase cost, cause some downtime, and take several hours of effort on our part to migrate the site to a new server.

We're keeping our fingers crossed that mod_security decides that we -- and our customers -- aren't evil after all.

Tuesday, August 20, 2013

Eliminating JavaScript validation errors due to jQuery in an Eclipse dynamic web project

If your Eclipse project includes jQuery files such as jquery-1.8.3.min.js, Eclipse's JavaScript validation may report syntax errors that, although harmless, makes it look as if your project contains bugs.

Much has been written online about how to resolve this problem, but not all of it is correct. In particular, suggestions involving Properties | Validation | Client-side JavaScript are off the mark, as these settings affect JavaScript within HTML pages, not standalone .js files.

This comment -- https://bugs.eclipse.org/bugs/show_bug.cgi?id=349020#c15 -- has it right but doesn't give much detail. Here are the exact steps I followed to correct the problem:

1. Right-click the project name in Project Explorer and select Properties.

2. Expand JavaScript and select Include Path.

3. Expand the folder that contains the offending JavaScript files (which will vary depending on how you've set up your project), and click Excluded.

4. Click Edit. Click the Add button next to the Exclusion patterns textarea.

5. Now type in the pattern for files to be excluded, being careful to include the correct path, which will vary depending on how you've set up your project. In my project, the pattern is resources\lib\jquery*.*.

6. Click OK. Click Finish. Click OK. The errors should now disappear.

Behind the scenes, this added the following line to my project's .settings\.jsdtscope file:
<classpathentry excluding="resources/lib/jquery*.*" kind="src" path="src/main/webapp"/>

Resolving the error "Java compiler level does not match the version of the installed Java project" in Eclipse

I inherited a Java project created by another developer. When I opened it in Eclipse, I was able to build and run it, but Eclipse's Problems window showed an error, "Java compiler level does not match the version of the installed Java project."

Here's how I fixed it:

1. Right-click the project name in Project Explorer and select Properties. Then click Project Facets.

2. Click the dropdown arrow to the right of Java. Select the value 1.6, rather than 1.5.

3. Click OK. The error should disappear from the Problems window.

Tuesday, June 25, 2013

Making VNC server run on boot on Ubuntu

The goal: Having installed vncserver, make it run automatically on boot, without anyone needing to log in.

Environment: Amazon Web Services EC2 instance running Ubuntu 12.04.1 LTS 64-bit. Vncserver was installed as per these instructions.

To start vncserver on boot:

Open an SSH connection to the server.
cd /etc/init.d
sudo vim vncserver-start, then insert this text:

### BEGIN INIT INFO
# Provides:          scriptname
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO
#! /bin/sh

sudo -u ubuntu vncserver -geometry 1200x650

sudo chmod +x tomcat-start
sudo update-rc.d tomcat-start defaults

One of the more interesting parts is the need to NOT run vncserver as root. When vncserver-start executes on boot, it executes as root. Launching vncserver as root results in an error. The solution is to prepend sudo -u ubuntu on the last line of vncserver-start.

Friday, June 7, 2013

Enabling remote access to a PostgreSQL database hosted on AWS

The goal: To enable access via pgAdmin and psql from our local machine to a PostgreSQL database server hosted on an Amazon Web Services EC2 instance.

The environment:
Server:

AWS EC2 Instance running Ubuntu Server 12.04.1 LTS, 64-bit
PostgreSQL 9.1
Default, out-of-the-box PostgreSQL configuration. That includes listening on port 5432, a database named postgres, and a role named postgres.

Client:

Windows 7
pgAdmin III version 1.16.1
psql version 9.2.3

Until the proper security settings are applied, the client can't connect to PostgreSQL on the server. If we try to connect using pgAdmin, a Server not listening error occurs:

If we try to connect using psql, a Connection timed out error occurs:

To enable connections, we must edit the AWS Security Group and two PostgreSQL configuration files.

Editing the AWS Security Group:

Log in to AWS.
On the EC2 Dashboard, select your Instance and note which Security Group it's using:

Select that Security Group, click the Inbound tab, and add a rule. The port should be 5432, and the source should be the IP address or our local machine (not the server), followed by /32. Don't forget to click the Apply Rule Changes button.

Editing the PostgreSQL pg_hba.conf file:

Use an SSH client to connect to the EC2 Instance.
cd to the directory that contains the PostgreSQL configuration files. This may vary, but mine are in /etc/postgresql/9.1/main.
Use a text editor to modify pg_hba.conf.
Locate the line host all all 127.0.0.1/0 md5.
Immediately below it, add this new line: host all all 0.0.0.0/0 md5
Save the file.

Editing the PostgreSQL postgresql.conf file:

Use a text editor to modify postgresql.conf.
Locate the line that starts with #listen_addresses = 'localhost'.
Uncomment the line by deleting the #, and change localhost to *.
The line should now look like this: listen_addresses = '*' # what IP address(es) to listen on;.
Save the file.
Restart PostgreSQL. The command may vary. In my case, it was: sudo /etc/init.d/postgresql restart.

Now you should be able to connect to the PostgreSQL server from your local machine, using your choice of pgAdmin3 or psql!

You'll be prompted for the postgres role's password when you connect, unless you've stored the password in %APPDATA%\postgresql\pgpass.conf on your local machine. (If your local machine is running Linux, the analogous file is .pgpass, usually found in your home directory.)

Caveats: The above instructions aren't optimized for security. In a production environment, you'll likely want tighter control over access to PostgreSQL. For example, in pg_hba.conf, we granted access to all IP addresses, which might be overkill. And logging in as the default role, postgres, might not be the best idea.

Wednesday, May 29, 2013

A database gotcha - null doesn't equal anything

I recently spent a long time debugging a problem where a database query was returning fewer rows than I expected. The cause was a well-known fact, but one that's easy to forget about: a "not equals" comparison to NULL is always false. An example makes this clear...

Create a table with a couple of columns:
CREATE TABLE test
(
id integer NOT NULL,
name character varying(10),
CONSTRAINT test_pkey PRIMARY KEY (id)
)

Insert a few rows into the table; one of the rows includes a NULL value:
INSERT INTO test VALUES (1, 'abc');
INSERT INTO test VALUES (2, 'def');
INSERT INTO test VALUES (3, null);

Suppose we'd like to find all the rows where the name isn't 'abc'. It seems like this query would do it:
SELECT * FROM test WHERE name <> 'abc'

But that doesn't work. The query returns only the first row. This query solves the problem:
SELECT * FROM test WHERE COALESCE(name, '') <> 'abc'

I executed the above example in PostgreSQL 9.2, but the same principle applies to many databases.