Did API v1 of Erp.BO.PartSvc/Parts Change Over the Weekend?

Kinetic ERP
41

Here’s a reference. Which shouldn’t be necessary but.

Following one of the recent minor updates I had to update some work to percent encode " to %22. Sending a percent encoded parentheses before the update failed, only literal parentheses matched. Meanwhile, # has always needed to be encoded as %23 for as long as I’m aware. I’m currently passing / over API V1 and V2 with great success.

It kinda looks like developers have been handwriting percent encoding one character at a time, ticket by ticket, applied SaaS client by SaaS client. Surely not though? Everything in the process has some kind of .urlencode(), some by default requiring manual intervention to disable it.

42

So I just did a bunch of tests with an nginx Proxy

 proxy_pass https://myEpicor.stephengould.com; #Works Fine

 proxy_pass https://myEpicor.stephengould.com$uri$is_args$args;

blows up erro 400, Bad Gateway (if the part has slashes)

location / {
    set $backend "https://myEpicor.stephengould.com";
    proxy_pass $backend$uri$is_args$args;

}

Gives a Path Undefined Error (for slash parts) 404

image
image1216×220 15.8 KB

         proxy_pass https://myEpicor.stephengould.com;
         proxy_set_header X-Original-URI $request_uri;
    # Force nginx to use the normalized URI
         rewrite ^ $uri break;

Also gives an error if slashes are included

So… Im’ not sure what this proves other than yes if you configure the nginx Linux proxy (incorrectly) you can get it to pass in the decoded URI and it will cause Epicor to balk wiht a 400,500, and or a 404 Error.

43

What do you think of the fact that you are getting the error I had on the windows env and not the error I got on the linux?

44

Not sure, there are 300 ways to configure that proxy so maybe there’s a combination that causes that other error?

45

Thank you and @Evan_Purdy for taking the time to test this. It’s greatly appreciated. I’ll keep this updated as I learn more.

46

One possibility.

47

@kananga So you have no issue with parts with / on linux and windows? Or are you on prem

48

We’re SaaS

49

have you tried this particular end point? The RPC GetByID gave me no issues but the specific odata mentioned did.

50

Coincidentally that example was the same endpoint, plus a couple of BAQ’s.

51

Gosh, I would think each cloud container would be set up mostly the same. Are you flex or current? Gov cloud?

52

Thank you again, Jose. Support confirmed this is due to a misconfigured ngnix proxy.

53

SWEET! Did they fix it?

54

They only communicated that the issue has been identified. I’m still waiting to hear when it will be fixed, and will post here once I know.

55

It sounds like all their Linux NGINX Proxies are configured the same way since Evan is also seeing this. So I’m sure you will but they probably need to figure it out for everyone

Oy

56

I’m still a bit confused why my live (windows) gave an error as well :thinking:

57

Your live Windows Error was I believe because the URLEncode didn’t work in that SWAGGER version. If you call it in POSTMan it works (at least it did for me)

58

I reported this on my Live (windows) instance. They updated the proxy in anticipation of the Linux move, and that’s what’s causing the issue. So it’s Linux related, but by association (this is my guess - not confirmed).

59

If you look at my screenshot the request URL looks properly encoded but not in the response body.

@spaceage so by your theory they haven’t prepped @kananga for Linux yet? Why is he so lucky :laughing:

60

I mean, he’s incredibly good-looking….so he’s got that going for him - which is nice :rofl:

There are a ton of US-Central based customers, and since my guess is that this was in anticipation of the Linux move in Spring, splitting up maintenance could make sense??