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
Best Answer
-
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
0
Answers
-
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.
0 -
Hi Umer - I have set on_state and on_event yes, but it doesn't not trigger, I believe. I am checking the state manually.
0 -
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?
0 -
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)
0 -
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.
0 -
Thanks @JIAN.DU,
Just to clarify, after you discovered your conflicting asyncio loop, did you receive the expected events when the refresh failed?
0 -
Yes after I fixed my conflicting loop and the above changes to platform_session.py
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 685 Datastream
- 1.4K DSS
- 620 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 254 ETA
- 557 WebSocket API
- 38 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 276 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 661 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 193 TREP Infrastructure
- 229 TRKD
- 917 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 90 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