2

Within Acumatica, we have an external js application that is brought inside Acumatica. We bring it in by creating a new screen/screen id, and within this template, we just include the js and css files, and the javascript application loads in. Up until now, there has been very little need for interaction between Acumatica and this 3rd party JS application.

We have since developed interaction between this javascript application and Acumatica by utilizing the Acumatica http rest apis to create, view, and manage Sales Order Documents.

So the use case is that an internal user will log into Acumatica via the UI. Then they navigate to this Custom Screen, which loads in the javascript application. Then this JS application starts making api calls to read/write to Acumatica Sales Orders.

As of now, we were planning to use a hardcoded username/password for the api calls within the javascript application. But upon further testing, we are seeing a session crossover between the logged in user's UI session and the hardcoded API credentials. Once we start interacting with the API, we noticed that the username in the upper right of the screen changes to the api user instead of keeping to the logged in UI session user.

So clearly, we are either doing something wrong, OR our approach is flawed. I'm guessing it's the latter. I'm hoping that someone can provide some direction as to a more sound/stable approach to how we should handle the API account vs UI logged in session accounts. We aren't likely to change our use case, so it's about figuring out how to best structure the api calls vs the UI sessions, etc...

Any help would be much appreciated.

NOTE: we are on 2019 r1

Cory
  • 305
  • 1
  • 8
  • And just a little more information. We are logging over the /entity/auth/login endpoint. I assume that is partially the cause of the session crossover. Is it needed to login over the apis if you are already logged in through the UI? I think yes, but worth asking. – Cory Dec 07 '20 at 01:30
  • I should also state that the rest api calls are being made from the front end javascript app (not through backend server calls). – Cory Dec 07 '20 at 01:35
  • We are also noticing that when we post to the logout /entity/auth/logout, it is also logging out the UI session (not just the API session). Adding this in case it's helpful to fully understand the issues we are seeing. – Cory Dec 07 '20 at 12:56

1 Answers1

1

The JavaScript calls you're making end up modifying the same session cookies that are used when you login to Acumatica through a web browser.

I see a few options to solve this:

  • Preserve the original cookies and restore them after your API call.
  • Move your API logic server-side, to a server that you control. This will also solve the problem that your Acumatica API users credentials are currently hardcoded in user-accessible JavaScript.
  • Stop using username/password authentication, and move to OAuth2, asking the user to authenticate if not already logged in to Acumatica and authorize your application to perform actions. This way, you won't have to to setup a separate user session.
Gabriel
  • 3,733
  • 16
  • 29
  • Hi, thank you so much for your insights here. We are trying to use the "Connected Applications" with Resource Owner Password Credentials / oauth2. We are able to interact with postman, no issue, but when we try with the react javascript app, we are able to get the token, but when we make the next api call using the token, we are getting a "you are not logged in" error. Any obvious ideas as to what we may be missing or need to be doing so that this works? – Cory Dec 10 '20 at 13:00
  • We ended up putting in a backend server to handle this so as not to worry about the UI session conflict. Thank you for your help. – Cory Dec 14 '20 at 17:34