APIToken service throws HTTP 403 to our request
Log:
GetAPIToken HTTP Request: grant_type=password&username=GE-A-00173750-3-4555&scope=trapi&client_id=GE-A-00173750-3-4555&password=xxx&takeExclusiveSignOnControl=true
2021-05-03 13:45:49.843 +00:00 [Information] ApiTokenServiceElectron: GetAPIToken HTTP Response: <html><head><title>403 Forbidden</title></head><body><center><h1>403 Forbidden</h1></center></body></html>
APITokenService URL: https://api.refinitiv.com/auth/oauth2/v1/token
Best Answer
-
I don't say that the whole service is wrong, what I say, it doesn't work with my credentials, although it should, and have been working for half a year.
This is the reason I wanted you to check a Refinitiv provided sample. There is no other way for us to identify if the issue is in your code, or with your entitlements. We do know passing machine ID as client ID is not correct - which is what your application is doing.
You can contact your Refinitiv account manager to check your credentials.
0
Answers
-
Hi @laszlo.torok,
What is this function GetAPIToken and which language/API are you using. If you are new to Refinitiv Real time optimized, then please start from this quickstart and use the provided samples to test it out.
This error message is not originating from Refinitiv systems.
0 -
Also note that you are using your machine ID as client ID. The application needs to pass a unique client ID, which you can be generated from AppKeyGenerator.
See the quickstart linked in previous response.
0 -
I'm sorry, this is message IS from the URL I provided. We have been using exactly this HTTP request for at least half a year now, then on Friday, suddenly, the API token service started to throw this error. The goal of the call would be to get an authentication token from the token service.
0 -
The limited information that you are providing isn't helping in diagnosis of the issue. The URL cannot be invoked in a browser - if that is what you are asking. I just tried it getting token in an application and was successful.
If you are getting HTTP 403 - Forbidden, there will be additional details in the JSON message like this:
{
"error": "invalid_client",
"error_description": "Invalid Application Credential."
}Can you try to download the sample as mentioned in the quickstart and follow all the steps and let us know if this is still an issue for you.
Are you using EMA, if so which language and version?
0 -
I don't use the URL from a browser, but from C# code.
response = await httpClient.PostAsync(authTokenUrl, httpContent);
string result = response.Content.ReadAsStringAsync().Result;
authTokenUrl: the URL I provided above.
httpContent: provided above.
result: <html><head><title>403 Forbidden</title></head><body><center><h1>403 Forbidden</h1></center></body></html>
I don't need a sample, as this code have been working for half a year, and your service started to throw HTTP 403 since Friday.
From my perspective, it doesn't matter if your sample works or not, as you tried it with different credentials. Which really matters is why it doesn't work with these credentials.
I don't say that the whole service is wrong, what I say, it doesn't work with my credentials, although it should, and have been working for half a year.
0 -
And I will repeat this again:
<html><head><title>403 Forbidden</title></head><body><center><h1>403 Forbidden</h1></center></body></html>
This error message is not originating from our servers. Your C# library responsible for REST call is generating it.
0 -
"You can contact your Refinitiv account manager to check your credentials. "
That person sent me here, stating that Refinitiv support works here..
"This error message is not originating from our servers. Your C# library responsible for REST call is generating it."
You can repeat it as many time as you want, but it doesn't solve the problem, just show your attitude. The response sent by your server cannot be parsed as JSON, that's why I'm restricted to the pure HTTP response. It's an empty HTTP 403, without JSON content.
Anyway, this is not what I expect. I expect support to investigate why their service throws HTTP 403, instead of working with the same way with same credentials for half a year.
I understand, in your opinion passing the same thing as username and client_id is wrong, but then how it it has been been working or months? And if it has been working, my expectation is:
- It should work the same way towards
- Or YOU should investigate why it doesn't work not me.
0 -
Hello @laszlo.torok,
It's unfortunate that you have encountered this issue, that the code that have been working, have suddenly stopped working, you have not made any changes on your side just prior, is my assumption on this correct?
If this is the case, one possible and very likely cause is your machine id's permissions having expired or been updated.
The best course of action is, as suggested by @Gurpreet, to contact your Refinitiv account manager directly, who can help verify your RDP credentials, and will be able to request your RDP password reset, if required.
The moderators of the forums can be of help with Refinitiv API usage questions, but not with permissionining issues, at least not directly.
In this instance, we have also contacted your organization's Refinitiv account manager, to let them know of this issue.
However, looking at the worst case scenario, if, once the creds are verified and password is reset you continue facing the issue, this would mean that the credentials remain valid and permissioned, and the solid next step would be to test with the standard example that is included with Quickstart Guide , to verify if the issue is originating within C# code/config, as discussed by @Gurpreet.
0 -
I just tested the get token endpoint with both client id or machine id as client id input and both of them work fine:
If the code has been working fine before, are you aware of any network policy/firewall/proxy changes in your company?
I believe that this may be related.
By the way, if the issue is related to your machine id permission (I don't think this is the case).
You still have to contact to Helpdesk to investigate the account permission issue.
Thanks for your understanding.
0 -
No, we haven't changed the code, and I'm not aware of network changes. Anyway, it doesn't seem to be a network/firewall problem, as we can access the server, just the response is not what I expect. I'm going to ask the Account Manager.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 中文论坛