<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, 20 Sep 2018 at 14:35, Ryan Kelly <<a href="mailto:rfkelly@mozilla.com">rfkelly@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>Hi All,</div><div><br></div><div>Over in github we've been discussing our options of rate-limiting pairing channel creation attempts:</div><div><br></div><div>  <a href="https://github.com/mozilla-services/channelserver/issues/21" target="_blank">https://github.com/mozilla-services/channelserver/issues/21</a></div><div><br></div><div>One obvious approach would be to use the existing fxa-customs-server, and just add some new action types like "createPairingChannel" and "connetToPairingChannel" that the channelserver can send over for checking.  However, the fxa-customs-server is currently run as a private "sidecar" service for fxa-auth-server, exposed only over a localhost interface.</div><div><br></div><div>Does it make sense for us to try to extract fxa-customs-server into its own standalone service that can be accessed by multiple consumers?  Or is that likely to be more work than just adding rate-limiting code directly into the channelserver?</div></div></div></blockquote><div><br></div><div>Another option would be to try running a third-party ratelimiting daemon that can be shared among different services, such as:</div><div><br></div><div>  <a href="https://github.com/lyft/ratelimit">https://github.com/lyft/ratelimit</a></div><div>  <a href="https://github.com/limitd/limitd">https://github.com/limitd/limitd</a></div><div><br></div><div>Which may be less work than adding custom rate-limiting code in channelserver.</div><div><br></div><div>+ulfr for possible opinions from opsec team.</div><div></div><div><br></div><div>  Cheers,</div><div><br></div><div>    Ryan<br></div></div></div></div></div>