Ingredients

When you sign up with RPX and register your application, you get:

1. A application ID,
2. An iFrame widget and
3. An API token.

When signing up, the domain names need to be provided. These are domain names from which an authentication request may originate. In our case, that includes localhost and www.example.com.

Recipe

Create a login page and place the iFrame widget on it. The iFrame will point to something like

src="https://example.rpxnow.com/openid/embed?token_url=appRpxURL"

where appRpxURL is a URL served by the application. When a user interacts with the login page, RPX calls the application at this URL with a token and the application is expected to turn around and request information about the user. This Google App Engine code fragment illustrates the interaction (to access it, you will need to use an OpenID login). At this point, the application knows the user id. This part is documented in a number of places on the web.

Integration

In a number of the applications we develop at Early Stage IT, the user id is stored in a session variable using GAE Utilities for the remainder of the session. The above-cited code fragment shows this also. The application is still responsible for determining what the user is entitled to do. The first thing to do in handling a user request is to verify that the user has the requisite application capability. This is illustrated in the last part of the sample code.

When the user logs out, clear the cookies by calling theSession.terminate()

If you use it…

…please cite this blog post. Feedback — positive or negative — gratefully accepted.

Google App Engine

This Hackathon will introduce software engineers to Google App Engine. It will be free of charge, first-come-first-served but preference will be given to software engineers in the web development area.

Event Details:

• Location: Aprigo, 460 Totten Pond Rd suite 660, Waltham, MA. I would like to thank Aprigo for their sponsorship of this event.
• Date: November 6, 2009
• Time: 9:00 am to 4:00 pm
• Meeting capacity: 10 people
• Food/drink: bring your own / buy in the building.
• Sign up: Eventbrite.
  

It is not an introduction to web programming or a Google Apps session. It is assumed you know server-side web development — perhaps ASP, JSP or PHP. Please note, this session will be based on Python. Still, it is not a programming language class — the emphasis will be on learning the available APIs which are common between Java and Python on GAE. If you have any questions about whether you will get much out of the hackathon, please contact us.

Agenda The main goal is to familiarize everyone with the App Engine and how you can use it to build your web application “in the cloud”.

• 1 hr – Getting Started – What is App Engine
• 1.5 hrs – Coding
• 15 mins – Introduction to Users API
• 1.5 hrs – Coding/lunch
• 15 mins – Introduction to UrlFetch and Mail APIs
• 1.5 hrs – Coding
• 15 mins – Introduction to Images and Memcache
• 1 hr – Coding
• 45 mins – Let attendees present the apps they worked on/wrap up

Prep Work

• Attendees should plan to bring their own laptop.
• The Development Environment section of the above link suggests downloading Python 2.5 and the App Engine SDK. Please download these ahead of time.
• The Download App Engine SDK page also has instructions on downloading and setting up a development environment such as Eclipse. This is not mandatory.
• It is helpful to have walked through the Hello World example ahead of time. We will be going over it again in the first couple of hours of the session so it is optional, not mandatory, to have done this.

Example Applications. Attendees are welcome to bring their own application ideas to work on during the Hackathon. For the main example, we will work on an application in the spirit of Cafe Survey. Another possibility is to create a wiki or a blog application.

1. Cloud Development for Google App Engine
2. Cloud Development for Amazon EC2
3. Managing software delivery from outsourcers
4. Managing evolution of database configurations
5. Performance and Stress Testing
6. Security Testing

In this introductory post, I want to cover activities that cross all platforms. The premise of Cloud Development is that the company does not own any hardware. Under these circumstances, how does software development get done?

Tight control over source code is essential. This need does not go away with Cloud Computing. It becomes more important! It used to be that if you lost track of the latest source, you could always look at the working machine. No longer, not consistently anyway. In the Google App Engine support forum, there is a predictable weekly request from someone or the other for Google to help them retrieve their latest source code. The answer is always the same (no, can’t be done).  The team needs to use the source repository frequently to build from.  The source repository should be backed up, versioned and secure. What should be under source control? Everything! That includes source code (duh!), install scripts (Rightscale scripts, for example, for creating an environment), security settings,  even database configurations. This last item will require further discussion; more on it in a subsequent post.

The issue tracking database is the team’s second most important asset, after source code. It too needs to be backed up, versioned and secure^†.

A gem: Amazon knows a thing or two about payments and money transfer; no surprise that Amazon FPS (flexible payment system) should be a unique part of the offering.

When it comes to writing applications, Google App Engine (GAE) is more constrained but ramp-up is easier and more amenable to agile development — a necessity for Early Stage companies.

How can we leverage the robustness of AWS from the simple (but constrained) environment of GAE? We tried to call FPS services from GAE to see. The remainder of this post is about tips and tricks for doing so. Fair warning, it’s a bit technical.

Scenario

We’re building a GAE application that will handle its billing and collecting through Amazon FPS, so what we really need is an interface class in GAE that would access FPS (from Google’s servers to Amazon’s).

FPS offers SOAP as well as REST interfaces. REST, being closer to GAE’s urlfetch API, was the interface of choice. The trickiest part of the interface is secure signing of the URL. Any flaws in it and the FPS engine will give a terse “denied” message and send you back.

We defined an FPS class to encapsulate this behavior and all classes in our application that need to interact with FPS inherit from this class. The function MakeURL() returns a URL that is ready to send to Amazon. Here’s the code for the FPS class:

