Becoming a Customer Company / We are the makers

Salesforce are pretty good at making marketing videos, these are two of my favorites because despite my finely honed sense of cynicism I’m a idealist who loves an uplifing musical score and some well timed words.

I’ll return to some hard core technical content next time. :)

Force.com Canvas

With  Force.com Canvas going Generally Available in Summer 13 (May-June 2013) I thought it was time to take a look.  The presentation used Canvas-PHP by Josh Birk

Here is the presentation I gave to the Sydney Salesforce Developers User Group on 17 April.

If you are in the Sydney area or remote and can teleconference, and you want to present at the Group, please get in touch with me at my email address <firstname>@<lastname>.net or via twitter @sherod, LinkedIn, meetup.com or smoke signals.

It’s been a big week.

After a lifetime of being picked last for sporting teams I’ve finally made ‘Most Valued Player’ status in something.  :)

MVP_r3_NODESCRPT

And I’m proud and excited for it to be what I’ve thrown myself into over the last couple of years  (That’s Salesforce incase you didn’t realise).

I’m still going through all the bits and pieces Salesforce sent me and I’m completely flat out at home and work, but I really wanted to thank Matt Lacey for his support in achieving this.

Of course the other enormous thing that happened this week is I changed jobs.  I’m now with Cloud Sherpas here in Sydney and I’m really looking forward to making a difference.

*An earlier version of this post used a Force.com MVP logo by mistake, my apologies!

 

Stronger Authentication for Outbound Messages from Salesforce

Salesforce offers a couple of mechanisms for securing Outbound messages.

Obviously the first step is to deploy your consuming web service to an SSL based end point and to use a CA signed certificate for the server.

You should also consider using your firewall to ensure that access to this endpoint is restricted only to the IP addresses which Salesforce uses for its services.

Finally you can also challenge Salesforce to provide a Client certificate to authenticate itself.

What you may not realise is that the client certificate is not unique to your organisation but rather generic to Salesforce.com

This opens the possibility of an outbound message being sent from another Salesforce organisation and malicious data being injected into whatever you have sitting behind your consuming webservice.

So what can you do about this?

0. Remember the Organisation ID appears in the Outbound Message

Every outbound message includes the ID of the organisation that sent it, verifying will assist you are receiving the message from the organisation you expected to receive it from.  (thanks to Stuart Hamilton for reminding me)

<element name="OrganizationId" type="ent:ID"/>

1. Place a Token in the url.

You could pass a token in the url of your configured endpoint:

https://ws.example.com./soapendpoint?token=jklasfjklwenwer83h2820222423wfaf2dfasdf2

Within the service that consumes the Outbound Message you could verify the token.

As long as you are using SSL the data in the URL should remain secret and this isn’t be any less secure than the rest of the data.   The token will be visible to anyone with access to that configuration inside Salesforce.

2. Verify Session ID

You tick the box to receive the Session ID s part of the outbound message and by calling back to Salesforce’s identity service to verify the session and the identity of the session originator: http://help.salesforce.com/help/doc/en/remoteaccess_using_openid.htm

This adds latency to the successful processing of the request.

3. Pull

Rather than transmitting all the information in the Outbound message send only the ID of the record then call back to SF with the session identifier (or with separate credentials) and conduct the query to retrieve the data.   You may be doing this anyway in order to retrieve data related to the object which triggered the outbound message.

4. Pass something in the object data

Add a token as a field in the object and pass that over in the outbound message as data content.  Probably not a great idea as it fills your data model with questionable data.

These are the options off the top of my head.  Is there something I’ve missed or a secret sauce I’m not aware of?  Let me know!

Faking a SF Outbound Message with cURL

Recently I had an issue where a third party service which was receiving an outbound message was failing.  Sadly Salesforce gives very little debugging information for outbound messaging if things go wrong (AFAIK you only get a single line in the Outbound Messaging monitoring list).

So, it can be handy to fake the outbound message sent from Salesforce to your test endpoint so you can get a bit more information.

Note, this is really only suitable for a test environment when you aren’t using sensitive data

I capture a version of my outbound message by setting up a PHP page   that will simply email me the contents of the document posted to it and then pointing the outbound message configuration at that url temporarily.

Assuming you’ve saved that Outbound Message into a text file then is you can POST that file to your outbound message service using cURL to test how if is working and capture any error messages to Standard Out.

curl -X POST -d @outboundmessage.xml -H 'Content-type: text/xml' -H 'SOAPAction:\"notification"' http://test.example.com/web/service/url

 

The 7 Apps that make up my information lifecycle

Since, in my opinion, all technical folk eventually evolve to giving lifestyle advice I figured I’d jump in early and get mine out of the way early :)

Lately I’ve decided to be far more methodical with the consumption and redistribution of information I come across.  Typically I would read articles and news in a fairly haphazard manner and then manually in inconsistently pass this on to others.

Thanks to a combination of cloud based services and iPhone/iPad apps I’ve managed to consolidate my workflow into the diagram below.

My Information Lifecycle

The key components are:

  • Buffer – for delayed retweeting (I don’t want to spam wildly)
  • Pocket – for excellent offline reading (Formerly ‘Read it Later’)
  • IFTTT – for wiring up the various services to each other
  • Chrome – because its my preferred browser and both Pocket and Buffer integrate with it.
  • Google Reader – Often via Feedly, for consuming RSS feeds from my blog list
  • Chatter – to redistribute my links and blog posts automatically on to ProQuest’s internal Chatter group.

I’m finding myself reading a lot more and actioning that information in a much more orderly manner.  As a side affect of using Buffer I’m also seeing what people are interested in the most… as it turns out those ’5 ways you can..’ ’7 reasons not to’ articles are far more popular that straight out technical postings!

A fact I may have ruthlessly exploited for this blog title ;)