# Friday, 06 November 2009

Because the format of Salesforce record identifiers are deterministic, there's always a concern when using them in Site URLs that someone will 'guess' record IDs and gain access to records.

If the data you're publishing is public anyway, like Solutions, Events, or Press Releases, then maybe it's no big deal. But when Sites are being used as landing pages for sensitive data, like Opportunities or Partner Accounts, then some more effort is required to protect the records.

Since most records correlate with an Account or Contact, in a portal context it's simple enough to check the record relationship. Otherwise, URL encryption is really the only option for anonymous visitors.

A couple blog entries here and here discuss the use of MD5 hash for creating encrypted URLs.

These solutions use custom fields and triggers to correlate a web page request with an originating request record.

With the recent release of custom settings in Winter 10, there's now the option of storing private keys and using PKI encryption to sign record identifiers and decrypt them.

Unfortunately, the Crypto class documentation is a bit 'cryptic' (pun intended) on how to implement full PKI encryption, since it only demonstrates how to sign strings, and not decrypt them. Hopefully, someone can enlighten me on how this might work. I have a C# RC4 encryption engine that I'm considering converting to Apex, but I obviously prefer to use the native Crypto class, if possible.

(Sample code from Apex Developers Guide)
  1. String algorithmName = 'RSA';
  2. String key = 'pkcs8 format private key';
  3. Blob privateKey = EncodingUtil.base64Decode(key);
  4. Blob input = Blob.valueOf('12345qwerty');
  5. Crypto.sign(algorithmName, input, privateKey);
Friday, 06 November 2009 00:34:25 (Pacific Standard Time, UTC-08:00)
# Wednesday, 04 November 2009

I'm hooked on Single Page Applications (or SPA for short). If you work in Google Apps everyday, then you know what I mean. Open up GMail, Calendar, or even a Google map, and there's just a single page load. All subsequent interactions occur asynchronously via AJAX, producing a fluid, responsive user interface.

Contrast this with a traditional web application where you fetch a page and are given a master list of records. Click on a record and a completely new page loads containing record details (aka Master-Detail pattern).

Visualforce and Dialogue Script are inherited from a paradigm that mostly encouraged multi-page apps. I've spent the greater part of 2009 re-writing just about every single DScript app to be a SPA, and now that I'm developing applications for Force.com I'm going through the same exercise.

First, don't make the same mistake I did and assume that an AJAX application using Visualforce is as simple as using the AJAX Toolkit. It'll work as a VF page within Salesforce, but can't be published to Sites for security reasons. I found this fact most unfortunate since the Salesforce AJAX API is one of the best AJAX frameworks I've worked with as it encourages functional programming (FP) and embraces all the good parts about Javascript (yes, I am trying to shed my 15 years of Object-Oriented programming and learn FP... a blog entry for another day).

A SPA treatment can be given to a Visualforce page through the use of the <apex:actionFunction /> and <apex:outputPanel /> controls, which I'll cover in detail in Part 2.

The swim lanes diagram below (click here for the full version) demonstrates the lifecyle of a Visualforce SPA page.

1) The browser requests the web page which is rendered with default data.
2) Subsequent page clicks call Apex controller methods via actionFunction.
3) The controller methods construct JSON formatted strings. 3) When the request is complete, actionFunctions re-render outputPanels that contain script templates for processing the returned JSON arrays.

Wednesday, 04 November 2009 21:42:09 (Pacific Standard Time, UTC-08:00)

If you need a primer on "what is the cloud" from a consumer perspective, my other blog has a good post that explains my definition.

When I talk about "development in the cloud", it basically means implies three things:

  • The application or service is available on the Internet
  • The code you develop is managed and hosted on an Internet server
  • The application is aggregating web services found on the Internet

I won't get into the specifics of multi-tenancy, or any other operational aspects of cloud computing, since there are many means to the same end of delivering services in the cloud.

Cloud services aren't always HTML web applications, although that's primarily what I focus on. Rich Internet Applications (RIA) built on frameworks such as Flash, Flex, and Silverlight are also strong components of the future of cloud computing.

Wednesday, 04 November 2009 15:37:51 (Pacific Standard Time, UTC-08:00)

Part of the reasoning behind the name "Embracing" the cloud is to capture the transformation taking place in my own product design and development methodology.

We've listed various apps on the Salesforce.com AppExchange since 2006, but none were what are called "native" apps running on the Force.com servers. One goal for 2010 is to develop and list up to 3 native apps on the AppExchange using Salesforce Sites.

My first application built using Sites can be found here. I'll write up a more detailed blog post in the next few days describing the process behind this site.

Wednesday, 04 November 2009 14:58:30 (Pacific Standard Time, UTC-08:00)
Running a small software company requires a healthy focus on communicating the value of your products and services without getting too technical. I founded Cubic Compass in 2001, where we continue to focus on creating great Service and Support portal solutions that are easy for Line of Business managers to deploy and use.

But Programmer-specific content is often too overwhelming for line of business managers, so at "Embracing the cloud", I'm carving out a little corner of the blogosphere where I can write about my passion of writing code for cloud services.

Some things I'll write about, in no particular order:
  • XOS and Dialogue Script (a server-side web framework I developed and maintain)
  • JQuery (my client-side language of choice)
  • Javascript (Assembly/C language for the Internet. Very powerful. I'm always looking to push the JS envelope)
  • Force.com Visual Force and Apex (Salesforce.com now offers much more than CRM)
  • Google Code API
  • Google Android (mobile devices are a key component of the cloud. I don't do iPhone development. Support the Droid!)
  • Softlayer (Where I host stuff)
  • Amazon EC2 (another place I host stuff)
  • Authorize.net (My preferred gateway for credit card processing)
  • Anything hosted in the cloud with a public API
If this sounds interesting to you, please take a moment to add me to your RSS reader. Also, if you write on a similar topic, please send me a link to your blog and I'll add it to my blogroll.

Happy coding in the cloud!
Wednesday, 04 November 2009 14:29:29 (Pacific Standard Time, UTC-08:00)