EMA: {"error":"invalid_grant" }
Hi,
We have been receiving the following error message using EMA API. Not sure why:
loggerMsg TimeStamp: 18:06:39.070 ClientName: ChannelCallbackClient Severity: Warning Text: Received Channel warning event on channel Channel_3 Instance Name Consumer_3_1 RsslReactor 0x0x7e9240 RsslChannel 0x(nil) Error Id -1 Internal sysError 0 Error Location /r/emalib_dbg/Cpp-C/Eta/Impl/Reactor/rsslReactorWorker.c:3375 Error Text Received HTTP error 400 status code with data body : {"error":"invalid_grant" } . loggerMsgEnd
Thanks,
Best Answer
-
Thanks for the log.
Based on your log, it seems to be the issue on the server-side rather than EMA. I’m not sure why the server replies with the invalid_grant because EMA already sends a new request to get a new Access Token with grant_type = refresh_token, and it also sends a valid refresh_token with the request message.
--- REST REQUEST ---
<!-- Time: 22:31:01:808 -->
URL: https://api.refinitiv.com/auth/oauth2/v1/token
HTTP method POST
HTTP header data:
Accept : application/json
Content-Type : application/x-www-form-urlencoded
HTTP body data: grant_type=refresh_token&username=GE-XXXXXXXXXXXXXXXXX&client_id=XXXXXXXXXXXXXXXXXXXXXXXXXXX&refresh_token=XXXXXXXXXXXXXXXXXXXX
Request timeout: 90
--- REST RESPONSE ---
<!-- Time: 22:31:04:547 -->
HTTP header data:
Date : Thu, 14 Jan 2021 03:31:04 GMT
Content-Type : application/json
Content-Length : 29
Connection : keep-alive
X-Amzn-Trace-Id : Root=1-5fffbaf5-31xxxxxxxxxxxxxx498c58c3
X-Served-By : region=us-east-1; cid=43a92xxxxxxxxxxxxxxxxxxxb3205a29
X-Tr-Requestid : xxxxxxxxxxxxxxxx84-3f45af9e7bfe
HTTP body data: {"error":"invalid_grant" }
Protocol version: HTTP/1.1
HTTP status code: 400
--- REST REQUEST ---
<!-- Time: 22:31:09:552 -->
URL: https://api.refinitiv.com/auth/oauth2/v1/token
HTTP method POST
HTTP header data:
Accept : application/json
Content-Type : application/x-www-form-urlencoded
HTTP body data: grant_type=password&username=GE-XXXXXXX&client_id=1fc3b1f559e44d2381c5ffa004909af9c47fb12f&scope=trapi.streaming.pricing.read&takeExclusiveSignOnControl=true
Request timeout: 90
--- REST RESPONSE ---
<!-- Time: 22:31:09:969 -->
HTTP header data:
Date : Thu, 14 Jan 2021 03:31:09 GMT
Content-Type : application/json
Transfer-Encoding : chunked
Connection : keep-alive
Content-Encoding : gzip
X-Amzn-Trace-Id : Root=1-5fffbafd-395d75a2277d9a6417d43767
X-Served-By : region=us-east-1; cid=73ef8666607743fca9aec424574aba15
X-Tr-Requestid : b9395c54-cf7d-479b-b0a7-aa92d476c011
HTTP body data: { "access_token":"eyJ0eXAiOXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-hj2Uiaerqyg8GVvUdOSGzLJ4bunAZCnURln2kozY6Q", "refresh_token":"653XXXXXXXXXXXXXXXXXX", "expires_in":"300" , "scope":"trapi.streaming.pricing.read", "token_type":"Bearer" }
Protocol version: HTTP/1.1
HTTP status code: 200
--- REST REQUEST ---
<!-- Time: 22:35:10:079 -->
URL: https://api.refinitiv.com/auth/oauth2/v1/token
HTTP method POST
HTTP header data:
Accept : application/json
Content-Type : application/x-www-form-urlencoded
HTTP body data: grant_type=refresh_token&username=GE-XXXXXXXXXXXXXXXXX&client_id=1fc3bXXXXXXXXXXXXXXXXXXXXXb12f&refresh_token=65372b05-436b-48c3-9fe2-275e996c03b0
Request timeout: 90
Anyway, after it gets the error, EMA immediately sends a new request with a grant_type password to get a new Access Token instead; therefore, this should not cause a delay in your application. I think that is the reason that EMA treats this kind of message as a warning.
I would suggest you open a case with the RDP server support team and provide them the log to contact the RDP Gateway team to verify what happens at the time reported in the log. As you said previously, this works without warning before, so it is clearly the server-side change.
0
Answers
-
Hi @yongguang.wang,
The error indicates that you likely do not have valid OAuth grant credentials. When you registered for this service, did you receive a Welcome email that provided you a username and password? If so, did you go through the Quick Start Guide to ensure you have proper access?
thanks.
0 -
Are you testing with the EMA C++ example from the RTSDK package?
If it's one of our examples, Can you let me know the command-line arguments you use to run the example?
You can also try your account with the 113_MP_SessionMgmt example; it is an OMM Consumer application example that demonstrates the basic usage of the EMA library in accessing
and parsing OMM market price data from Refinitiv Real-Time - Optimized.
0 -
I got exactly the same behavior with EMA C++ Linux sample Consumer 113. Thanks!
0 -
Have you modified any codes before running the app? Or you just build it and then run the app with -username <RDP Username> -password <RDP Password> -clientId <appkey>
Can you try the below curl command with your account on the Linux box? It can help confirm that your login is valid.
curl --location --request POST 'https://api.refinitiv.com/auth/oauth2/v1/token' --header 'authorization: ' --header 'content-type: application/x-www-form-urlencoded' --header 'accept: application/json' --data 'grant_type=password&username=<RDP Username>&scope=trapi&takeExclusiveSignOnControl=true&client_id=<Your App Key>&password=<RDP Password>'
0 -
Thanks a lot, moragodkrit.chumsri_1!
No code changes.
I just executed the curl command and got a long string of access_token.
Please let me know if you get more info about it.
Regards
0 -
-What version of RTSDK you currently use?
-Did you found the issue after running the application for a while? or you found the error immediately after starting the app?
As far as I understand, the error message is related to the token management that the Reactor fails to use the refresh token grant type to renew the access token, and the Reactor tries to use the password grant type instead. The 240 seconds is the default token reissue interval and 10 seconds is the default retry internal using the password grant type.
Anyway, I can't replicate the issue with the latest version of RTSDK 2.x. I leave it running for a while, and it can run and get the refresh token as usual.
To verify the issue at the application level, please turn on the REST API log. There is the message log for the REST API call that EMA interacts with the RDP Authentication service.
Please add the following log to EmaConfig.xml; if you are using example 113, it should be added under the Consumer_4 section.
<Consumer>
<Name value="Consumer_4"/>
<ChannelSet value="Channel_4"/>
<Logger value="Logger_1"/>
<Dictionary value="Dictionary_1"/>
<XmlTraceToStdout value="0"/>
<RestEnableLog value="1"/>
<RestLogFileName value="Restlog.txt"/>
</Consumer>
You can find additional config from EMACPP_ConfigGuide.pdf provided under folder Docs from RTSDK package.
Ema will generate Restlog.txt under the running directory; it contains the REST API messages EMA sends and receive from the server. We can review the parameters from the log. If it appears to be an incorrect message from EMA, you can directly open a case to the EMA development team.
0 -
Thank you very much for you info!
We are using Electron SDK 1.5.
You are absolutely right that the error message shows up 4 minutes after startup.
I will try the config changes you suggested above.
Regards,
Yongguang Wang
0 -
I added your suggested config entries and got the following error log.
Regards,
Yongguang Wang
loggerMsg
TimeStamp: 15:30:55.073
ClientName: ChannelCallbackClient
Severity: Warning
Text: Received ChannelDownReconnecting event on channel Channel_4
Instance Name Consumer_4_1
RsslReactor 0x0x2502fd0
RsslChannel 0x(nil)
Error Id -1
Internal sysError 0
Error Location
Error Text </r/emalib_dbg/Cpp-C/Eta/Impl/Transport/rsslSocketTransportImpl.c:7915> Error: 1004 HTTP Tunneling not supported for this platform.
loggerMsgEnd
0 -
I added your suggested config entries and got the following error log.
Regards,
Yongguang Wang
loggerMsg
TimeStamp: 15:30:55.073
ClientName: ChannelCallbackClient
Severity: Warning
Text: Received ChannelDownReconnecting event on channel Channel_4
Instance Name Consumer_4_1
RsslReactor 0x0x2502fd0
RsslChannel 0x(nil)
Error Id -1
Internal sysError 0
Error Location
Error Text </r/emalib_dbg/Cpp-C/Eta/Impl/Transport/rsslSocketTransportImpl.c:7915> Error: 1004 HTTP Tunneling not supported for this platform.
loggerMsgEnd
0 -
Have you modified any other configuration in EMAConfig.xml?
Basically, the configuration I just provided is just a config to log the REST API connection, and it does not relate to the REST connection to the Streaming Server. The log seems to be the connection issue between the example app and the Refinitiv RealTIme-Optimized.
Is there any Restlog.txt generated in the running directory?Do you still found the issue when restoring the configuration to the original config?
0 -
Can you download and try the example from the latest version of RTSDK 2.0.0.L1?
0 -
No other modifications.
Is EMA v1.5 still supported?
What does the following error message mean?
Error Text </r/emalib_dbg/Cpp-C/Eta/Impl/Transport/rsslSocketTransportImpl.c:7915> Error: 1004 HTTP
Regards,
Yongguang Wang
0 -
Version 1.5 still supports, but the error message seems to generate when setting the wrong ChannelType. Actually, I want you to test using the setup explained in Quick Start Guide and then add the following config to the Consumer config you currently use.
<RestEnableLog value="1"/>
<RestLogFileName value="Restlog.txt"/>If you currently use RTSDK 1.5 and example 113 use Consumer_3, you must add it to Consumer_3.
The original error shows that you are using Consumer_3, but the latest message you provided seems to be Consumer_4 instead. This causes incorrect Channel settings in this case. Note that I use Consumer_4 because the codes in Consumer.cpp from RTSDK 2.0 use Consumer_4 by default.
You can find the following codes to see the difference between the codes from different versions of Consumer.cpp(RTSDK2.0 vs. 1.5). Note that the structure of the EmaConfig.xml has been changed in the latest version.
From RTSDK 2.0 package
// use the "Consumer_4" to select EncryptedProtocolType::RSSL_SOCKET predefined in EmaConfig.xml
EmaString consumerName = "Consumer_4
if (connectWebSocket)
{
// use the "Consumer_5" to select EncryptedProtocolType::RSSL_WEBSOCKET predefined in EmaConfig.xml
consumerName.set( "Consumer_5" );
}From 1.5 package
// use the "Consumer_3" to select EncryptedProtocolType::RSSL_SOCKET predefined in EmaConfig.xml
EmaString consumerName = "Consumer_3";
if (connectWebSocket)
{
// use the "Consumer_4" to select EncryptedProtocolType::RSSL_WEBSOCKET predefined in EmaConfig.xml
consumerName.set( "Consumer_4" );
}The original problem you found is that the application found an invalid_grant error when the application re-requests the access token. It’s not the first time the app tries to get a token, so I suspect that EMA might send incorrect grant_type with some invalid parameter to the Authentication Server, there is the reason we need to turn on the REST log file. Also, I suggest you update to the latest version of RTSDK or test it with the latest version because if the problem does not occur with the latest version, it could be some bug, and it is already fixed in the latest build.
0 -
Thank you very much for your reply.
I added your suggested config entries to Consumer_3. But the parameters were not accepted by v1.5 app using Consumer_3 to and got the following error log.
We use v1.5 company wide and we try to be consistent. This "grant error" did not happen before. It just appeared in recent weeks. We did not change our code at all.
Regards,
Yongguang Wang
loggerMsg
TimeStamp: 23:14:57.856
ClientName: EmaConfig
Severity: Error
Text: unsupported configuration element [RestEnableLog]; element ignored
loggerMsgEnd
loggerMsg
TimeStamp: 23:14:57.856
ClientName: EmaConfig
Severity: Error
Text: unsupported configuration element [RestLogFileName]; element ignored
loggerMsgEnd
loggerMsg
TimeStamp: 23:14:57.856
ClientName: EmaConfig
Severity: Error
Text: unsupported configuration element [RestEnableLog]; element ignored
loggerMsgEnd
loggerMsg
TimeStamp: 23:14:57.856
ClientName: EmaConfig
Severity: Error
Text: unsupported configuration element [RestLogFileName]; element ignored
loggerMsgEnd
loggerMsg
TimeStamp: 23:14:59.185
ClientName: ChannelCallbackClient
Severity: Success
Text: Received ChannelUp event on channel Channel_3
Instance Name Consumer_3_1
Connected component version: ads3.4.2.L1.linux.tis.rrg 64-bit
loggerMsgEnd0 -
The message was generated from the server. I can think of two possible causes for the issue.
1. It's some bug in RTSDK 1.5.0, and EMA sends invalid parameters when it tries to get a new Access Token. And it may occur in some specific scenario, so it's not happened previously. Anyway, I can't replicate it in my env, so I can't confirm.
2. It's a problem on the server-side. If you often found the issue, you might need to open a case with RDP Support to verify the request message that the server receives from your EMA application. The team should check what parameter the application sends to the server and cause the error message.
Actually, I'm using 1.5.1.L1, and it's the first version that introduces the EMA configuration to log the REST API message. It was created to investigate the issue, like the error you found. I would recommend you to use 1.5.1 or update it to 2.0.0.L1 instead. There are many changes in EMA internal codes. It may help resolve the issue as well. Note that when you found any issue in 1.5.0 and it is still reproducible in the latest version, the Development team will fix it based on the latest version's codes rather than fix it in the version you are using.
0 -
I just tried 113 using RTSKD2.0.0 and got the same error. Please see the error log appended below. Should we just ignore it since it is only a warning?
I also have the Testlog.txt file. Please let me know if we can extract any info from it.
Regards,
Yongguang
loggerMsg
TimeStamp: 22:27:01.031
ClientName: ChannelCallbackClient
Severity: Success
Text: Received ChannelUp event on channel Channel_4
Instance Name Consumer_4_1
Connected component version: ads3.4.2.L1.linux.tis.rrg 64-bit
loggerMsgEnd
loggerMsg TimeStamp: 22:31:04.547 ClientName: ChannelCallbackClient Severity: Warning Text: Received Channel warning event on channel Channel_4 Instance Name Consumer_4_1 RsslReactor 0x0x1a18740 RsslChannel 0x(nil) Error Id -1 Internal sysError 0 Error Location /local/jenkins/workspace/ESDKCore_RCDEV/OS/RH8-64/rcdev/source/rtsdk/Cpp-C/Eta/Impl/Reactor/rsslReactorWorker.c:3441 Error Text Received HTTP error 400 status code with data body : {"error":"invalid_grant" } .loggerMsgEnd
0 -
Sorry, I can't download or open the file.
Anyway, It sounds like that your application can run after receive the warning? If so, I believe that EMA may try to get the token again after failing and generating the warning. If it's the case, I believe that you can ignore the warning message.
0 -
Thank you very much for you reply!
After the "grant_error", there are still updates flowing down. But, we are not sure about the state of the connection and whether the performance of the connection is down-graded. I think we still need to know the root cause of the warning and even better to fix it.
I can email the Restlog.txt to you
Regards,
Yongguang
0 -
Please let me know how should I sent the Restlog.txt file to you. By email?
Regards,
Yongguang
0 -
It looks like the file contains some sensitive information; therefore, It gets blocked by the system.
Can you send an email to moragodkrit.chumsri@refinitiv.com? Hopefully, the email system will not block the attached file.
You can also use https://thomsonreuters.sendthisfile.com/ to send the file to me.
0 -
I have faced the same issue and dug deeper. According to what I found retrieving an auth token using the refresh token always fail. So authentication logic falls back to using username+password combination with the given warning.
Code:ReactorTokenSession.java:361
else
{
_sessionState = SessionState.REQ_AUTH_TOKEN_USING_REFRESH_TOKEN;
_restAuthRequest.grantType(RestReactor.AUTH_REFRESH_TOKEN);
_restReactor.submitAuthRequest(_restAuthRequest, _restConnectOptions, _authTokenInfo, _errorInfo);
}0 -
I have faced the same issue and dug deeper. According to what I found retrieving an auth token using the refresh token always fail. So authentication logic falls back to using username+password combination with the given warning.
Code:
ReactorTokenSession.java:361 else{
_sessionState = SessionState.REQ_AUTH_TOKEN_USING_REFRESH_TOKEN;_restAuthRequest.grantType(RestReactor.AUTH_REFRESH_TOKEN);_restReactor.submitAuthRequest(_restAuthRequest, _restConnectOptions, _authTokenInfo, _errorInfo);}0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