Do you have a redirect on the endpoint by anychance? Have you changed Epicor version at all as V1 is now a tickbox against the user
try using the AuthenticationHeaderValue class:
HttpClient _httpClient;
var password = “abcd”
var KineticUserName = “kineticusername”
var creds = Convert.ToBase64String(
System.Text.Encoding.ASCII.GetBytes($“{KineticUserName}:{password}”));
_httpClient.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue(“Basic”, creds);
I dont think that we have redirect. V1 checkbox marked. Interestingly that this app used on many tablets and today it started failing, now i checked the last working tablet. The app was booted yesterday and it was still working (retrieved responses) but when i restarted app, it stopped working. Can this be related with windows framwork update?
Never say never but I have not had a .net update break something like this. Any firewall changes or endpoint redirects? We had the same issues Monday when we migrated as we had a redirect on the old endpoint to the new.
As of this morning, we’re also getting this 401 Unauthorized error but only when calling BaqSvc from the REST client. We’ve made no code changes and the client has been working forever until now.
All calls direct to the endpoint work fine outside of the client (aka direct via a browser or the ResstHelp interface), or if the client calls the Erp.BO.X endpoints direct as well (are fine).
What’s the takeaway here? That something happened last night that changed now causing this issue?
I’m seeing this too in a lot of places. But not in C# in Node. I think microsoft or someone did something to break.. something… I"m investigating, but its driving me crazy.
What’s the specific call that is failing on your end? And what version of Epicor or .net are you on.
We’re testing right now on a core console application to see if we can reproduce there on the latest rest client.
For now, though, it’s 100% reproducable calling any BAQ via using the V1 client:
dynamic result2 = EpicorRest.DynamicGet(“Erp.BO.CountrySvc”, “Countries”, parameters);
… returns data (including any Erp.BO.XXX call)
dynamic result3 = EpicorRest.DynamicGet(“BaqSvc”, “TI-PartPurchasedDetail”, parameters);
… returns null (no matter the BAQ called)
UPDATE: Just also got it to happen on core running the V2 client, albeit seems intermittent. Dunno, seems squirrely (how you like that descriptive @klincecum?)
That’s interesting to note @josecgomez … when we visit the endpoint in the browser, we can see that it does a redirect to include the / before the query parameters.
…/api/v1/BaqSvc/TI-PartBOMSingleLevel?$top=1000
redirects to
…/api/v1/BaqSvc/TI-PartBOMSingleLevel/?$top=1000
which explains why our manual tests works, but not in the client.
Please tell me epicor don’t change endpoints on their cloud without telling people . This will break any .net program that doesn’t handle redirects (you shouldn’t just accept a redirect as a place to send credentials)
The RestSharp RestClient class has a bool property “FollowRedirects” which appears to initialize to false by default. I am curious what would happen if setting that to true.
It’s not that you cannot do that in a normal .net class it’s, from a security point of view, a bad idea:
var handler = new HttpClientHandler
{
AllowAutoRedirect = false
};
using var client = new HttpClient(handler);
var request = new HttpRequestMessage(HttpMethod.Get, url);
request.Headers.Authorization =
new AuthenticationHeaderValue("Bearer", token);
var response = await client.SendAsync(request);
if ((int)response.StatusCode >= 300 && (int)response.StatusCode < 400)
{
var redirectUrl = response.Headers.Location;
var redirectRequest = new HttpRequestMessage(HttpMethod.Get, redirectUrl);
redirectRequest.Headers.Authorization =
new AuthenticationHeaderValue("Bearer", token);
response = await client.SendAsync(redirectRequest);
}
UPDATE: For anyone needing an immediate fix who’s using the RestClient, this was the workaround we implemented for BAQSvc calls.
dynamic result = EpicorRest.DynamicGet(“BaqSvc”, “TI-PartPurchasedDetail/”, parameters);
We just simply applied the extra “/” to the end of the BAQ name, which the RestClient then uses in the string formatting to achieve the correct URL (see previous post).