Yeah I would put that monster back in its cage and walk away slowly.
1 Like
I hope that James and his company are not reliant on EWA working as a critical part of their system/success!
1 Like
It works… just… slowly 
I thought it was just something with our setup…
EWA is just not very efficient. EWA is one of the foundational reasons why we decided to go a different direction, and completely redesign the screens to run in the new UI with web native functionality in Kinetic.
The technology behind EWA is actually amazing… it is amazing because it works, and it is amazing how it works. to create an EWA Client, there is a program generator that literally converts the C# code into Javascript. Those two languages are not as similar as they would need to be, and so there is a lot of code manipulation. As a result, it sends LOTS of code over the interweb, and it is not the most efficiently written code when you convert C# to Javascript… but amazingly, it does work…
I would only use it sparingly, and instead, spend your time working towards upgrading to Kinetic.
2 Likes
Yes, Develop our own Mobile App. 
1 Like
Thank you for your reply Tim!
I’m curious if anyone is aware that a couple of the JQuery scripts being used in EWA have vulnerabilities? Additionally, the JQueryUI.js script in EWA apparently has a XSS vulnerability. This is of major concern if the site is open on the net and not the company intranet. We are pursuing EWA for offsite Union/contract employee’s that do not have company hardware, thus no direct access to our VPN. Initially this was going to be done via a publicly available site, but it seems we may have to change direction on that. I used a chrome diagnostic tool called “Lighthouse” on the EWA website and it threw quite a number of issues! Among those were design, development, and security issues. (JQuery)
1 Like
I suspect this is true for a lot of apps, the later versions of Epicor may have a slightly different versions of these libraries @Gideonn
I would recommend to (never) put EWA (or Epicor as a whole) on the WAN.
2 Likes
Understatement of 2022 Award Winner!
True but Epicor (CORP) Isn’t doing this any favors with their wide open cloud offering. I stand by it though, my ERP shouldn’t be on the WAN too many potential holes… also last I checked my user’s “passwords” were still mostly… Monkey1234 
Mark,
Do you think that James could utilize some sort of azure virtual desktop and set up a VPN using Azure VPN gateway between the application server and the virtual desktop and then install Epicor on the virtual desktop?
I know James said that he can’t allow VPN, but maybe there is enough granularity to limit the routes over the VPN so that they can only access the Epicor resources.
Another issue James may have is the regulatory issues of using cloud and would have to pay for dedicated servers. Not sure… Just a thought.
Depending on the VPN software you can create different access groups that give access to only certain boxes or sites.
You could have a VPN that only allows access to Epicor over 443/8008 once connected to the VPN and nothing else.
1 Like
That’s what I was trying to figure out with Azure VPN Gateway- I am still learning about what you can do to route traffic to on prem resources and how much control there is.
Networking is not my strong suite.
Thanks for the info Jose.
1 Like
So what does “wide open” mean here? If we’re talking about BasicAUTH, Epicor does provide login access with OAUTH2 via Azure AD so it’s possible to have MFA and have conditional access rules with their cloud product. It’s on the users who don’t use that. 
Everyone is trying to get rid of BasicAUTH and Epicor is on track to do so.
Is their Azure Data Center wide open access? Not according to anyone who wants ODBC access. 
Are there security features that could be put in front of the app servers like Azure Front Door, Azure Firewall, Azure Private Link/Endpoint, Azure Application Gateway, etc.? Sure.
Tailscale is an interesting alternative to traditional VPNs.
From a Zero Trust perspective, the VPN is generally too permissive of a tool as Jose has pointed out. The goal is to provide access from a well-authenticated resource to another resource, preferable right down to the application and not the entire server. This is doable with modern authentication methods.
1 Like
They don’t have any way of doing it in 10.2.500 as far as I am aware. Is that different for newer versions? I have blurry recollection of whether this changed in 10.2.600 or 10.2.700 or kinetic.
Would you please clarify what you mean by modern authentication methods and which of those are supported by Epicor?
If you do a Menu search and see this, then you have the capability. Somewhat sure that 12.2.500 had it.
Epicor only supports Azure AD today. Other authentication providers are Auth0 or JumpCloud.
A very good explanation of authentication: Modern Authentication (codemag.com)