[philiptellis] /bb|[^b]{2}/
Never stop Grokking


Friday, January 27, 2012

Saving a PDF that doesn't allow saving form contents

Several organisations, consulates, for example, have forms that need to be filled up in PDFs. They have very smart PDFs that change as you fill out the form and generate nice 2D bar codes at the end with all the information easily scannable when you submit the form. Most of these forms can be saved after you've filled them out, which is important if it's complex and you need to work on it for a few days, or if you need to put it on a pen drive and take it somewhere else to print.

Every now and then however, I've come across a PDF that won't allow you to save the form contents. This kinda sucks, so I decided to find a work around.

I first tried the print to PDF option, however Adobe won't let you print these particular PDFs to a PDF.

I tried Preview, but you can't fill out the form in Preview.

Then I tried actually printing it to a dummy printer. Note that this is for MacOSX.

  1. The first step is to open your printer settings. If you don't have a printer create one:
    Print & Fax
  2. Then open the Print Queue and pause it
    HP Deskjet F4200 series
  3. Step 3, is to print your document to this printer.
  4. Now look into /private/var/spool/cups for a file that was created within the last few minutes. It should start with d and have a lot of numbers after it. You'll need sudo:
    sudo ls -l /private/var/spool/cups
  5. copy this file somewhere convenient, and give it a .ps extension (it's a postscript file).
  6. You can now open this file with Preview. I recommend opening it and reordering the pages, and then save it as a PDF.
That's it. There's a way to do it for windows too, but I don't have a windows box handy to document it. Linux is trivial.

Wednesday, January 25, 2012

Password reset over HTTP -- Part 2

So it looks like I've been forgetting a lot of my passwords recently. After yesterday's issue with delicious submitting passwords in the clear, today I have a problem with livemocha.com.

As before, their login page is properly secured, but the password reset page is over HTTP:

This is the password reset page:

livemocha - password reset over http

And this is the URL the passwords are POSTed to, in clear text:

livemocha - password reset submitted over http

They also include third party code on their page, in this case it's a flash object from userplane.com, google analytics, and some JavaScript from pbc.com (alias for paybycash.com)

I've gotten in touch with them via their online form. Let's hope they respond.

Tuesday, January 24, 2012

HTTPS for login but HTTP for password resets

I recently tried to log in to my delicious.com account, and realised that I'd forgotten my password, so went through the reset password flow. This is what I saw...
  1. The Sign-in page is over SSL, which is good:
    delicious login over ssl
  2. The Forgot password page, where you enter your username is also over HTTPS. Not strictly required, but good all the same:
    delicious - forgot password over HTTPS
  3. This sends you an email with a link to reset your password. This page is not over HTTPS:
    delicious - reset password page -- not over HTTPS
  4. And submitting this form also goes to a page that is not over HTTPS:
    delicious -- form submit over http

Now they put the login page on HTTPS, which shows that they want to protect the user's password from sniffing, but the password reset form, which also accepts the user's password, sends the password in clear text over HTTP. This isn't good. If you're going to protect passwords via SSL, do it everywhere. FWIW, the userid (but not the username) is also sent in this form.

Additionally, the password reset page contains JavaScript from google analytics and chartbeat. As I've written before, you shouldn't trust third party scripts. While you may choose to ignore this on most pages, pages that accept the user's credentials should be considered sacred. The user assumes that anything they enter on this page is available only to your servers. By including third party JavaScript, you're breaking that trust.

I've emailed violations@delicious.com with these details, and am awaiting a response.

Update 2012-01-25 21:08 UTC: As of this time, Delicious have fixed the core issue of the password reset page being on HTTP. Kudos to the team for acting quickly. The secondary issue of third party scripts on this page still remains, but that's a policy decision for them, and not me.

...===...