Keeping up the pace…

Starting tonight the assignment for the 232 crowd (web architecture) is to build a blog on a hosted platform, and update it three times a week.

If I assign it, I should be able to do it.

Famous last words, but perhaps not.

The in-between-class question today has centered around hosting providers – which will be the subject of a homework assignment, I think… but not just yet. First we have to cross this bridge – getting the first “real” content up (as opposed to “un”-real, which is how I classify Google-Sites content).

Initially, student blogs will be linked to the class webpage inside the  college portal. Upon approval by students, selected blogs may be featured as links from this blog… but again, only with explicit approval of the affected student(s).

Almost time for class…

Advertisements

Hacking HTTP via GET; part the second. (finally!)

When I left off (Hacking HTTP via GET; part the first) with this subject, I demonstrated the basics of “hacking” via modifying parameters on a GET method.

But what of methods? And why GET? and what else is there?

A method is the subroutine (or function or procedure or whichever semantic construct you prefer) which is bound to an object (or class); and is executed (or performed) whenever an instance (copy) of an object is encountered. Or so sayeth the oracle of the Wikipedia.

In the case of the web, wherein we are in a stateless protocol (that is, there is no implicit memory of what came before), the protocol itself defines a group of “methods” – or actions to be taken.

The currently-defined (HTTP 1.1; RFC 2616) methods are: GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT. For our purposes, the methods of particular interest are GET and POST.

Why GET? Because it’s the basic, easiest-to-comprehend (and generally program) method when data needs passing from the client to the server. When you go to a web page such as the homepage of this blog, your browser sends a GET request with a parameter of “/” (root, or whatever is aliased to root).

GET has an attribute(/feature/flaw) of displaying all the parameters requested as part of the URI.

It’s this behavior that makes it possible to “hack” via the GET – the parameters are exposed, and thus changeable before the request is sent. It’s also this behavior which makes GET the most popular way to send parameters – it’s much easier to debug! And there is a deeper more technical reason as well; buffering on the server side is handled by the web-server software, not the applications program.

POST is the other method for sending data; the authors of HTTP 1.1 thought most forms would be handled via POST requests. POST hides the data being sent – and is capable of handling much larger objects than is GET. But it is significantly more trouble to program for a POST method, and debugging is a bit more “interesting” as well.

Of the other methods, HEAD is widely used – it requests and receives header and meta-information about a resource, and is often issued by browsers simply to check if the server version is newer than the locally-cached version.

PUT and DELETE are the precursor methods to WebDAV (web-basd distributed authoring and versioning) but are rarely encountered; TRACE is a debugging method and CONNECT deals with proxy tunneling.

Back to the grindstone…

…making new webmasters and developers and support engineers.

Yep – it’s a shiny new semester.

It’s about now that I begin to envy the established bloggers – the ones who find it easy to write hundreds, or thousands of words a day… but enough carping, back to work.

Today I received a welcome piece of news – the server I donated to the college has been placed in a datacenter rack and is operating. We’ll see how well that works out, but if all is well, then we will have a Linux system accessible throughout the college network – but isolated from the “real” world. It will also have more compute and storage resources than the antique RS-6000 publicly available… and allow for server-side programming. In time we may mount a BSD VM – for shell work only, to demonstrate the differences between System V and BSD styles… but first we need to get the base system verified.

I rebuilt my apple* server this week; it is up and running but without any significant content as yet. Also the homebrew barebones ESXi server is running quite nicely, and in use as a staging and testbed server for cloud operations.

User interface designers and system architects should read the book  Traffic: Why We Drive the Way We Do (and What It Says About Us) by Tom Vanderbilt (link to Amazon) – especially chapter three – and apply the knowledge to your designs. You might also learn some useful driving tricks. This is the best thing related to computing I’ve read this year. So far.

With the new semester under way, the intent is to update the blog at least weekly, perhaps more often than that.

[note: I do not have an Apple-branded machine in working condition. But I do have a server named for a fruit.]

ON the question of the day: Google+ or Facebook?

Once again the muse lives elsewhere, but a comment thread on Facebook deserves a better discourse than that limited media can sustain.

This morning, most of the world woke up to find massive changes in the User Interface of Facebook – many of which were “inspired” by Google+. Venting, fist-shaking, etc. ensued. Meanwhile, Google took the opportunity to take the wraps off a bit, and open Google+ to everyone. It’s still classed as “beta” but now anyone can join.

If you haven’t figured it out yet, I’m in the early adopter camp. Stuff comes swinging by, I take a look, sometimes getting just a tippy-toe wet, other times jumping for full immersion. Thus I’ve been using G+ for about three months. Color me a bit skeptical at this juncture.

It’s not a replacement for Facebook.

