Recently a client came to me with a small project: a single new page on her site, password protected to keep out casual browsers and search engines, but not requiring a high degree of security.

When I’m very busy, as I am now, I occasionally subcontract to other American-based freelancers with whom I’ve worked closely and whom I trust to produce excellent work. Because this project was in a language I rarely work in, I decided the most efficient use of the client’s money would be to subcontract to someone with more experience in that language. I reached out to some contacts and was put in touch with someone who received enthusiastic recommendations.

Not realizing that this individual (who will remain nameless) actually ran an outsourcing firm, I sent him some instructions; the page was presented to me the next morning.

To someone not closely familiar with web technology, it might have looked perfect. You input the password. If it was incorrect, you received a warning and nothing happened. If it was correct, you were redirected to the actual page.

However, there were two major flaws in the implementation that suggested that the requirements — or the reasoning behind them — had not been understood:

1. Use of Javascript

The password verification was implemented entirely in Javascript — I recognized this immediately from the alert box that appeared when an incorrect password was input. The problem with this is that it is entirely client-side: i.e. performed in the user’s browser. A user could simply “view source” for the page to retrieve both the password and the URL of the destination page.

2. The destination page was not password protected

That is, if you visited the URL of the destination page without first going through the password page, there was no validation performed — it could be accessed without a password. This defeated both of the purposes of the password protection: the URL could be shared among users, and if a user were to put a link from another website to the page, it could be picked up by search engines.

I sent the project back to the subcontractor, explaining my disappointment with the use of client-side authentication. He agreed to have the flaws corrected, and it was at this point that I learned that he was outsourcing overseas.

When the “corrected” page was returned to me the next morning, the password authentication had indeed been moved server-side (meaning that a casual user could not retrieve the password or destination URL); but the two-page structure that permitted unauthenticated access to the destination page had not been corrected (the correct behavior would have been to use a “cookie” to create a “session” identifying the user, and to refuse to present the destination page if the session did not indicate that the user had entered the password).

Finally, disappointed, I decided to implement the page myself, and will not charge the client for the time spent by the subcontractor. Lesson learned: be certain in advance whether the subcontractor I’m hiring outsources. I could have saved myself some time and money if I had known this — I might have hired someone else, or at the very least would have been much more specific in my instructions (overseas developers will typically implement whatever takes the least thought to meet the instructions given, so you must give them very explicit instructions.)

The same caveats apply to anyone hiring for web development. If you are considering hiring an outsourcing company rather than an American-based agency or freelancer, be certain that you have someone in house with the technical savvy to both a) communicate very detailed instructions to the outsourcer, and b) evaluate the resulting product for technical flaws and adherence to specifications.

In the end, please consider hiring your friendly neighborhood freelancer, who will make the effort to understand the problem you are trying to solve; will be able to offer suggestions as to alternate and possibly more efficient solutions; and will consider it a point of pride to solve it correctly.

The obvious solution was to code my own module, and here it is: usertrack. You can also check it out from Subversion at http://svn.triopter.com/drupal/usertrack/trunk/usertrack/ .

Usertrack includes simple Views integration for filtering, sorting, and annotating your User view with login status and last logout date. Please read the README for compatibility and installation notes.

More info about the site.

If you aren’t familiar with the plugin, it duplicates the image management dialogue to permit you to attach images to a post as metadata using a simple graphical interface — instead of having to locate, copy, and paste the URL into a custom field.

The new version allows fields to be accessed properly outside the Wordpress Loop as well as on archive and category pages. It fixes several bugs including broken template tags and some data loss bugs that were related to post revisions, autosaves, and scheduled / future posts. It’s been tested with Wordpress 2.8.6 and will likely still work with earlier versions going back to 2.7.

I’d like to extend a big thank you to everyone who submitted bug reports and fixes for the plugin — I hope you’ll contact me so that I can give you credit (name and URL) in the documentation.

Imagine the following (simplified) models:

class Blog(models.Model):
  owner = models.OneToOneField(User, primary_key=True)
  title = models.CharField(max_length=32)


