Category Archives: Programming

HTTP PUT vs LDAP Modify

The StormPath blog has an interesting article exploring HTTP PUT vs POST in REST based APIs for managing identity information. The article is interesting and worth reading, but misses the bigger picture. It points out that both HTTP PUT and POST can be used for sending updates in a REST API, but the HTTP spec mandates the HTTP PUT be idempotent. The idempotent requirement dictates that for an HTTP PUT, all values must be sent on the request, not just the ones being modified by the client.

Now I am sure idempotent PUT operations are important to people that design ways to update html documents. But I’m not in that business and neither are you. I am in the business of designing and enabling distributed identity systems, and in that business you never send a modification request that passes data you don’t need to modify. Simply put, you have to assume multiple concurrent updates to the backend data.

Put another way the article could simply have said “Never use HTTP PUT for data modification”. And herein lies the most important lesson of REST APIs: the REST mechanism is the means by which to build distributed systems, not an end to itself. The fact that you are using REST does not obviate the principals of basic distributed system design.

Oh, but it gets worse. Assuming your data model is attribute-value based, some of those attributes are going to be multi-valued attributes. Just as a client should only transmit the attributes that are modified, it should also only transmit the value modifications for multi-valued attributes.

That’s why LDAP Modify works as it does. One common mistake developers make using LDAP is not doing proper multi-valued attribute updates. Likewise your REST API will not only need to support partial record updates but partials attribute value updates.

Advertisements

All you say

Jeff Atwood has an interesting post on web programming vs traditional desktop development. But he goes way too far with this blanket statement:

Pretty soon, all programming will be web programming. If you don’t think that’s a cause for celebration for the average working programmer, then maybe you should find another profession.

All you say? Really?

Putting aside entire fields such as embedded systems, game development, database administration, mainframes, developer tools and compilers, network management, systems administration, configuration management, identity management, source code control systems, etc; one could say that “all end user application development will soon be web programming”. But even that is unlikely.

First of all the death of the desktop application a long way off. I have email accounts with Yahoo and Gmail, but both feed into my Thunderbird email desktop app. I only use the web interface when I am forced to use another computer. Word processing is still done predominantly on desktop apps. As is IM, media editing, and a host of over things that people do on a day to day basis.

Even a good portion of web development will soon be desktop development. Or put another way, instead of writing clunky web applications that at best approach what is possible on a desktop app, RIAs will be written in Silverlight, Flash, or JavaFX that deliver true desktop app functionality on the web.

Software Language Impedance Mismatch

Ben Laurie rips a report on software security for suggesting that C and other languages introduce software insecurity because they don’t prevent buffer overflows:

So, what’s wrong with that statement? Firstly, I think we’ve got past the idea that there’s something extra special about buffer overflows as a security issue. Yes, there are many languages that prevent them completely (e.g. PHP, amusingly), but they don’t magically produce secure programs either. Indeed, pretty much all languages used for web development are “safe” in this respect, and yet the web is a cesspit of security problems, so how did that help?

Thirdly, talking about “unsafe” languages implies that there might be “safe” ones. Which is nonsense.

Ben makes the excellent point that languages such as Java and C# eliminate buffer overflow and a couple of other risks; they don’t necessarily result in more secure application. For example one problem I regularly see in practice is failing to prevent injection attacks (SQL, OS, etc). It doesn’t matter what language you develop in if you take the user supplied data and stick whatever they tell you into a SQL query.

And BTW a SQL injection attack on an unprotected system is a whole lot easier to do than a buffer overflow attack, especially for disgruntled ex-employees that have details of the back end DB. It’s not even hard.

But this does raise the interesting question, why do we choose the languages that we do? In some cases it’s because there is a team standard. Or perhaps you join a project already in progress. In some cases its chosen because its what you know best.

