Back to all discussions

  •   almost 10 years ago

Time

1. I see the document that all "times" specified in seconds UTC but last published document for affinity system says that it is UTC + local offset. So, what is it UTC or local time?
2. The same question is for token expiry time. Is it UTC or local. If it is local how the system knows what local time my app has?

I think both answers should be UTC time but last document confused me. Please confirm.

  • 15 comments

  •   •   almost 10 years ago

    Answering my own question 2. I verified that the expiry time is sent in UTC time.

    Still waiting confirmation about data. If I specify in request 1 PM is it local or UTC on Test system?

  •   •   almost 10 years ago

    Very strange behaviour. The expiry time specified in UTC. If I calculate how much time left till it exppires it looks like it is UTC. But I get notAuthorize error after 12AM of local time. I think something is wrong on your side guys. May be you can explain how it works.

    And timestamps in GetData is going to be critical as I need to know in what time I am getting the data.

  •   •   almost 10 years ago

    All timestamps should be in UTC. That would include the "start" field of the DateTimeInterval element used in GetData request. I agree the latest document should be be clarified in that respect and we follow up with this.

  •   •   almost 10 years ago

    Here are details on the "expires_in" value (from the OAuth 2.0 spec):

    expires_in: The lifetime in seconds of the access token. For
    example, the value "3600" denotes that the access token will
    expire in one hour from the time the response was generated.

  •   •   almost 10 years ago

    You don't report expires_in, you report absolute time that's why I was asking. In this case your data custodian doesn't seem to work correctly. My token is expiring at 12AM my local time not UTC time.

  •   •   almost 10 years ago

    Can you please provide the JSON response you receive when the authorization process completes. This will be helpful to better understand your issue.

  •   •   almost 10 years ago

    I just authorized myself till the next year to avoid this. I don't think it is critical at this point.

  •   •   almost 10 years ago

    Here is BTW how you report token. As you can see there is no "expires_in", only absolute expiry time. I cannot paste xml into this field so the best I coud do: this is response from read authorization status

    AuthorizationStatus
    ns3:currentStatus 1 ns3:currentStatus
    ns3:expiry 1414123200 /ns3:expiry
    ns3:scope hourly /ns3:scope
    ns3:AuthorizationStatus

    When you send tokens you send only token type, access token and refresh token but no expiry time

  •   •   almost 10 years ago

    This appears to be the response to the Authorizarion Status request. To clarify, I was wondering if you could provided the JSON content in the response to the OAuth 2.0 Access Token request.

  •   •   almost 10 years ago

    Access token resolve report
    {"access_token":"eyJhbGciOiJSUzI1NiJ9","refresh_token":"_8Do6b7ji1XXo4fs","token_type":"bearer"}

  •   •   almost 10 years ago

    Ok, the OAuth 2.0 specification actually defines the "expires_in" parameter as recommended but not required in the Access Token response. Apologies for that.

  •   •   almost 10 years ago

    Could be useful if you report it when you send token

  •   •   almost 10 years ago

    Well upon further review, the optional "expires_in" value, and the "expiry" sub-element of the "AuthorizationStatus" element would actually specify different times. "expires_in" would indicate when the access token expires, but could be refreshed via the refresh token. "expiry" indicates when the Customer wants full authorization to conclude, and thus any access AND refresh tokens to become invalid.

  •   •   almost 10 years ago

    Thank you for explanation but currently we don't have either of them in the message :-) Are you going to add anything or for a contest it stays without expiry?

  •   •   almost 10 years ago

    Yes you have "expiry" in the respsone to the ReadAuthorizationStatus service call. In the Test Lab access tokens don't expire i.e. a refresh will not be required. As per the above, the authorization will expire based on the date set by the "Customer" during the authorization proces. This time is also indicated by the "expiry" sub-element of the AuthorizationStatus element provided in the ReadAuthorizationStatus response.

Comments are closed.