You know, you might just have a bad web.config - Epicor by default ALWAYS sets atleast since 10.2 and I’ve even seen it in my 10.1.500.46
<add key="CorsOrigins" value="*" />
If you did not have that key you might want to take the web.config.template and compare it to your web.config - it is in the same folder.
I have seen users struggle in 10.2 yet somehow they are using a 10.1.400 or 10.1.500 web.config where stuff is diff, and ordered differently, even some versions for OWIN are used are different. because they did not rebuild their AppServer during Major Upgrades, bu merely “Upgraded it” which is a no-no.
Also you must understand your error, you might get “GET/POST/PUT/PATCH” to work, it is the “OPTIONS” that isn’t working. You want to be authenticated to execute “GET/POST/PUT/PATCH” but not necessarily for “OPTIONS”.
You can enable, disable and kill CORS all day long, if the OPTIONS Verb is not allowed you will rarely win.
Your Issue is a generic OPTIONS is Excluded from Honoring any Rule whatsoever. Its not a Client Side Issue, you can grab all the tools in the world to fake headers - your OPTIONS Verb will always say “No Thanks” on the Server Side.
I tried all of the above suggestions as well as others I found on SO and what mattered in my situation was we had Request Filtering enabled on IIS and the OPTIONS HTTP Verb was not in the list of allowed verbs. Once I added it I was able to sort out the rest of it.
In our case it was request filtering in IIS disabling OPTIONS verb at the root web application level. Open up IIS Manager, click on root application, click on Request Filtering, if OPTIONS appears in list either remove or Allow Verb. Wish I had checked this first as lots of wasted time.
It’s always been a culprit of a bad web.config
In our case I always say SSO / WebDAV was the culprit because we couldn’t even open the “Active Homepage”. If you have SSO it wouldnt work, because if you go to get a token to the Token Service it will ask you to login with your Windows Creds first – well how can a web app grab a token if SSO is saying no. =) Perhaps its just us having a misconfig in WebDAV.
Perhaps in Epicor Case its to remove the Handlers for it to avoid Auth for the preflights – inspect you web.config vs web.config.template and if you are using SSO WebDAV you might need to enable more things…
Examples of what it should look like:
Perhaps once again your using an older web.config or need to do
Good Luck.
EDIT:
As a matter of fact our ERP Admin Upgraded our Test Environment, while he Rebuild our DEV Environment look at the difference both 10.2.300.13
Test since its an older web.config exhibits all kinds of API Issues. Token, fix that, then its something else etc…
While DEV Works fine.
Conclusion
Make sure your web.config is up-to-date by comparing it to a fresh AppServers web.config or web.config.template (which may or may not be up-to-date) or reaching out to a community member to share their web.config for your version. Even better rebuild your AppServer, you can change web.config values and versions but you might not have the proper new versions if you did an Upgrade and not a Rebuild.