<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 3, 2016 at 1:46 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Morgan Fainberg's message of 2016-05-03 11:13:38 -0700:<br>
<div><div class="h5">> On Tue, May 3, 2016 at 10:28 AM, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<br>
><br>
> > On 05/03/2016 11:47 AM, Clint Byrum wrote:<br>
> ><br>
> >> Excerpts from Monty Taylor's message of 2016-05-03 07:59:21 -0700:<br>
> >><br>
> >>> On 05/03/2016 08:55 AM, Clint Byrum wrote:<br>
> >>><br>
> >>>><br>
> >>>> Perhaps we have different perspectives. How is accepting what we<br>
> >>>> previously emitted and told the user would be valid sneaky or wrong?<br>
> >>>> Sounds like common sense due diligence to me.<br>
> >>>><br>
> >>><br>
> >>> I agree - I see no reason we can't validate previously emitted tokens.<br>
> >>> But I don't agree strongly, because re-authing on invalid token is a<br>
> >>> thing users do hundreds of times a day. (these aren't oauth API Keys or<br>
> >>> anything)<br>
> >>><br>
> >>><br>
> >> Sure, one should definitely not be expecting everything to always work<br>
> >> without errors. On this we agree for sure. However, when we do decide to<br>
> >> intentionally induce errors for reasons we have not done so before, we<br>
> >> should weigh the cost of avoiding that with the cost of having it<br>
> >> happen. Consider this strawman:<br>
> >><br>
> >> - User gets token, it says "expires_at Now+4 hours"<br>
> >> - User starts a brief set of automation tasks in their system<br>
> >>    that does not use python and has not failed with invalid tokens thus<br>
> >>    far.<br>
> >> - Keystone nodes are all updated at one time (AMAZING cloud ops team)<br>
> >> - User's automation jobs fail at next OpenStack REST call<br>
> >> - User begins debugging, wasting hours of time figuring out that<br>
> >>    their tokens, which they stored and show should still be valid, were<br>
> >>    rejected.<br>
> >><br>
> ><br>
> > Ah - I guess this is where we're missing each other, which is good and<br>
> > helpful.<br>
> ><br>
> > I would argue that any user that is _storing_ tokens is doing way too much<br>
> > work. If they are doing short tasks, they should just treat them as<br>
> > ephemeral. If they are doing longer tasks, they need to deal with timeouts.<br>
> > SO, this:<br>
> ><br>
> ><br>
> > - User gets token, it says "expires_at Now+4 hours"<br>
> > - User starts a brief set of automation tasks in their system<br>
> >    that does not use python and has not failed with invalid tokens thus<br>
> >    far.<br>
> ><br>
> > should be:<br>
> ><br>
> > - User starts a brief set of automation tasks in their system<br>
> > that does not use python and has not failed with invalid tokens thus<br>
> > far.<br>
> ><br>
> > "Get a token" should never be an activity that anyone ever consciously<br>
> > performs.<br>
> ><br>
> ><br>
> This is my view. Never, ever, ever assume your token is good until<br>
> expiration. Assume the token might be broken at any request and know how to<br>
> re-auth.<br>
><br>
> > And now they have to refactor their app, because this may happen again,<br>
> >> and they have to make sure that invalid token errors can bubble up to the<br>
> >> layer that has the username/password, or accept rolling back and<br>
> >> retrying the whole thing.<br>
> >><br>
> >> I'm not saying anybody has this system, I'm suggesting we're putting<br>
> >> undue burden on users with an unknown consequence. Falling back to UUID<br>
> >> for a while has a known cost of a little bit of code and checking junk<br>
> >> tokens twice.<br>
> >><br>
> ><br>
> Please do not advocate "falling back" to UUID. I am actually against making<br>
> fernet the default (very, very strongly), if we have to have this<br>
> "fallback" code. It is the wrong kind of approach, we already have serious<br>
> issues with complex code paths that produce subtly different results. If<br>
> the options are:<br>
><br>
> 1) Make Fernet Default and have "fallback" code<br>
><br>
> or<br>
><br>
> 2) Leave UUID default and highly recommend fernet (plus gate on fernet<br>
> primarily, default in devstack)<br>
><br>
> I will jump on my soapbox and be very loudly in favor of the 2nd option. If<br>
> we communicate this is a change that will happen (hey, maybe throw an<br>
> error/make the config option "none" so it has to be explicit) in Newton,<br>
> and then move to a Fernet default in O - I'd be ok with that.<br>
><br>
> ><br>
> > Totally. I have no problem with the suggestion that keystone handle this.<br>
> > But I also think that users should quite honestly stop thinking about<br>
> > tokens at all. Tokens are an implementation detail that if any user thinks<br>
> > about while writing their app they're setting themselves up to be screwed -<br>
> > so we should make sure we're not talking about them in a primary way such<br>
> > as to suggest that people focus a lot of energy on them.<br>
> ><br>
> > (I also frequently see users who are using python libraries even get<br>
> > everything horribly wrong and screw themselves because they think they need<br>
> > to think about tokens)<br>
> ><br>
><br>
> Better communication that tokens are ephemeral and should not assume to<br>
> work always (even until their expiry) should be the messaging we use. It's<br>
> simple, plan to reauth as needed and handle failures.<br>
<br>
</div></div>This is not what the documentation says, so yeah, we need to actually<br>
tell users that expires_at is an upper bounds, because right now it<br>
says:<br>
<br>
 The date and time when the token expires.<br>
<br>
 The date and time stamp format is ISO 8601:<br>
<br>
 CCYY-MM-DDThh:mm:ss±hh:mm<br>
<br>
 For example, 2015-08-27T09:49:58-05:00.<br>
<br>
 The ±hh:mm value, if included, is the time zone as an offset from UTC.<br>
 In the previous example, the offset value is -05:00.<br>
<br>
 A null value indicates that the token never expires.<br>
<br></blockquote><div><br></div><div>Ok this here is a major issue we need to fix. a token with a null expires will *not* validate.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://developer.openstack.org/api-ref-identity-v3.html" rel="noreferrer" target="_blank">http://developer.openstack.org/api-ref-identity-v3.html</a><br>
<br>
Perhaps "The latest date and time when the token expires. Tokens may be<br>
revoked or expired before this time and any use of tokens should be<br>
prepared to reauthenticate to keystone and obtain a new token at any<br>
time upon encountering a 401 error code from any service."<br>
<br></blockquote><div><br></div><div>++ Lets fix this ASAP.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am not suggesting, btw, that users would explicitly think about getting<br>
tokens. I just think a user would read the docs as they are now, and<br>
reasonably think that they could expect tokens to be around a stable<br>
amount of time, and would be annoyed that they weren't. Obviously people<br>
would like to not think about that, and that's fine, but let's actually<br>
tell users how the API works if we're going to do that.<br>
<br>
BTW, I'd submit a patch, but I can't find the api-ref/source for the<br>
identity API. :-P<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>The docs are too spread out. Sadly the API Ref has been neglected and.. well.. yes what you said. <br></div></div></div></div>