<div dir="ltr">On Thu, Nov 14, 2013 at 10:44 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 14/11/13 18:51, Randall Burt wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
On Nov 14, 2013, at 11:30 AM, Christopher Armstrong<br></div>
<<a href="mailto:chris.armstrong@rackspace.com" target="_blank">chris.armstrong@rackspace.com</a> <mailto:<a href="mailto:chris.armstrong@rackspace.com" target="_blank">chris.armstrong@<u></u>rackspace.com</a>>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Thu, Nov 14, 2013 at 11:16 AM, Randall Burt<br></div><div class="im">
<<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@rackspace.com</a> <mailto:<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@<u></u>rackspace.com</a>>> wrote:<br>
Regarding web hook execution and cool down, I think the response<br>
should be something like 307 if the hook is on cool down with an<br>
appropriate retry-after header.<br>
</div></blockquote></blockquote>
<br>
I strongly disagree with this even ignoring the security issue mentioned below. Being in the cooldown period is NOT an error, and the caller should absolutely NOT try again later - the request has been received and correctly acted upon (by doing nothing).<div class="im">
<br></div></blockquote><div><br></div><div>Yeah, I think it's fine to just let it always be 202. Also, they don't actually return 404 when they don't exist -- I had that in an earlier version of the spec but I thought I deleted it before posting it to this list.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Indicating whether a webhook was found or whether it actually executed<br>
anything may be an information leak, since webhook URLs require no<br>
additional authentication other than knowledge of the URL itself.<br>
Responding with only 202 means that people won't be able to guess at<br>
random URLs and know when they've found one.<br>
</blockquote>
<br>
Perhaps, but I also miss important information as a legitimate caller as<br>
to whether or not my scaling action actually happened or I've been a<br>
little too aggressive with my curl commands. The fact that I get<br>
anything other than 404 (which the spec returns if its not a legit hook)<br>
means I've found *something* and can simply call it endlessly in a loop<br>
causing havoc. Perhaps the web hooks *should* be authenticated? This<br>
seems like a pretty large hole to me, especially if I can max someone's<br>
resources by guessing the right url.<br>
</blockquote>
<br></div>
Web hooks MUST be authenticated.<br></blockquote><div><br></div><div><br></div><div>Do you mean they should have an X-Auth-Token passed? Or an X-Trust-ID?</div><div><br></div><div>The idea was that webhooks are secret (and should generally only be passed around through automated systems, not with human interaction). This is usually how webhooks work, and it's actually how they work now in Heat -- even though there's a lot of posturing about signed requests and so forth, in the end they are literally just secret URLs that give you the capability to perform some operation (if you have the URL, you don't need anything else to execute them). I think we should simplify this to to just be a random revokable blob.</div>
</div><br>-- <br><div dir="ltr"><div>IRC: radix</div>Christopher Armstrong<div>Rackspace</div></div>
</div></div>