Youth culture killed my dog 4 to 8 of 22 articles Change bannerposts rsscomments rss

A Story of Chief Justice Marshall   05 Feb 06
[print link all ]

by John Esten Cooke
From the 1901 edition of the The New McGuffey Fifth Reader


Among the great men of Virginia, John Marshall will always be remembered with honor and esteem. He was the son of a poor man, and his early life was spent in poverty; but he was not afraid of labor, and everybody saw that he was a person of more than common ability. Little by little he rose to distinction, and there was scarcely any public office in the gift of the people that he might not have had for the asking. He served in the legislature of Virginia; he was sent as envoy to France; he was made Secretary of State; and finally he became Chief Justice of the United States. The greatest judges looked up to him and listened to what he said, as if that decided everything. When he died at the age of eighty, he was one of the greatest and most famous men in America.

My father knew him well and loved him, and told me many things about him. He was very tall and thin, and dressed very plainly. He wore a suit of plain black cloth and common yarn stocking, which fitted tightly to his legs and showed how thin they were. He was a very great walker, and would often walk out to his farm which was several miles from Richmond. But sometimes he went on horseback, and once he was met riding out with a bag of clover seed on the saddle before him.

His manners were plain and simple, and he liked to talk about everyday matters with plain country people, and laugh and jest with them. He never seemed to remember that he was a great man at all, and he often played quoits and other games with his coat off, as full of fun as a boy, and ready to laugh with everybody. In a word, he was so great a man that he never thought of appearing greater than other people, but was always the same unpretending John Marshall.

It was a fashion amoung the gentlemen of Richmond to walk to market early in the morning and buy fresh meats and vegetables for their family dinners. This was a good old fashion, and some famous gentlemen continued to do so to the end of their lives. It was the habit of Judge Marshal, and very often he took no servant with him. He would buy what he wanted and return home, carrying his purchases on his arm; and on one of these occasions a little incident occurred which is well worth telling and remembering.

Judge Marshall had made his purchases at the market and was just starting for home when he heard some one using very rough and unbecoming language. He turned round and saw what was the cause of the hubbub. A finely dressed you man, who seemed to be a stranger, had just bought a turkey in the market, and finding that it would not be carried home for him beccame very angry.

Judge Marshall listened a moment to his ungentlemanly talk and then stepping up to him asked, very kindly, “Where do you live, sir?”

The young man looked at the plainly dressed old countryman, as he supposed him to be, cand then named the street and number where he lived.

“I happen to be going that way,” said Judge Marshall, with a smile, “and I will take it for you.”

The young man handed him the turkey and left the market, followed by Judge Marshall. When they reached the young man’s home, Marshall politely handed him the turkey and turned to go.

“What shall I pay you?” asked the young man.

“Oh, nothing,” answered Marshall; “you are welcome. It was on my way, and no trouble at all.” He bowed and walked away, while the young man looked after him, beginning now to see that he had made a mistake.

“Who is that polite old gentleman who carried my turkey for me?” he asked of a friend who was passing.

“That is John Marshall, Chief Justice of the United States,” was the answer.

The young man was astounded and ashamed. “But why did he offer to carry my turkey?” he exclaimed.

“To give you a reprimand and teach you to attend to your own business and behave like a gentleman.”

This little anecdote will show you the character of John Marshall; and I cannot believe that it was his wish merely to reprimand the foolish young man. He was too sweet-tempered and kind to take pleasure in reprimanding any one; and I have no doubt that he carried the turkey simply from the wish to be obliging.


I enjoyed this little story on its own terms, but it is also begging to be deconstructed along several different axes. This story is long out of print and its author long turned to dust. Almost all of the orignal owners of the book this story appeared in are dead. A google search for the title only returns a single match.
I saved this story and of course Project Gutenberg has rescued over 17,000 books from the trash heap of history. But…

This is where I ran out of steam so here are some alternate endings for this blog entry. Feel free to choose one of these or make up your own:

  • <slather> “I flip a coin.”
  • <Xach> “and that’s why the tables have to be structured in a rails-friendly way”
  • <chime> “And that’s how I spent my summer vacation. The End.”
  • <dbday> “And that’s the story of how you were born!”

|

RubyConf 2005   27 Oct 05
[print link all ]

By now you’ve read the trip reports , viewed the slides , and listened to the presentations . If you haven’t then shame on you, because there is lots of good stuff there. So I’ll just talk about what RubyConf did for me and how you should change your life to take advantage of my new found knowledge.

First of all I got to do fan boy things like thank Matz for Ruby.

Note that Martin Fowler snuck into the picture, but I had to smudge him out since my understanding is that you have to buy a book from him before you can take his picture.

I also got to have lots of great conversations with my fellow rubyists. Some of it was finally getting to put faces with irc nicks and blog entries. But the chance encounters at the lunch table and at the laptop filled tables during the panels were also edifying. I’m not a gregarious person by nature, so I am very glad I pushed myself to talk to people while at the conference. Talking things over with smart people that have similar goals is one of the best ways to generate interesting ideas. Now I just need to follow through on some of them.

Probably the best part though was just spending three days concentrating on something like Ruby with lots of other people that were also enthusiastic about it. You could smell the Ruby in the air. Many of us spend our days working to pay the mortgage, changing diapers, and cooking dinner. Even though those things are important it is good for the spirit to put all of that on hold for a few days and just geek out. That I am posting a blog entry should be proof enough that RubyConf was very energizing.