On the other hand, I wouldn’t put too much stock in Twitter or LinkedIn – they are the most threatened by this development… especially LinkedIn. It might be why LI put its IPO back on the shelf. They may have waited a bit too long.

I don’t think we’ve found the “winner” in the social space as yet – I think FB and G+ represent the peak of an era which is about to end. They backed the wrong technology.

Google especially reminds me of Samuel Pierpoint Langley in the 1890s. He was head of the Smithsonian Institution, a learned man, with all the establishment of the day backing his experiments in heavier-than-air flight. His devices flapped their wings.

As we know, two bicycle mechanics from Ohio came up with the proper answer, and while it involved wings, it was the profile of the wing, not the flapping, which was critical.

I think there are the equivalents of the Wright brothers out there, toiling along in a garage somewhere, about to launch the new social media upon us  — and they will center around the phone. It’s this last which Facebook and Google have so neglected.

 

 

Reading, Writing, Reliability…

It’s probably not the three R’s you were expecting.

Reading – you’re doing that right now (unless you absorb blog posts by osmosis) and it’s what students need to practice. It’s astonishing to me how little time students are spending reading… not just on class assignments, but also on relevant topics and the world at large.

This lack of interest shows up in assignments and in writing. Written communication skills are necessary in most walks of life. If you want to learn to write, first you need to read. I collect writers, both in printed form and on the Internet (see this page for writers I enjoy). Just as you become a better reader with practice, so too do writing skills improve with repetition (as long as you’re not typing the same stuff over and over).

Reliability… the “soft” skill. If you tell me you’re interested in starting a web design business, and then take two or three weeks to return an email, well… I can’t recommend you to any business I stumble across. If you tell me you’re unemployed and looking for work and then don’t follow up on phone messages… I wish these were anomalies, but they’re not. They’re typical.

And that is a very sad state of affairs indeed.

Ruminations on a semester finished…

Summer School is over. Done. Kaput.

This was an experiment, on two levels. One, for me to take a course prior to teaching same; and second, adapting a semester-long course into a six-week quickie version.

Note to self: do not teach advanced classes during a six-week session. There is not enough time for the knowledge to sink in – the eureka moment arrives a bit late for most students.

Second note to self: students do not necessarily recall much if anything useful from prior semesters; even down to the trivia of how to log in to computers in our Hands-On-Lab (procedure has been the same for six years now). Do not expect students to have practiced any of the skills taught in prior courses.

Taking a class in preparation to teach it was an eye-opener. I have a much better idea of where the confusing parts are, which parts will be easy, and how problematic a lecture-intensive class is for non-native English speakers.

I do hope the students this fall read the book before class. It makes it easier on me and they’re more likely to pass the quizzes…

Help! – my hotmail account’s been hacked…

Except of course I never had a hotmail account.

But I know a lot of people who do… and who also have yahoo accounts, gmail accounts, and probably other email accounts as well – which they only access via a web browser.

The real story title is: “Help me – my browser-based email has been hijacked!”

First step in the cleanup – triage. How bad is the damage?

If this is your primary account – the one which you use for everything (online banking, shopping, brokerage, insurance, social media and so on)… you’re potentially in very deep trouble. For most folks issuing the help-me message, this is their primary account.

Now, let’s find out just how bad this is… can you reset the password? You should do so, and ditch the easily-guessed password you were using. Here is one password generator; there are many others. But get clear of the easy passwords.

Next, check your webmail system for forwards – this is hiding in settings. Are you forwarding your emails anywhere? Do you recognize every account listed? If not, you have a substantial headache ahead, because your newfound pen-pal is reading all your mail… including the one just generated by the system which confirms you just changed your password. Next step – remove the unknown mail forward assignments… and change the password again.

Now comes the painful part – you need to immediately reach out and change every password on every site where you used the compromised account as your primary email contact. Remember – your secret pen-pal has the necessary codes to reset your accounts, and may already be doing so. If you can’t get in anywhere… start calling or using other methods.

Still feel that easy password was a good idea? You should use randomized passwords everywhere, and never the same one on multiple sites. (Easy for him to say, but if you read down the blog, you’ll see I went through the same exercise a few months ago, albeit for a different reason).

If you want to save this headache in the future, a good password is a good starting place. I tend to go one step further; my primary email is not accessible via web-based systems, and can only be accessed by a dedicated email client. That’s right, I use a separate program just for email. For most of Internet history, this was the norm; web-based is a recent “convenience” – and is vulnerable to all the gotchas of web-based clients.

I use and recommend Forte Agent and Mozilla Thunderbird. Forte Agent I’ve used since its beginnings – but this is not an easy package to master, and many are turned off by having to pay for it.