class Entry(models.Model):
  blog = models.ForeignKey(Blog)
  slug = models.SlugField(max_length=255, db_index=True)
  headline = models.CharField(max_length=255)
  content = models.TextField()


If I want to show the user only their own entries in the admin object list, I can filter the list in the ModelAdmin.queryset method — simple as pie:

class EntryAdmin(admin.ModelAdmin):
  def queryset(self, request):
    qs = super(EntryAdmin,self).queryset(request)
    return qs.filter(blog__owner=request.user)


Now, say I want to also limit what blogs the user can assign the entry to. There’s a useful little ModelAdmin method called formfield_for_dbfield, but it doesn’t receive the request as an argument. What to do?

Well, the ModelAdmin.get_form method does receive the request as an argument, and it gets called before formfield_for_dbfield. So let’s just put the request object somewhere that we can get to it later:

class EntryAdmin(admin.ModelAdmin):
  def get_form(self, request, obj=None):
  self.request = request
  f = super(EntryAdmin,self).get_form(request, obj)
  return f


Then when we call formfield_for_dbfield we have easy access to the request:


class EntryAdmin(admin.ModelAdmin):
  def formfield_for_dbfield(self, dbfield, **kwargs):
    if dbfield.name == 'blog':
      kwargs['queryset'] = Blog.objects.filter(owner=self.request.user)
    return super(EntryAdmin, self).formfield_for_dbfield(dbfield, **kwargs)


Not the world’s most elegant solution, but simple and effective. And there’s plenty more you can do with these techniques. Gotta love Django!

It’s not supported on OS X.

But OS X is UNIX-y! There’s a version for Linux! Why won’t it work on OS X? Can’t you google for installation instructions?

Well, no. Perhaps my google-fu is weak, but I could find no information whatsoever about how to get it working.

In fact, if these guys hadn’t pointed out that it was possible, I would have given up then and there.

But I got it installed. And you can, too. Here’s how:

1. Make sure you have the Apple Developer Tools installed.
2. Download the Payflow Pro Java SDK (you have to log into a Payflow Pro account to get the download), and unzip it to your hard drive (it doesn’t matter where, as long as it’s a place where the user your web server runs as can get to it).
3. cd into the java directory.
4. Set your paths. I had trouble getting these to stick, so I’d love any suggestions anyone might have on that aspect:

   $ CLASSPATH=${CLASSPATH:-}:Verisign.jar:.;export CLASSPATH

   $ libpath=.:../jni:../lib

   $ LD_LIBRARY_PATH=$libpath:${LD_LIBRARY_PATH:-};export LD_LIBRARY_PATH

5. Compile the java code:

   $ javac PFProJava.java

6. Run a test transaction:

   $ java PFProJava test-payflow.verisign.com 443 "USER=YourUserName&VENDOR=YourVendorName&PARTNER=YourPartnerName&PWD=YourPassword&TRXTYPE=S&TENDER=C&ACCT=5105105105105100&EXPDATE=1209&AMT=1.23&ZIP=12345&comment1=Test JNI Transactions" 30

   Don’t forget to insert the correct user/vendor/partner/password.

   Oh, and when I tried it with an account that didn’t have a username (which is possible in payflow pro), it wouldn’t accept the transaction until I set the USER to be the same as the VENDOR.

7. I ran into another problem, which was that I kept getting a NoClassDefFoundError even after following the above steps. I fixed this by adding the absolute path to Verisign.jar to my CLASSPATH:

   $ CLASSPATH=${CLASSPATH:-}:/path/to/directory/Verisign.jar:.;export CLASSPATH

8. As I mentioned, I had a lot of trouble getting the CLASPATH to stick. I couldn’t even run the binary from another directory – even if I speicified the full path to it. In the end, the following sequence was the most reliable means of running a successful transaction:

   $ cd /path/to/binary/

   $ CLASSPATH=${CLASSPATH:-}:Verisign.jar:/path/to/directory/Verisign.jar:.;export CLASSPATH

   $ java PFProJava test-payflow.verisign.com 443 "USER=YourUserName&VENDOR=YourVendorName&PARTNER=YourPartnerName&PWD=YourPassword&TRXTYPE=S&TENDER=C&ACCT=5105105105105100&EXPDATE=1209&AMT=1.23&ZIP=12345&comment1=Test JNI Transactions" 30

   Again, I’d gladly welcome suggestions as to how to make this work more fluidly.

