Suddenly receiving 403 on all User calls, but no changes.

[steev sachs]

This is a cry for help, because I'm totally flummoxed.

Today, out of the blue, a working implementation of Valence that checks a user's existence and creates that user if they do not exist, has suddenly begun to throw 403s (invalid permissions).

The D2L sample continues to work when manually authenticated with the same data passed to our app, so this doesn't seem to be a server configuration issue or an issue with changes in the LE

(No permissions have been altered on the LE, for what it's worth.)

Does anyone have any idea what could cause this phenomenon?  Is there anything besides invalid user role permissions that could cause a 403 response?

Thank you for any help!

[Desire2Learn Staff: Jacob Parker]

Where are your user tokens (userId, userKey) coming from? (Please don't post them here.)
E.g. do you have them hard-coded? If so, there are a number of reasons they could expire, causing 403 errors.

[steev sachs]

Thank you.  It turns out the issue was that our server time had gotten off.  Apparently an invalid timestamp causes 403 on all calls.  We've now worked in a proper loop of multiple attempts to avoid this occurring again.

[Desire2Learn Staff: Viktor]

Yes -- because the timestamp is one of the factors in creating the authentication signature tokens, a time skew can result in producing an "invalid token". Better error reporting around this condition would be an obvious area where the platform could be improved, admittedly.

[Desire2Learn Staff: Jacob Parker]

In this case we report it with a body like:

Timestamp out of range
123124123421

As Steev has noticed the SDK will take that value and calculate the clock skew so that if you try again with the same application context it will work.

One thing to be mindful of is that if you are making a lot of API calls, but constantly making a new application context object (in whichever languages SDK) often the application context object won't be long lived (e.g. a singleton.) This means that if you make the retry-on-timestamp-out-of-range loop (a good thing) if you dont store away the clock skew in a more permanent place and restore it each time you make an application context you could end up trying every API call twice - not so great for performance.