But sometimes it’s done to reduce impedance mismatch. For example I have on occasion had to write ISAPI filters and Apache modules. I suppose I could try to write an Apache module in Java, but I would spend an inordinate amount of time trying to bridge between the Java and C world. I could try to do it in C#, if the module only had to run in Apache for Windows, but again that take a lot of extra work and in the end it would be unlikely to be worth it.

As another example I have had to write provisioning connectors for both MIIS and Sun IdM. I wouldn’t try to write a MIIS connector in Java and I wouldn’t try to write a Sun IdM connector in C#.

So forget about people telling you what language is “safest” or “easiest”. Choose the one that fits the job at hand. If you don’t know a language that fits the job, team with someone who does or outsource the work.

But please do scrub those SQL statement parameters.

Jeff’s OpenID account gets hacked

No, not me (at least not me so far as I know). The Jeff in question is Jeff Atwood of the Coding Horror blog (one of my favorite dev blogs). Jeff relates how his OpenID account was hacked here and here. It’s fascinating reading, especially because the hacker was of the friendly sort who apparently just did it to point the vulnerability.

The hacker was able to obtain the unsalted hash of Jeff’s password on a different site. He then looked up that password using one of the reverse hash web sites available. He then guessed Jeff’s OpenID provider and tried the password there. Since Jeff had used the same password in both places, the hacker was able to log into OpenID and impersonate Jeff at Jeff’s StackOverflow web site, which depends on OpenID.

Here is an interesting question: is it dangerous to reveal your preferred choice of OpenID providers? I suspect there is nothing dangerous about, given peoples propensity to flock to one of the big players anyway. Even if there are a plethora of OPs, the bad guys will just script a solution that tries a list known OPs until a hit is made.

What is an engineer?

Phil Windley has this interest post about the cost of bulk cold storage. He relates this definition of engineering:

I often say, quoting Pat Taylor, one of my professors in my undergraduates days in metallurgical engineering, that an engineer is some one who can do for a dollar what any fool could do for two. Of course, building performant, efficient code is part of this, but so is understanding the cost of bulk storage and other resources and using that in the trade-off.

I love that definition.

I often quote the engineering definition of Professor Gale Neville Jr., my thesis advisor and mentor back at the U of Florida Aerospace Engineering department. He defined an engineer as “someone who measures with a micrometer, marks with a piece of chalk, and cuts with an ax”.

Of course these two professors are really describing two different facets of engineering; efficiency improvement and design. Both are critical in software development.

Phillips versus flat-head, for real this time

A while back I wrote this post comparing the argument between Virtual Directories and Meta-directories to an argument comparing Phillips and flat-head screw drivers. I forgot about it until I noticed something interesting. Somehow a lot of readers found there way to the post from a thread comparing Java and C#. But another group of readers found arrived by searching for, oddly enough, information about Phillips versus flat-head screws.

Now I have no more interest in getting involved in the Java versus C# language debate than I am in the Virtual Directory versus Meta-directory debate.

But Phillips versus Flat-head screws? Boy have I got some opinions on that.

If you have to work with existing screws your choice has already made for you (just as if you join a project in progress you seldom get to choose between Java and C#). But if you are starting a project from scratch, you not only have to choose between Phillips and Flat-head, there is also Torx (the commercial name for hexlobular internally driven screws), square, hex, Allen (internal hex), one-way-flat-head, spline drive, etc. Just as you might consider more choices than Phillips and flat-head, you might also consider a myriad of programming languages in addition to Java and C#.

But some are clearly superior to others in certain aspects. Flat-head screws have more driving power than Phillips head screws (Phillips head screws are designed to cam-out to prevent over tightening, an intentional design feature). But flat-head screws are much harder to drive by hand due to tool slippage. This is an interesting analogy to  the ease of development of C++ versus both Java and C#.

Allen and hex head screws have even more driving power than flat-head screws and are easier to user, but suffer from the limitation of needing have the exact size tool to fit the specific head size, whereas flat-head screws can accommodate a wide variety of tool sizes. This is similar to how scripting languages are often limited to use in a specific framework.

Wait, am I still talking about screws?