Closed Bug 985007 Opened 11 years ago Closed 10 years ago

Add configurable parameter to (stage/test!) tokenserver to allow client to set token expiry length


(Cloud Services Graveyard :: Server: Token, defect)

Not set


(Not tracked)



(Reporter: telliott, Assigned: rfkelly)




(1 file)

Nick was looking for a way to test sending expired tokens to storage servers. It might be good to allow (by configuration) a backdoor to have the client able to specify in a request param "give me a token that expires in 3 seconds"
Requesting shorter durations sounds safe in general, perhaps we can have an optional "duration" parameter in the request, and we set the token duration to min(requested_duration, default_duration).
OS: Mac OS X → All
Hardware: x86 → All
See Also: → 968592
Here's a quick take on this - you can add "duration=X" in the query string, and you'll get min(duration, server_default).

Frankly this seems safe and useful to enable even in production, but I can hide it behind a flag if you prefer.
Attachment #8393927 - Flags: review?(telliott)
Attachment #8393927 - Flags: feedback?(nalexander)
Comment on attachment 8393927 [details] [diff] [review]

Review of attachment 8393927 [details] [diff] [review]:

I wouldn't worry about hiding it. I'm not sure we should document it yet, though, in case we end up pulling it.
Attachment #8393927 - Flags: review?(telliott) → review+
Comment on attachment 8393927 [details] [diff] [review]

Review of attachment 8393927 [details] [diff] [review]:

Looks good to me.

::: tokenserver/tests/
@@ +187,5 @@
> +        # But you can't exceed the server's default value.
> +        res ='/1.0/aitc/1.0?duration=4000', headers=headers)
> +        self.assertEquals(res.json['duration'], 3600)
> +        # And nonsense values are ignored.
> +        res ='/1.0/aitc/1.0?duration=lolwut', headers=headers)

Wouldn't mind getting a 400 bad request back in these cases, but not too important.
Attachment #8393927 - Flags: feedback?(nalexander) → feedback+
Committed in

Let's keep this bug open while we try it out, and consider whether to make it an official part of the protocol.
I think what we have is good enough, we can leave it as a testing-only feature and not document it as part of the protocol.
Closed: 10 years ago
Resolution: --- → FIXED
I am taking back this bug since I am interested by the feature for Syncto.

We want to be able to configure the surface attack of the credentials we get.
The syncto server will ask new credentials for each transaction that should take less than 5 minutes. We will cache this credentials so it is important for us to reduce the 1 hour duration.

Is it reasonable to use this parameter?
Flags: needinfo?(rfkelly)
> Is it reasonable to use this parameter?

Yes, if you need it, I think it's reasonable to use and to make it a more formal (and documented) part of the protocol.
Flags: needinfo?(rfkelly)
Product: Cloud Services → Cloud Services Graveyard
You need to log in before you can comment on or make changes to this bug.