That’s that. You’ve got it installed. The following code will suffice to call it from PHP:

$pfpro_path = '/path/to/directory';

$pfpro_server = 'test-payflow.verisign.com'; // for test transactions. Change this for live transactions.

$vars = '?your=values&to=submit&to=verisign'; // build this string appropriately from your variables according to the payflow documentation, and don't forget to run escapeshellcmd() on each one, since we'll be passing this to exec().

$cmd = 'cd "' . $pfpro_path . '; "; CLASSPATH=${CLASSPATH:-}:"' . $pfpro_path . '}Verisign.jar":.; export CLASSPATH; cd "' . $pfpro_path . '"; java PFProJava ' . $pfpro_server . ' 443 "' . $vars . '"'

$result_code = exec($cmd, $result_string);

Phew!

Good luck…. and if you happen to figure out that whole path issue, drop me a line!

Quick-n-Easy Comments

First thing I did was to replace the commenting system I’d created for my blog-app-in-progress with the commenting framework that comes for “free” with Django.  It’s not as fully featured as I might like, but it’s got some pretty nifty options, and is fairly easy to set up.  I figured I’d rather know how to use this than re-implement comments any time I want to add them to an app.

There are some interesting ways to extend the functionality of Django’s comment framework, although I don’t really like that they require editing the original source of that framework — especially since Django itself is likely to require upgrading frequently in the near future as we approach v.1.0.  Hopefully either the comments framework will be expanded further, or the model inheritance branch of Django that I’ve heard rumors of will eventually make that much less of an issue.

Absolute URLs

One thing I discovered was that the comments framework requires that the get_absolute_url() method be defined for any class that takes comments, so I took this opportunity to replace all the paths in my app with get_absolute_url() calls.  Except for the paths in the date-based generic templates, since a date object doesn’t have an absolute URL method.

I ended up adding some more global variables to settings.py, and constructing all the URLs from those, including the ones in urls.py and in the get_absolute_url() methods.  This should make future changes to path structure much simpler.

Templates

Lastly, I wrapped everything in the blog in the base template (after troubleshooting a problem with context not passed from a custom view to a custom tag), added a template tag so I could include a date-based archive menu in the sidebar, and set up some very basic design elements in a stylesheet in the header, to visually separate the sidebars from the content (I think this will make development a bit more pleasant).

All in all, not bad for another 4 hours or so of work in an unfamiliar language and framework.  I’m very pleased with how easy it is to develop in Django, although I’m still extremely frustrated at times with documentation that fails badly to describe syntax (I’m not talking about Python syntax only, but also which optional function arguments should or shouldn’t be in a dict; or syntax for Django’s template language).

I’m also pleased that I’m feeling better.  I might even venture to add chicken soup back into my diet tonight!

So, to my understanding, a decorator is a function that gets wrapped around a second function.  When the second function is called, the decorator is effectively called instead, and it calls the second.  I could be completely misled, but I’m going to run with that for now.  If I’m wrong, won’t someone please please please correct me?

My previous praise of the documentation was a little premature. The docs are a thousand times more approachable than RoR’s, and better categorized and stuff. But they’re very lacking in descriptions of syntax, or real-world examples, and in a few cases are out of date.

I spent 2 hours trying to figure out how to get date-based generic views to work before realizing that the examples I was finding on Google (unfortunately there are none on the Django docs wiki) were all a year out of date, and the view had to be called completely differently. And then it was only by chance that I finally managed to stumble across an up-to-date example of the correct way to call them.

Still, I feel like I sort of understand how the framework functions, which is more than I can say for RoR. I’ll probably be sticking to this. Once I sort out a few last questions, I’m going to need a more ambitious project to try!