Seems reasonable. I had it on my list of 'silly questions' to ask someone why xLO had to be to left of auth :)
I tried moving xLO to the right of tempauth and seems to work fine (as in func tests pass). With keystoneauth I got timeouts due to keystoneauth exceptions when the subrequests env wasn't as expected but Clay's patch sorted that.
Putting paranoia hat on - is there a risk that a client could take advantage of this change to deliberately extend the lifetime of a token/avoid revocation? e.g. client starts a GET just before revocation, reads slowly... owner revokes token and PUTs new xLO segments, client reads new content. Do we/should we check that segment put timestamps are < original GET request timestamp?
Seems reasonable. I had it on my list of 'silly questions' to ask someone why xLO had to be to left of auth :)
I tried moving xLO to the right of tempauth and seems to work fine (as in func tests pass). With keystoneauth I got timeouts due to keystoneauth exceptions when the subrequests env wasn't as expected but Clay's patch sorted that.
Putting paranoia hat on - is there a risk that a client could take advantage of this change to deliberately extend the lifetime of a token/avoid revocation? e.g. client starts a GET just before revocation, reads slowly... owner revokes token and PUTs new xLO segments, client reads new content. Do we/should we check that segment put timestamps are < original GET request timestamp?