My plan is to go to at least two conferences a year. I went to No Fluff Just Stuff and RubyConf this year. And I am very happy with the results. Next year I plan to be at RubyConf again. I would also like to go to a large conference like OSCON or maybe an open space conference .

So what are you doing to make yourself a better programmer and advance your career? One of the things should be regularly attending conferences.


|

Conferences   11 Aug 05
[print link all ]

There are two conferences I’ll be attending soon: Cincinati No Fluff
Just Stuff
and RubyConf.
If you would like to meet up to discuss Seaside
like web frameworks in Java
( Lakeshore ) or Ruby drop me a line
at hensleyl@papermountain.org .


|

Poor Man's Ajax   17 Apr 05
[print link all ]

Last summer I began working on extending Avi Bryant’s liveUpdater.js and integrating it into Borges . I was successful as far as that went and reported my results here and here . Unfortunately Borges turned out to be a dead end because of some fundamental problems with its implementation.

However my fork of liveUpdater.js has went on to lead a productive part in the Lakeshore project (more about it later). liveUpdater has been a core piece of the user interface for many commercial applications written by myself, the gentle folk at Mission Data , and several other people that are using Lakeshore. So in short, liveUpdater is under active development and is being used successfully in several commercial applications.

Enough with the history lesson… take a look at the demo . What’s happening is that some event on the client side (a keypress, a click, etc) triggers a request to the server via XMLHttpRequest. The server returns one or more snippets of HTML. The snippets replace existing sections of the current document based on their “id”. Very nice things are now possible with only a tiny amount (or in the case of Lakeshore, no) javascript coding. You get the dynamic feel and most of the responsiveness that is promised by Ajax without splitting your logic between the client and the server.

Here is how the “Update time” link on the demo works. The HTML contains an empty div with an id of “time”. The “Update time” link is set to use liveUpdater with a target URL of time.cgi :


document.getElementById(‘time-link’).onclick = liveUpdaterUri(‘time-link’,‘time.cgi’)

time.cgi sets the content type of its response to “text/xml”. It returns a body element containing a div with the current time. Note that the id of the div matches the id of the empty div in the original HTML document. If you wished to replace additional elements on the page just include them in the body element.


|

Common Web Security Anti-Patterns   16 Jan 05
[print link all ]

The following is from a handout I used for a presentation to a group of Java programmers. In retrospect I don't think I like the anti-pattern format, but hopefully you will find it helpful in spite of that.

Name: Trusting form data
Problem: Preserving state across a series of web pages and form submissions.
Supposed Solution: Store information in hidden form fields.
Exploit: The values of the hidden fields can be easily changed by an attacker to subvert the application. The application will then use the altered data in calculations that should only performed with trusted data.
Example: The data stored in the hidden field is the price of an item in an ecommerce system. A criminal organization exploits this to purchase a large number of expensive items at a 100% "discount".
Alternative Solutions:
  • Only accept data from forms when it doesn't matter if it is tampered with. For example instead of storing the price in an ecommerce system, only store the product id then look up the price using the product id as a key.
  • Use a framework such as Lakeshore that abstracts away the problem of managing state across pages.
  • In cases where sensitive data must stored on the client side (e.g. a price quote) the sensitive data must be cryptographically signed. A signature can be generated by concatenating the sensitive data with a secret and calculating a one way hash. This signature is then always passed with the sensitive data allowing any tampering to be detected.
Name: SQL Injection
Problem: User supplied data must be used in queries against a database.
Supposed Solution: Just substitute the user input into an SQL template and execute it.
Exploit: An attacker can carefully craft the supplied data to execute arbitrary SQL. The details vary by database vendor, but for Oracle the key concept is starting the SQL to be inserted with a single quote.
Example: An ecommerce system allows the catalog of products to be to searched based on a user supplied string by simply inserting the user supplied string into a query. The attacker enters the following as a search criteria: x' UNION SELECT table_name FROM user_tables WHERE 'x'='x. This will allow the attacker to obtain the name of the table that credit card information is stored in then use the same technique to retrieve all of the credit card numbers stored in the system.
Alternative Solutions:
  • Don't execute SQL using raw JDBC calls. Use a library such as SQLProcessor that always uses prepared statements. This is sufficient for applications that use Oracle databases, but may not be for other databases.
  • Escape single quotes in user input before using it in an SQL statement.
Further reading: http://www.securityfocus.com/infocus/1644

Name: Cross Site Scripting (xss)
Problem: User supplied data is displayed to other users
Exploit: An attacker can carefully craft the data so that it does a wide variety of malicious things when another user views the data.
Example: An ecommerce system displays the names and addresses of problem orders on a screen accessible by an administrative user. The attacker enters javascript for his address that will steal the viewing user's JSESSIONID cookie and post it to a logging URL controlled by the attacker. When the administrator views the attacker's order his JSESSIONID is stolen and the attacker can then impersonate the administrator.
Alternative Solutions:
  • Filter out dangerous characters from user supplied input before storing it.
  • Encode all user supplied input before displaying it to other users
Further reading:
|

 

Copyright © 2014 Leslie A. Hensley