This shows you the differences between two versions of the page.
|
unifieduploader:start [2009/12/22 07:02] 87.153.227.81 |
unifieduploader:start [2009/12/22 17:12] (current) jamesharrison |
||
|---|---|---|---|
| Line 16: | Line 16: | ||
| * sort - String, order, history or other sort of upload | * sort - String, order, history or other sort of upload | ||
| * target - String, Optional, if specified denotes a target AMQP exchange | * target - String, Optional, if specified denotes a target AMQP exchange | ||
| - | * identity - String, in the format "em:HASH;ec:HASH;" - either may be omitted eg "em:;ec:HASH;" but one must always be filled with data. Hash is a unique ID for a given user | + | * identity - String, in the format "em:HASH;ec:HASH;" - either may be omitted eg "em:;ec:HASH;". Hash is a unique ID for a given user |
| * client_identity - String, as above, to identify a given upload client. May be a simple name or number as opposed to a hash, or a hash (em uses developer keys) | * client_identity - String, as above, to identify a given upload client. May be a simple name or number as opposed to a hash, or a hash (em uses developer keys) | ||
| * client_version - String, version number/name for a given upload client | * client_version - String, version number/name for a given upload client | ||
| * type - Optional (Required for order/history uploads), the typeID of the uploaded data | * type - Optional (Required for order/history uploads), the typeID of the uploaded data | ||
| * region - Optional (Required for order/history uploads), the regionID of the uploaded data | * region - Optional (Required for order/history uploads), the regionID of the uploaded data | ||
| - | * hash - SHA1 of the string formed by "data+target+identity+client_identity+client_version+type+region" for error checking | ||
| * generated_at - Time the data being uploaded was generated | * generated_at - Time the data being uploaded was generated | ||
| + | * hash - SHA1 of the string formed by "data+sort+target+identity+client_identity+client_version+type+region+generated_at" for error checking, lowercase hex-encoded. | ||
| ==== Response Codes ==== | ==== Response Codes ==== | ||
| Line 37: | Line 37: | ||
| A HTTP server running on zofu's box will take the HTTP requests, perform the consistency checks and filter out any client versions known to have bugs or be uploading bogus data, and push the received data onto a given AMQP exchange- either order_uploads, history_uploads or another exchange based on the target value (this will be restricted to a list of exchanges). The arbitrary exchange option allows for non-market data to be uploaded using the same mechanism (loot logs, fittings, etc), allowing the unified upload architecture to work with pretty much anything. | A HTTP server running on zofu's box will take the HTTP requests, perform the consistency checks and filter out any client versions known to have bugs or be uploading bogus data, and push the received data onto a given AMQP exchange- either order_uploads, history_uploads or another exchange based on the target value (this will be restricted to a list of exchanges). The arbitrary exchange option allows for non-market data to be uploaded using the same mechanism (loot logs, fittings, etc), allowing the unified upload architecture to work with pretty much anything. | ||
| - | The upload receiver will obscure the em/ec identity hashes using a secret salts. This is needed to give public feed consumers the ability to match uploads to a user (whose identity remains unknown), while protecting em/ec from upload spoofs. | + | The upload receiver will obscure the em/ec identity hashes using a secret salt. This is needed to give public feed consumers the ability to match uploads to a user (whose identity remains unknown), while protecting em/ec from upload spoofs. These resalted messages will be pushed onto the public exchanges, with the unsalted messages being confined to private exchanges for EM/EC. |
| The messages pushed onto the exchange will be YAML formatted and include all the HTTP POST parameters that are received. | The messages pushed onto the exchange will be YAML formatted and include all the HTTP POST parameters that are received. | ||
| Line 52: | Line 52: | ||
| - HTTP receiver knows EMHASH1, can check if USERKEY+USERHASH is a valid pair | - HTTP receiver knows EMHASH1, can check if USERKEY+USERHASH is a valid pair | ||
| - HTTP receiver does hash(USERKEY+USERHASH+EMSALT2) -> FEEDHASH | - HTTP receiver does hash(USERKEY+USERHASH+EMSALT2) -> FEEDHASH | ||
| + | - The 'one must be filled' part was assuming that EC required authentication on uploaded data. As this is actually not the case it can be discarded. Merged the rest. --- //[[james@mmmetrics.co.uk|James Harrison]] 2009/12/22 17:08// | ||