On 08/06/2013 09:52 AM, Patrick Ohly wrote:
On Tue, 2013-08-06 at 09:21 +0300, Alberto Mardegan wrote:
[...]
> I don't think so. A client should simply assume that the
token it gets
> is valid, and use it as long as it can. As soon as some calls start to
> fail because the token is invalid, it would have to request a new one.
> If even the new token is wrong, it should use add the
> UiPolicy=RequestPasswordPolicy to the parameters dictionary and request
> a new one, and if that also fails, just stop trying.
That's exactly what SyncEvolution now does, except that after the first
failure it sets the "force refresh" flag. That's not more complicated at
all, and it if fixes one corner case. Seems worthwhile to me.
Your code is probably well written and clean, but in the general case
adding one more step is something which can considerably complicate the
code.
> Note that this flow is not OAuth specific, and the client
doesn't need
> to know anything about refresh tokens.
True. So perhaps the flag should be renamed from "ForceRefresh" to
"TokenFailed" to reflect what happened instead of what is expected to
happen.
Yes, but I would argue that this is exactly what RequestPasswordPolicy
is for (I admit that's also not entirely well-named): the client uses it
to tell signond that the authentication reply it got from signond is
invalid. It doesn't need to know the exact reason. And in fact, we have
already a hard time explaining what RequestPasswordPolicy is for, that
I'm rather against adding another flag unless it's really necessary.
Anyway, we'll see how it goes: I claim that it's possible to fix the
issue without the ForceTokenRefresh, so for the time being I won't
implement it. signond will ignore it, so you'll still be able to use the
same code for UOA and gSSO. If I turn out to be wrong, well, I'll just
implement it. :-)
Ciao,
Alberto