Notification messages sent with either the REST or SOAP transports contain the following elements:
a Signature and
Timestamp that verify the notification
message is coming from Mechanical Turk
the Version of the notification
API used for the message
one or more Event data structures
that describe recent activity for HITs of a HIT type
Similar to how you include a Signature
parameter with your requests to the Mechanical Turk Requester
service that proves it is you, and not somebody else, sending
the request, Mechanical Turk includes a
Signature with each notification message.
The signature value is calculated in the same way: Mechanical
Turk produces a string by concatenating several values from the
notification message, then calculates a Keyed-Hashing for
Message Authentication code (HMAC) with the SHA-1 hashing method
using a key known only to your application and Mechanical Turk:
your AWS Secret Access Key.
To verify the signature in a notification message:
Produce a string by concatenating the following values:
the string "AWSMechanicalTurkRequesterNotification" (the "service" name)
the string "Notify" (the "operation" name)
the value of the Timestamp
parameter included in the notification message
Calculate an RFC 2104-compliant HMAC, using your AWS Secret Access Key as the key. This is the same method you use to sign your requests to Mechanical Turk, and could be performed using similar code.
Base64 encode the HMAC value. (This is also similar to request signing.)
Compare the result to the Signature
value included in the notification message. A matching
value indicates the notification message is genuine.
For more information about the method used to produce signature values, see AWS Request Authentication.
Similar to how a REST request sent to the Mechanical Turk
Requester service must include a Version
parameter to indicate which version of the service API the
client is expecting to use, a notification message also contains
a Version parameter. This version string
will be identical to the version included in the notification
specification for the HIT type.
For notifications sent over the SOAP transport, the version will be in the message header as part of the WSDL URL. See The SOAP Transport for more information.
Tip: | Your application may need to accommodate receiving notification messages of different versions at the same time if you want to upgrade your notification specifications to a new version without missing messages. You can avoid having to accommodate multiple API versions by first disabling the notification specifications that use the old version, upgrading your application to use the new version, then updating the notification specifications to use the new version and re-enable notifications. |
When a new version of the notification API is made available, all existing notification specifications will continue to use the API versions they were using previously. You must update your notification specifications to use a new version of the API.
A notification message describes one or more events that happened in regards to a HIT type. Each event includes:
the event type (EventType), a
value corresponding to the EventType
value in the notification
specification data structure
the time of the event
(EventTime), as a dateTime
in the Coordinated Universal Time time zone, such as
2005-01-31T23:59:59Z
the HIT type ID for the event (HITTypeId)
the HIT ID for the event (HITId)
the assignment ID for the event, if applicable
(AssignmentId)
Multiple events may be batched into a single notification message.
Mechanical Turk may send a "Ping" event to your notification receptor at any time. "Ping" events are for diagnostic purposes, and do not correspond to HIT activity.