Repository navigation
RestClient GetJsonAsync parameters in uri and AddDefaultHeader with Authorization #1957
Description
Describe the bug
I was trying to perform some simply GET request using all the methods made available by the RestClient class (GetAsync(), GetAsync<T>() and GetJsonAsync<T>()). The first two requests worked great, but using the third one I found some problems.
In the constructor I added, for the RestClient, the base URL as written in the docs, and an Authorization ApiKey as a DefaultHeader; when performing the request I also added some parameters like the Id and a parameter to add in the query like this example taken from the documentation
var client = new RestClient("https://example.org");
var args = new {
id = "123",
foo = "bar"
};
// Will make a call to https://example.org/endpoint/123?foo=bar
var response = await client.GetJsonAsync<TResponse>("endpoint/{id}", args, cancellationToken);Unfortunately this request give me a BadRequest when all the other methods work perfectly. It seems that the DefaultHeader Authorization, previously added, it isn't considered when performing the GET request but I don't have a specific error log.
To Reproduce
I don't have any test to show you because the test I use to find the error was with sensitive data.
But the code I use is like this:
public TestClient(ILogger<TestClient> logger, IConfiguration configuration)
{
_logger = logger;
_configuration = configuration;
var options = new RestClientOptions(URL);
_client = new RestClient(options).AddDefaultHeader(KnownHeaders.Authorization, APIKEY);
}
public async Task<TResponse> Get(string id, CancellationToken cancellationToken)
{
var parameters = new
{
id = id,
details = true
};
var response = await _client.GetJsonAsync<TResponse>("info/{id}", parameters, cancellationToken);
}Expected behavior
I expect that like the other request if I add my authorization api key in the RestClient with the AddDefaultHeader I can make request without problems and receive the response from the URL.
This url is composed as follows: http://BASE_URL/info/{id}?details=true
Stack trace
at RestSharp.RestClientExtensions.<GetAsync>d__14`1.MoveNext()
at WebRestClient.Services.TestClient.<GetCities>d__6.MoveNext() in C:\Users\fcodognotto\Projects\DaprCurse\RestClient\WebRestClient\Services\TestClient.cs:line 53
at Program.<<Main>$>d__0.MoveNext() in C:\Users\fcodognotto\Projects\DaprCurse\RestClient\TestClient\Program.cs:line 12
Desktop (please complete the following information):
- OS: [Windows 11]
- .NET version [.NET 6]
- Version [e.g. 108.0.1]
Activity
alexeyzimarev commentedon Nov 7, 2022
GetJsonAsyncexpects to post the whole object as JSON payload. It cannot figure out what the{id}URL path parameter is and where to get it from.alexeyzimarev commentedon Nov 7, 2022
I am actually wrong. It should parse the object.
alexeyzimarev commentedon Nov 7, 2022
I don't believe the auth header can be ignored. The method code is very simple, it uses the client that's configured by you to make the call, so the header should pass through.
The best way to diagnose the issue is to make a call to https://requestbin.com/ instead of your server, keeping all the other parts intact (auth header, URL and query). You will get a full view of the request, and you can see what parts aren't coming over to the other side.
federicocodo commentedon Nov 8, 2022
@alexeyzimarev Maybe I found the problem, after testing the request call with
GetJsonAsyncin the RestSharp repository and returning me an error, I started looking at the request URL and headers. First of all the URL will be parsed correctly from{id}todetailsset totrue, after checking the tokenId I noticed it was not the same as I provided and I found out how inside the token there is a colon (:) which is converted to hexadecimal (%3A), this token is located in the request URL.Is there any way to prevent it from being converted?
alexeyzimarev commentedon Nov 8, 2022
You mean that in the auth header you get
:encoded? It's weird because header parameters have encoding disabled.federicocodo commentedon Nov 8, 2022
@alexeyzimarev Unfortunately not, the problem lies in the URL, the
{id}which is added after the/info/URL part and before the query string?details=trueFixes #1957
alexeyzimarev commentedon Nov 8, 2022
My PR should allow you to avoid encoding for specific properties.
federicocodo commentedon Nov 10, 2022
I tried to use the attribute on a class and it seems to work perfectly. Is it possible to do something like this with a dynamic object? Otherwise if you can't do it it's not a problem, thank you very much
alexeyzimarev commentedon Nov 10, 2022
As long as the object behind a dynamic object has a type where properties are annotated with this attribute, I think it will work.
stale commentedon Jan 7, 2023
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
repo-ranger commentedon Jan 7, 2023
Fixes #1957 (#1964)