<div dir="ltr"><div class="gmail_extra">CCing the devel list for awareness and feedback.</div><div class="gmail_extra"><br>Everyone, this is about the in-progress move from oauth-based authentication to macaroons.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 5, 2016 at 12:56 PM, Matias Bordese <span dir="ltr"><<a href="mailto:matias.bordese@canonical.com" target="_blank">matias.bordese@canonical.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>I wanted to share what my initial plan would be for the macaroons auth story:</div><div><br></div><div> (1) update store auth (store/auth) to handle macaroons (get root, get discharge, refresh, etc)</div><div> Q: where/how would it be a good place/way to store the macaroons?</div><div> (sth similar to what has been done for oauth tokens? ie. json data in home dir?)</div></div></blockquote><div><br></div><div>Inside the State (overlord.State()). See overlord/* for ideas and usage patterns, please reach out online for more insights.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> (2) add login api method (daemon/api)</div><div> Q: should this import directly from store/auth? should something be added to snappy/?</div><div> (add lock/unlock state + track login)</div></div></blockquote><div><br></div><div>Seems fine to import directly. FYI, snappy/ used to be a huge catch-all package. Nowadays it's much better already, but we want to kill it altogether.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> (3) switch to macaroons:</div><div> - in login command (cmd/snappy/cmd_login), using API method above</div></div></blockquote><div><br></div><div>The snappy command is dying completely, hopefully this week still. Let's please kill the cmd_login there and replace it by something under cmd/snap/, which is the modern CLI using the client package that talks through the API.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> - in existent store interactions (store/snap_remote_repo), setting macaroons auth expected header</div></div></blockquote><div><br></div><div>+1</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> (4) remove unused oauth code</div></div></blockquote><div><br></div><div>+1. I wouldn't mind doing a first pass that removes login and oauth altogether before introducing the macaroon-based implementation, if that makes your life easier.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> (5) add macaroons refresh support</div><div> (will probably require an extra api method, and updates to store interactions to handle the refresh behind the scenes)</div></div></blockquote><div><br></div><div>This one may require more conversation. Let's get back to it later once we have more in place.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>If this makes sense, I'll be following the given order and work on an MP for each item.<br></div></div></blockquote><div><br></div><div>Some of these items seem like large chunks of work. I'd encourage breaking the pull requests further into smaller items at sensible break points. It'll make our lives easier, and your progress more engaging.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Let me know if you think we should discuss any bits, atm my main questions are the ones labeled with Q: above. As soon as I have some initial code that you can take a look at, I'll ping back (who should I mainly ping for this?).</div></div></blockquote><div><br></div><div>Please feel free to ping me directly in some channel. If I'm not around, Samuele and Michael have good context for the pieces being touched.</div><div><br></div><div><br></div><div>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a><br></div></div>
</div></div>