class FPS(object):
    host = '' # Populate in the derived class
    Args = {} # Dictionary. Populated with FPS parameters in the derived class
    Args['Timestamp'] = datetime.datetime.now().isoformat()
    def encode(self, aws_secret_key, str, urlencode=False):
        hm = hmac.new(aws_secret_key, str, sha).digest()
        b64_hmac = base64.encodestring(hm).strip()
        if urlencode:
            return urllib.quote_plus(b64_hmac)
        else:
            return b64_hmac

    def MakeURL(self):
        sorted_header_keys = self.Args.keys()
        sorted_header_keys.sort(key=str.lower)
        rqst = ''
        for header_key in sorted_header_keys:
            rqst += header_key + self.Args[header_key]
        encd = 'https://'+self.host+'/?'
        for header_key in sorted_header_keys:
            encd += header_key + "=%s&" % urllib.quote_plus(self.Args[header_key])
        encd += 'Signature=%s' % self.encode(SECRET_AWS_KEY, rqst, True)
        return encd

You will also need to import a bunch of libraries (datetime base64 hmac httplib urllib re sha sys time). They are all part of GAE. Everything else is part of building the application and left as an exercise for the reader.

Oh, and one last thing: the Getting Started Guide calls for downloading a number of artifacts (AWS Access Key ID, AWS Secret Access Key, X.509 Certificates and Private Key, and various SDK components). You will need the ID and the secret key but none of the other components.

Copyright © 2009, J Singh

Alternative Methods for Building Web Sites

If all you want is a web site displaying information about your company, consider these alternatives for building and hosting your web site yourself:

1. Google Sites. Some folks consider it “simplistic” but it is sure to grow in scope and sophistication.
2. Microsoft Small Business.
3. Yahoo Small Business.
4. A comprehensive list of other services available.  These provide the “iron” & the tools and you can build the services using standard web technologies.

There are also a number of firms that will do it for you for a fee. Search for the words “website creation service”. Among the more interesting ones we found:

1. IRCUSA. Prices vary from $250 (1 page) to $3000 (~12 pages).
2. Register.com. $12.95/month. Cheap but ugly.
3. Richard Waller. About $1000 for a 6-page web site.
4. GoDaddy. About $65/month.

(If you research any of the options further, or find an interesting new one, please post a comment and let us know. Thanks in advance.)  In any case, you will need to come up with what the web site will say, unless you want to hire a marketing company to do it with you.

Building a web application

A web application is more than a web site. If your users log in to make purchases, to view their portfolio, to communicate with their friends, they are using an application that they interact with.

This post is about how to build a simple web application for not much money, using the Google App Engine. You can build web sites using these techniques but you may not want the hassle. The goal is to aquaint you with resources available on the internet for building and hosting a web application. Quantitecture web site as well as Early Stage IT web site were built using the techniques described here. We request that, if you build your site based on these techniques, you include a reference to this blog on your site. We can undertake custom development of features especially for your site. Please contact us to discuss details.

Caveat emptor. Quantitecture or Early Stage IT or the author of this blog shall not be held responsible for any expenses you incur as a result of using these techniques.

Getting Started

Assuming you decided you wanted maximum flexibility in building a web site and didn’t want to use one of the methods listed above, you will need:

1. Download Google App Engine. It’s free. If you will be doing any significant programming to power your web site, best to pick up a book on Python since Google App Engine is programmed in that language.
2. This is the most formidable part of the exercise for a newbie: Downloading and configuring Eclipse to use as the Integrated Development Environment. Also install “Web Development Tools” while you’re at it — they include a nice HTML editor although you won’t need most of the other components. Strictly speaking, Eclipse is optional and you can just edit the files in Notepad. Using Eclipse makes the job easier, though. It’s free.
3. A name for your site. We use GoDaddy as the domain registrar but their values could compel you to look elsewhere. You can type in a name and see if it is available. Try others if it is not. You can spend a lot of money on a web site name but with some creativity, you may be able to get one for $10/yr or so.
4. A logo. You will need this in GIF or JPEG formats. You can spend a lot of money on a logo. We built the Quantitecture logo using GoogleFont. It’s free.
5. A FavIcon (optional). See those little icons that show up on browser tabs? They’re FavIcons. We used Microsoft Office to create the little red Q on the Quantitecture web site and converted it to the right format using a FavIcon creation tool. We used ColorPic to match the color of the Q to the red in our logo. It’s free.

Once you have gone through Hello World example for Google App Engine, preferably using Eclipse, and tested it on your local machine, upload the code and see it run on the web.

This would be a good time to follow uploading instructions to connect your domain (www.example.com) to the uploaded code. The folks at Google wrote the instructions with a great deal of precision. They should be followed meticulously. They work!

Once you have accomplished this and can see your Hello World application connected to www.example.com, please contact us via the link on this blog. We can give you a starter set of files to get your web site off the ground.

Changing the layout

If you want a different layout than what our starter files give you, you can change it. The magic to controlling layout of your web site is in CSS. You will need to change the CSS that is included in the starter files. A good book on CSS is worth the investment if you will be going this route. You do not need to change the HTML if you want to change the layout. Here is a web site that offers many possible layouts for you to use.

If you have questions

Any questions should be sent by e-mail and will be responded to as time permits. If you need a prompt response, please call us for our per-hour rates.