Hi Jan,

On Thu, May 26, 2005 at 02:18:29PM -0400, Jan Harkes wrote:
> My guess is that the server clocks are off by a couple of seconds and
> the new token is rejected by one of the servers because local time is
> earlier than the BeginTimestamp value in the token. This also explains
> why you seem to be losing tokens.

oh, it was a sneaky trap!

> I don't really know why tokens have a BeginTimestamp, but disabling that
> part of the test seems logical. The following patch will make sure that
> the server doesn't reject tokens that haven't 'started' yet.

I do not see any practical application of tokens "to be valid in the future"
either, but it may exist. As long as we have the timestamp, it would be safest
to check it - though we might relax the check to say "up to a minute in
the future is ok" or something?

IIRC Coda is quite independent of clock on the clients being right,
but it is natural to expect the servers in the same realm to be in sync
with each other. Even if not, having big offsets between token (auth) servers
and file servers undermines the reliability of the timestamps in the tokens
in general.

So, I think the check (allowing for some small discrepancy) would ensure
among others the sanity of a setup. If we make it complain loudly about
the reason when it fails, we shall help newbie administrators as well.

> -    if (t.tv_sec < st.BeginTimestamp || t.tv_sec > st.EndTimestamp) {
> +    if (t.tv_sec > st.EndTimestamp) {

may be

> +    if (t.tv_sec + 60 < st.BeginTimestamp || t.tv_sec > st.EndTimestamp) {

?

Regards,
--
Ivan