Important Update: Some Community URL Redirects are Under Maintenance. Learn More. .

cancel
Showing results for 
Search instead for 
Did you mean: 

API code in multi-session environment

Ilya_Khen
Champion III

Hi all,

 

Statement:

Archer platform v6.4 SP1 P3

Application with custom object, which uses WEB API to authenticate and do SOAP requests.

 

Question:

I am using the API code in Custom Object, and for each session, I am authenticating. But because I cannot always use user session, I have to use plain credentials of App Owner. Reason, I cannot use user session, because I need to have full access to whole application.

 

I know it is not secure method, but putting security aside. In case of multi session environment, where many users simultaneously using the application, each user will be recreating session token of the user (App Owner) defined in the custom object. Meaning that there might be possibility when user A will not be able to get request/response from WEB API, because her session was overriden by user B.

 

I am curious, how do you folks deal with such scenario?

8 REPLIES 8

Anonymous
Not applicable

Ilya,

 

What is the custom object code doing? Is it something that a non-Module Owner would have access to? If so, you could remove the session from the script, and the REST API would automatically use the session of the user who called it. If they are needing elevated privileges though, that wont' work.

 

On the other side, you mentioned security. Have you found a way around putting the credentials in the custom object in plain text? If so, I'd be very interested to hear how you did that. If not, how have you alleviated concerns over exposing privileged account credentials in plain text?

Hi Scott,

 

Reason I need App owner access, because pre-saving the record, I need to do validation of the data against ALL existing records, not only the ones user have access to. Thus, I have to use some plain credentials, but multiple usage is the obstacle.

 

I do not mind about security here, as it is used in special dedicated network and special non-technical group of people trained to use Archer pages only. There is not much capability for them to check source code, and I do obfuscate it for such matters. Based on the given conditions, I assume that is enough for that use case, but obviously I know that it is not good all around security-wise. But security is about compromise based on likelihoods

 

So, there is no way for multisession plain credential then?

YOU SHOULD ALWAYS BE CONCERNED ABOUT SECURITY.  lol  I'm off my soap box. 

 

It has to be the same as 2 users try to directly log into an environment with the same user.  One of them logging in will kick the other out.

 

Anyway, I keep thinking that maybe you can assign them a role that grants read access to all records but use their group for the record permissions.

 

Not sure if that will work, though... The end users could end up still seeing all records.

 

I'll keep thinking.

I think assigning the role would not help much, as it is restricted on RP level then. Who knows though, maybe for API it matters

 

Yeah, yeah, I know about security  But stakeholder accepted the risks.

How about users can read all records but only edit assigned?

Wouldn't that then give them flexibility to read (compare all records) and still update existing?

 

I'm assuming you want them to only view their assigned records, but maybe you need to evaluate that criteria.

Yeah, we will check some common ground as well. I was just wondering if it is possible somehow to enable multisessioning for the account. Maybe would be good enhancement idea, though harder to implement.

 

Thanks!

Anonymous
Not applicable

Ilya,

 

To Jason's point, you should always be thinking about security. If you've found a way to obscure the credentials when a user does Right-click, View Source from a record page, which exposes the entire custom object's code in all it's glory, I would be VERY interested in talking with you more about how you achieved that. We've looked into it a few times, and never found a solution that didn't expose privileged user credentials in clear text through this method.

Hi Scott,

 

Yes, I do understand you point, and I totally agree, that security is always a priority. But in that exact scenario, we were okay to provide some weakness due to other restrictions and use case. Moreover, it was functionality over security per customer agreement.

 

As for obscurity, it is pretty simple. You can always obscure code by given plugins or even simple base64 encoding. This is not elevating security by any means, but given users technical knowledge and restricted environment, we acknowledged the risk and accepted as solution.

 

Thanks!