Hey,

I found that the timestamp in the {services_timestamp_nonce} table all had the maximum integer value (2147483647). After poking around for a bit, I found that this is because the timestamp is displayed in milliseconds, and therefore is too long to be stored in a integer field.

I fixed this by dividing the $timestamp variable of function _services_keyauth_authenticate_call in services_keyauth.inc by 1000 ($timestamp = array_shift($args) / 1000;).

Could this error occur because of a php.ini setting? If so, which one ? :-)

Comments

marcus_w’s picture

marcus_w commented

Oops, too soon, can't authenticate that way. But I'm unable to find the real time() call, which passes to the argument. Can anyone help me please?

marcus_w’s picture

marcus_w commented

Well, one more post.

It seems my Java update is feeding the server with millisecond timestamps. I tried dividing that by 1000, but that resulted in an error because the same nonce was used in 1 second (at least, I think that's it). So, I'm pretty stuck.

It would be better if the timestamp for nonce creation is not directly put through to the services_timestamp_nonce table. So just the php 'seconds' timestamp goes into the table. That way, the 30 second expiry rule can work, while the millisecond nonce creation can also work. You'll just get 2 (or more) nonce strings per timestamp in the table.

marcingy’s picture

marcingy commented
Status: Active » Closed (works as designed)

The table stores unix timestamps which is seconds based, so the issue is that you are passing timestamps in the wrong format.