RDP python library not raising exception on invalid_token
Hi
I am currently using RDP python package 1.0.0.a0
Currently the library allows checking the session state using rdp.session.get_open_state, but if the underlying token becomes invalid, the library currently does not raise an exception.
We are running some code on server A. Today, the same account was used to log into server B. This meant that that server A was no longer authenticated with Refinitiv, even though there was an open session state.
Using rdp.session_get_open_state, server A still had an open session, however from the logs refinitiv servers returned an invalid_token request on server A.
Should an error be raised when server returns invalid token? Or is there a way to check or send a heartbeat to the server to check whether the token is still valid, before a data request is sent?
rdp.HistoricalPricing.get_summaries(...)
2020-07-15 12:30:35,044 - hpack.hpack - DEBUG - Decoded (b'www-authenticate', b'Bearer realm="GET /data/historical-pricing/v1/views/events/{universe}", scope="trapi.data.historical-pricing.events.read", error="invalid_token", error_description="token expired"'), total consumed 149 bytes, indexed False
Hi Nick.
It turns out, my other asyncio loop was conflicting with the one in platform_session.py (I am on 1.0.0a0).
Because of this conflict, I was not able to get any values when calling PlatformSession.get_last_event_code() and PlatformSession.get_last_event_message() were returning 'None'.
I think, rdp library platform_session.py should be changed from:
def run(self):
self._loop = asyncio.new_event_loop()
asyncio.set_event_loop(self._loop)
To
def run(self):
try:
self._loop = asyncio.get_event_loop()
except RuntimeError:
self._loop = asyncio.new_event_loop()
This way, when I call PlatformSession.get_last_event_code() and PlatformSession.get_last_event_message(), they return valid values related to the token/session:
EventCode.SessionAuthenticationFailed iPlanet session has been expired.
I am by no means an asyncio expert, is this something you could raise with the developers? I could not find a github repository for the rdp library to raise this issue.
Thanks
Hi @JIAN.DU
Can you confirm if you are using the session state event handlers e.g.
rdp.PlatformSession(
app_key,
rdp.GrantPassword(
username = user,
password = password),
on_state = lambda session, state, message : print("Platform session state: ", state, message),
on_event = lambda session, event, message : print("Platform session event: ", event, message))
The same can be done for Eikon/desktop and TREP sessions as well.
Also, my colleague will do some test around authentication with the latest version of RDP library and respond once completed.
Hi @JIAN.DU,
The behavior I would expect you should get is that on A, when the application attempts to refresh its access token, a session authentication event should be raised within the Session indicating an issue. In this scenario, did you mistakenly start an application on server B? Or did you want the application on server B to assume control of authentication? Or did you expect the application on server A to steal it back?
Hi Nick - yes that's right. It was launched by mistake. I am looking to code in so that if it happens again, to check the token and refresh the session (steal it back explicitly) on exception. I do not expect the library to do this by default.
rdp.PlatformSession.get_open_state() was returning Session.State.Open even though it had lost the token and could not request.
I guess ideally if there was a way to also check the status of the token itself?
I have the on_event and on_state enabled as per Umer above however I do not see the lambda being called when I tried to replicate losing the token. (Could very well be my mistake)
Hi @JIAN.DU,
I will notify the Python team regarding your findings.
Just so you are aware, if you do code around this issue you will need to ensure it occurs during a refresh (not startup). Also, if you happen to run the same application on server B (as you mistakenly did), both the instances will, in effect, be "stealing" the token from each other during there respective refresh cycle.
Thanks @JIAN.DU,
Just to clarify, after you discovered your conflicting asyncio loop, did you receive the expected events when the refresh failed?