11

I want to do a simple HTTP request in C#, but something is not working and all I got is 403 Forbidden status code.

When I try to do same request in Postman, everything works fine. I tried to run Fiddler and see all headers that are being sent by Postman. I copy-pasted all of them, but i still got 403 Forbidden in the request sent by C# code.

C# Code (Using https://flurl.dev):

public static void Main(string[] args)
{
    FlurlHttp.Configure(settings => {
        settings.HttpClientFactory = new MyClientFactory();
    });

    var url = "https://example.com"
        .AppendPathSegments(new[] { "v1", "oauth", "accesstoken" })
        .SetQueryParam("grant_type", "client_credentials")
        .AllowAnyHttpStatus()
        .WithBasicAuth("username", "password")
        .WithHeaders(new {
            User_Agent = "Something/0.4.0 Dalvik/2.1.0 (Linux; U; Android 5.1.1; SM-G975F Build/NRD90M)",
            X_Secret_Header = "secret_encoded_value",
            accept_encoding = "gzip, deflate",
            Accept = "*/*"
        });

    HttpResponseMessage msg = url.GetAsync().Result;

    Console.WriteLine("StatusCodeString: " + msg.StatusCode.ToString());
    Console.WriteLine();
    Console.WriteLine(msg.Content.ReadAsStringAsync().Result);
}

class MyClientFactory : DefaultHttpClientFactory
{
    public override HttpMessageHandler CreateMessageHandler()
    {
        return new HttpClientHandler
        {
            AllowAutoRedirect = false
        };
    }
}

C# Request And Response:

CSharp Request in Fiddler CSharp Response

Postman Request And Response:

Postman Headers Postman Response Postman Response in Fiddler

Can someone explain me why is this not working? Same headers, same everything.

I replaced the url with "example.com" because i don't want to show the real API URL here.

Also sorry for so many images.. I don't know how to show the problem here in other way.

modugnico
  • 111
  • 1
  • 1
  • 5

8 Answers8

15

From Postman there should be a link on the right side called code. Click that and then select C# to get the code generated by Postman. Paste that in and try it out.

Brian Olson
  • 241
  • 1
  • 7
  • The code generated by Postman does not work in .NET Framework applications when you're setting the Cookie header explicitly. To send cookies, you need to specify the handler in the HttpClient constructor, and either use `UseCookies = false` in combination with manually setting the Cookie header, or use `CookieContainer` instead. – Rudey Jul 05 '23 at 16:54
7

For me the problem was the TLS settings in C#. Try adding this line at the start of your app or just before your HTTP request code:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Ocean Airdrop
  • 2,793
  • 1
  • 26
  • 31
3

I know this old, but to get the same C# code as postman sent, let the postman generate the code for, but first you must get RestSharp lib from nuget or from PM console type this:

Install-Package RestRequest -Version 1.2.0

Steps:

1- Call your rest api from postman

2- Press the code button enter image description here 3-A pop-up window will open, then choose whatever language you want, in your case it's C# enter image description here

Mostafa Hassan
  • 288
  • 1
  • 14
3

Just to help anyone searching - there can be multiple reasons for such an error.

Steps to help debug such a problem.

  1. Download Fiddler (or an equivalent like Wireshark) to record the network traffic.
  2. Make the working request through postman (recording the traffic)
  3. Make the failing request through C# (recording the traffic)
  4. Look at what's different between the two requests.

In my case, I was getting quotation marks in my authentication. It was a subtle difference that I didn't realise until I compared the two

Working Call (200 OK)

working call viewed with fiddler

Failing Call (401 unauthorized)

failing call viewed with fiddler

JsAndDotNet
  • 16,260
  • 18
  • 100
  • 123
2

My suggestion would be retrieving raw request strings from postman and C# application and using something like https://text-compare.com/ to look for differences. The guess is there's some extremely minor difference like extra slash that is very difficult to notice with plain eye.

ErBu
  • 355
  • 2
  • 7
  • 1
    I compared the request strings using the site you provided, but the result says: "The two texts are identical" – modugnico Jun 30 '19 at 14:45
2

I had similar issues and all answers here didn't work. I was getting a 403 on in my C# client but it was working well in Postman. After a few hours, and following @JsAndDotNet advice to use fiddler, I found out the server was bouncing all requests without User-Agent.

One way to be sure is to check the response. In my case, the response was supposed to be in json, but I was getting a text/html which indicates that the server was seeing my request as emanating from a browser and hence blocking it.

Specifying my own User-Agent (any random string really) fixed the problem

elfico
  • 450
  • 1
  • 6
  • 13
1

The next step would be to compare the Raw requests and responses, from your C# code and Postman, place them side by side and compare the differences - I assure you there would be at least one. :-)

403 is an authorization problem so the token would be the first suspect, since the bad structure of your request is more likely to throw a 400 "Bad request" error.

In this particular case though, I've run your code in VS2019 on my machine using Flurl and it seems to be working fine. It returns an example HTML page:

<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">
    body {
        background-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;

    }
    div {
        width: 600px;
        margin: 5em auto;
        padding: 50px;
        background-color: #fff;
        border-radius: 1em;
    }
    a:link, a:visited {
        color: #38488f;
        text-decoration: none;
    }
    @media (max-width: 700px) {
        body {
            background-color: #fff;
        }
        div {
            width: auto;
            margin: 0 auto;
            border-radius: 0;
            padding: 1em;
        }
    }
    </style>
</head>

<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is established to be used for illustrative examples in documents. You may use this
    domain in examples without prior coordination or asking for permission.</p>
    <p><a href="http://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>
Duck Ling
  • 1,577
  • 13
  • 20
  • 1
    i replaced the actual url with "example.com" because i don't want to show the real api here – modugnico Jun 30 '19 at 14:39
  • 1
    Okay, so your code works. Now Go to Postman "Authorization" tab from the working example and check if the token you're using is the same as the one you have in your VS code – Duck Ling Aug 03 '19 at 21:15
1

in case this helps anyone. I had the same problem with an api I was calling and was at a bit of a loss because everything including the authorization header seemed exactly the same between postman and visual studio. But when I really looked carefully at fiddler i noticed that when using postman, the api that was being called was https://api.someplace.com/properties/?pagesize=20 and in visual studio i had https://api.someplace.com/properties?pagesize=20

Note the lack of the slash between "properties" and the querystring. "...properties/?..." worked fine and "...properties?..." resulted in a 403.

I think (obviously correct me if I'm wrong here) that what actually happened was that in the first http call, where the slash was missing, the server made a HTTP 301 redirect to the api with the slash. When the redirect happened the authorisation header was not carried along for the ride and this resulted in a 403 authorization error.

Now why this redirect was necessary I dont know, any apis I build allow for both scenarios and no redirect should be necessary. But in the end, I simply changed the url to be "../properties/?etc..." and the problem went away.