How to securely pass in auth info?

Kristin Harper

Hi,

So we've got a roommate selection process in one of our forms. Updates on the user making the selection are quick and work just fine. But since the person making the selections does not have permission to edit/update other constituent records, right now we are relying on a datasync to update the survey/user record for the users selected as roommate. But the datasync only happens every 15 mins thus creating a delay and the potential for errors. Multiple users could be selecting the same user as a roommate at the same time if they make this selection before the data has synced. But there has to be a better way to do this. It seems to me just adding a “has roommate request in progress” interest id to the the individuals selected as a roommate (non-logged in users) might fix this. A SRConsAPI call would allow this. The problem is that we would have to pass in a user id and password with the correct permissions for this call. What is the most secure way to pass in this information? What is considered the best practice here?

Eric Oyler

@Kristin Harper
The SRConsAPI is for server-side API calls, and therefore the user ID and password are not of concern for security because they are on the server code which is inaccessible to regular web visitors. You will not want to utilize this for a front-end (JavaScript) call because the ID and password would be visible to the public in the source code.

You can use the CRCons API for the front-end but that's a part of the problem you are experiencing is that the CRCons API only provides authentication to act on a record for the person logged in via SSO.

I see three options:

1. If you have the platform and capability, you could write a web app/servlet that runs on the server that would allow you to utilize the SRConsAPI to update the roomate's record. You would have to create your own security around this web app/servlet to prevent abuse, but it would allow you to write on a non-logged-in user's record.
2. If you want to stick with front-end only API calls, the other option is to use Custom Interactions. You can create the custom Interaction type in the admin, and then the logged-in user can identify their roomate, and you can use the logInteraction and listInteractions methods along with the two constituent IDs. For example, if the logged in user cons ID is 1234, and the select roommate with cons ID 5678, you could log a new interaction where the subject is “roomates-1234-5678”. Then if someone else comes along and tries to select 5678 as their roomate, you first get all interactions using listInteractions and search on all with the “-5678” in the subject - if any responses come back, you tell the user that person is already selected by someone else… You can modify this pseudo-process to match your desired user experience. So long as the custom interactions are public, they can be searched by anyone to see who has already selected a roommate and who that selection was.
3. Or if you want to go with a third party, you could use something like Firebase to store the cons IDs showing the relationships between users, and manage your own security/rules/data structure if you need something a bit more complex.

Some food for thought.

~E