Issue48 49 fix hmac signing

[coleshaw]

Close #48
Close #49

Per our conversation earlier today, these small tweaks seem to make the Etna Client able to sign request bodies.

[coleshaw]

@graft ☝️ ?

[graft]

Hmm, could you comment on my JSON.generate question?

[coleshaw]

Sorry, I missed your question about JSON.generate() -- don't see a comment in the diff space. Do you have a specific question about it? Or did I miss it in Slack?

The problem with that was more of a "niceness" / UX issue. When Metis sends back error messages to Magma, they are JSON errors. But because that code used to be .join(', '), they would get flattened into a string (because Error takes a string argument only) and appear in Magma as JSON strings, not JSON objects. So instead of getting something parse-able like:

{
    "errors": [
        [
            {
                "dest": "metis://project/magma/model-record-attribute.txt",
                "source": "metis://project/metis/test2.txt",
                "errors": [
                    "Invalid bucket: \"metis\""
                ]
            }
        ]
    ]
}

you would get something a little less user-friendly (and Ruby-specific), like

{
    "errors": [
        "{:dest=>\"metis://project/magma/model-record-attribute.txt\", :source=>\"metis://project/metis/test2.txt\", :errors=>[\"Invalid bucket: \\\"metis\\\"\"]}"
    ]
}

[graft]

We should definitely squash those ugly ruby errors. However, here you are in client.rb, receiving the error, so why should you turn it into JSON here? If the problem is it needs to be transmitted on from here (i.e., magma uses etna::client to talk to metis, gets an error, and wants to pass it on to the user) that should be solved outside of the client context (magma is another service generating errors and should properly format them there).

[coleshaw]

Sorry, maybe I'm misunderstanding your question.... That method call doesn't turn the error into a JSON array, it turns the errors into a JSON-string so they can be transmitted cleanly via Etna::Error, and then Magma can properly format them. That kind of sounds like what you're suggesting (Magma formatting errors, not Etna Client), but I feel like I'm missing something.

Or, are you suggesting that Etna Client should pass a JSON object directly back to Magma, outside of raising an Error?

We could also just send back body and then parse that out in Magma, but that kind of makes the method json_error() irrelevant.

[graft]

Okay, I misunderstood what was happening here - eventually Etna::Client is packaging whatever error it gets as an Etna::Error, which can't hold a json object. This seems an unfortunate weakness in the Etna::Error type, so your solution is the only way to actually pass a json error out of the Etna::Client.

However it might be nicer to allow the Etna::Error to attach a json object instead of (or in addition to) just a string message, which would let you pass it out of here without having to JSONify it (and unpack it in Magma). Then Magma can take the JSON off Etna::Error directly and do whatever it wants.

[graft]

Let's 🚢 here and punt the Etna::Error improvements to a new issue.