Archives: 2012

Posted on
by

iCal is a simple format for sharing calendar, event and todo list information between applications. It is widely supported by many many applications.

I have recently been hacking on a couple of projects which required me to implement the format, and during this I hit on a couple of less well documented gotchas.

So, I’ve jotted them down here in order to hopefully save you some time…

  • Line endings: The specification says that line endings should be CRLF only, and some less tolerant clients puke if they’re not.
  • No blank lines: Ensure that your output contains no blank lines, again some clients with puke or interpret these as the end of the file.
  • End in .ics (the biggy): This is important if you dynamically generate an iCal feed for use with Google Calendar. You should set header type appropriately, e.g.

    header("Content-Type: text/calendar");
    header('Content-Disposition: attachment; filename="calendar.ics"');

    But critically, if all your entries are showing up only as “Busy”, you must also end the URL you pass to Google calendar as http://foo.com/bar/whatever.ics

You may find one of these validator tools useful too.

Hope that helps!

Image “Calendar Logo” by Quadmod

Posted on
by

As I’ve blogged before, IFTTT.com (short for “If This Then That”) is a popular service which lets you trigger actions based on certain events that occur around the internet.

One of the most requested features, by programmers at least, is to add WebHooks support. Webhooks are a very simple way of pinging API information about the internet between web services. It uses JSON to send an arbitrary payload over HTTP via a POST request to a specified endpoint. This is about as simple as you can get, which is of course the beauty of it.

Support for Webhooks is an obvious extension to IFTTT, and would allow people to build on the service, connecting together more than just the hand picked menu of channels on the IFTTT dashboard. Quite why this is so slow coming is a mystery; some have speculated that it was a business decision on their part, others that it is hard to build a slick interface for something of such a highly technical nature, others that they simply haven’t gotten around to it just yet.

Free Software to the Rescue!

Until IFTTT implement a WebHooks channel, you can use the following workaround.

Abhay Rana, in a project over on GitHub, has built a some code which provides a WebHooks bridge for IFTTT and other services. I have extend to add some extra functionality you might find useful.

Currently, the IFTTT wordpress channel uses that software’s RPC endpoint to make posts, so the software works by providing a little bit of middleware, that you install on an internet facing machine, which pretends to be an installation of WordPress. You then point the wordpress IFTTT channel at this installation, passing it some special parameters.

You specify the final endpoint URL as a tag, and by default the contents of the post, title, and categories get JSON encoded and relayed to this endpoint.

My extensions

Different Webhook endpoints need different fields, however, so my extension lets you provide service specific plugins. These plugins can manipulate the data sent to the upstream endpoint further, providing different fields and encoding options. This lets you support multiple webhook endpoints from a single installation, and without having to set up multiple IFTTT accounts.

To use, create the appropriate plugin in your installation’s plugins directory containing your extension of the Plugin class, then pass a special category “plugin:NameOfClass“.

I have included an example class and a JSON payload class. The latter assumes that the post body is valid JSON, validates it, and then sends it to the upstream endpoint. This lets you send specially crafted messages to upstream webhook endpoints.

My extension also includes much more debug logging, as well as some extra validation code and graceful failures.

Why?

IFTTT is a fantastically useful service, but unfortunately you are limited to using the services they choose to (or have time to) write connectors for. I find this limiting, and at times frustrating, since as well as excluding some great existing services, it places limits on my ability to hack my own stuff together!

Previously, I’d often used twitter to glue things together. However, since Twitter are currently making concerted efforts to turn their service into just another ad serving platform, rather than the communication platform and messaging service it was growing into, it was necessary to come up with an alternative method.

WebHooks seem a better solution anyway.

Thanks again to Abhay Rana for the original code, and I hope people find my additions useful!

» Visit the project on Github…

Posted on
by

Yesterday, there was a thread on hacker news highlighting that many sites around the world were making available potentially sensitive information about their site via Apache’s server-status link (provided by mod-status).

The stated advice is to limit access to this and similar pages (such as the server info page provided by mod-info) by using Allow/Deny to limit access to requests from the local machine, thus:

<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1 ::1
</Location>

Many distributions have this as the default configuration, but beware!

If you run Squid in a reverse proxy configuration, which many sites including this one do to improve performance under high load, you can easily expose such pages.

A common reverse proxy configuration is to run Squid on the local machine “in front” of Apache by configuring Squid to listen to port 80 and relaying to a local Apache server (which is bound to a different port). Under this configuration all requests to Apache will appear to be local, originating from the local machine.

Without extra steps being taken (such as using Squid ACLs) you could quite easily expose sensitive information you thought was only available to your local admins.

Beware!