Working in Browser? Really?

Yeah, I use multiple desktop browsers depending on tasks, e.g.
Firefox with NoScript for general browsing, forums, etc… clear everything on exit
Chrome for personal, online accounts that involve transactions - allow password saves, clear everything else on exit
Edge for email accounts and business apps - allow password save and clear ALMOST everything else on exit

May be overkill but so far I’ve not had any security “disasters”, gives me at least a little peace of mind.

2 Likes

So in a nut shell…

The suggest to “Clear the client cache” will be replaced with “Delete cookies … and clear cache”

The biggest thing to realize is how customizations are implemented in the browser based method.

As for the security concerns, my initial thoughts were about the ability for a user to change values in a browser field, even if they are read only. If the field security system (say for R/O fields) in the client version version relied on the data passed to the client not being able to be changed by the client program, then it works.

So the security in a browser based system must be 100% handled at the server end. If field security has certain fields as hidden, their values shouldn’t be passed to the browser at all. You can’t rely on code in the browser (aka javascript) to keep it hidden. But if that info was required for updating some other fields, those couldn’t be done client side.

Imagine the discount% is hidden for a certain user/sec group. During order entry, the discount amount is calculated based on the discount %. I know this is poor example - as one could easily deduce the discount% from the original ext price and the net price. But it is just to show where the info must be known (to the client or browser), and how the information is used.

I’m probably way wrong on how any of this works, but I think it’s something like…

Client Based

  1. In Order Entry, open fetching an order (or making an new one and setting the customer) the discount% is included in the data sent to the client.
  2. The client knows the current user should not see the discount% so it alters the control to hide/obscure it. But the actual discount% is in the underlying dataset.
  3. A line changed (but not yet saved), and the discount amount is calculated and displayed. This all happened on the client with no interaction by the server.
  4. The line is saved and the OrderDtl data (including the discount amount) is updated on the server.

Using the same security methods within the browser version, would be similar. But the user can easily hit F12 in the browser and find the data that isn’t being displayed. If the new discount amount is calculated in the browser (say after a qty change) , that discount% needs to be available to the code running in the browser.

Browser Based

  1. In Order Entry page, fetching an order (or making an new one and setting the customer) the discount% is included in the data sent to the browser.
  2. The info sent to the browser tells it to the current user should not see the discount% so it alters the control to hide/obscure it. But the actual discount% is in the underlying dataset.
  3. A line changed (but not yet saved), and the discount amount is calculated and displayed. This all happened in the browser with no interaction by the server.
  4. The line is saved and the OrderDtl data (including the discount amount) is forwarded to the server to process.

In order to make the browser version secure, it needs to have practically no code running that would be related to the actual transaction data. So changing the qty would trigger a call to the server to recalculate the discount amount for this record and return it to the browser to update the UI - but not actually update anything on the server end yet.

1 Like

And so should the .NET client.

If we just protect in the .NET Client then I can use:

  • DMT
  • Service Connect
  • REST
  • BLTester

to get around client security in BOTH .NET and the browser. So why not secure everywhere at once?

And, unlikely as it may be, debug works just as fine in Visual Studio on .NET applications as F12 does for browsers.

3 Likes

I like Edge is a nice browser, but why use the imitator when you can have the real thing. Also I hate BING and it insists on pushing that

but Edge is a fine browser its the same shz as Chrome

2 Likes

I assume you mean Chrome is the real thing?

You can change the search engine to Google.

Edge browser with Google SE… This is the way

3 Likes

This is the way.

3 Likes

image

4 Likes

Deep linking is a compelling feature for web vs desktop app for sure, but have you found a way to perform deep linking in the Kinetic Web UI? I have been looking for a way to pull up a specific quote for example, but I’ve had no luck thus far.

Yup, per one of the teachers at my EE classes (Patrick Ferrington). He said it will be gone by the end of 2024. That’s a HUGE deal for us, security-wise and as soon as I got home from Insights I started coordinating with the higher-ups to get everything running smoothly for the inmates in the cloud when the time comes.

2 Likes

Hey Lee,

Deep linking starts with 2022.1 according to Tim Shoemaker:

Approval Link in Mail - Kinetic 202X - Epicor User Help Forum (epiusers.help)

2 Likes

Thanks, Mark! I’m glad to see they’ve added that feature since my last investigation.

1 Like

Yes, there is a “Share” option on every app… in this image you can see the share option in the PART table. Once you select it, you can then copy the link and send it via email. The link is a web URL with all the data necessary to recall the part that was displayed. If the user clicks on the link, and they are already logged in, it takes them directly to the screen/record specified. If they are NOT logged in, it asks for their login first, then goes directly to the screen. Its an amazing thing. (oh… and you can build your own deep links too… just follow an example that you share and change the part number/customer id, etc.)

6 Likes

Tim, can we add deep links to to BPM emails, or is it limited to manually sharing via the share button?

Once you have a link you can send it and do whatever you want with it. Email it, share it on facebook, etc!

2 Likes

I just cried a little. :heart:

3 Likes

image

1 Like

@josecgomez - So the link format is something that could be automatically generated by the BPM? Or will it have some guid that the BPM won’t create on the fly? We’re on 2021.2, so I don’t have an environment to see what it looks like yet…

I’m thinking an email alert BPM - i.e. Order# (Whatever#) was put on hold, etc…

Some URL that can be built by the BPM:
https://AppServer/Environment/Apps/Erp/Home/#/view/Erp.UI.SalesOrderEntry?SONum

Or GUID URL that needs someone to manually click on the ‘share’ link to create?
https://AppServer/Environment/Apps/Erp/Home/#/view/Erp.UI.SalesOrderEntry?channelid=a501137a-1d05-4d30-9443-3f9cb772d2a0channelid=a501137a-1d05-4d30-9443-3f9cb772d2a0

  1. I like the idea of having a quick way within a BPM to create a share link. This is a good idea, and someone (@josecgomez ?) should create a new Epicor Idea and the rest of you should vote for it so that it can be escalated. Note that I am the Product Manager of BPMs and BAQs as well, so I can help push these easy items up the line.
  2. UNTIL then, it is also fairly easy to go and grab the format of the link (create a link one time), and copy that into your code, swapping out the index key, and then send the link.
5 Likes

Epicor has a document available on EpicWeb titled, “Getting Started with the Kinetic User Experience” (dated May 2022). On page 5 there is a graphic describing that the Classic UI, and Classic and Modern Shells will stop being updated in the Kinetic 2023.1 release; and completely removed from the application in the Kinetic 2024.1 release, with the Desktop Client being replaced by Browser Access.

3 Likes