SuperCRM Web API
A customer relationship management (CRM) software is primarily used to manage contacts (customers) and the interactions with them. This demo demonstrates a multi-tenant API service that allows two types of users – individual and business (team) – to setup account and perform CRUD operations related to contacts and interactions in isolation (each account is only limited to seeing and modifying data that belongs to it).
This demo is based on the following walkthrough: Build a multi-tenant CRM RESTful API service on ASP.NET Core Web API.
Here we expose the API for testing purposes using Swagger UI. You can perform all actions including sign-in, sign-up, and store the session which can then be used to call authenticated APIs from the Swagger-UI page.Test API with Swagger UI »
Tips to try out the demo :
(Clicking on the links for actions below ensures that the Swagger-UI page opens up the action with a pre-filled request body)
Authentication And Verification Checks
- Let's setup a user named Jay by calling sign-up endpoint (with a valid email) and the UI will capture session credentials returned to sign subsequent API calls with HMAC token. (Calling sign-in also leads to the same behavior but you need to have an existing account to sign in.)
Before you can call protected endpoints like contacts APIs, you need to verify Jay's email first. (You can try calling get contacts which will demonstrate the ASK's user verification check in action.)
You should have received an email with a verification token; call verify endpoint with it.
(You can also resend the verification email.)
- If you had entered an incorrect email, you can call change-email to fix it – this endpoint has been opted out of the user verification check(btw, you need to verify every time you change email).
Activity Data Authorization Checks
Now, you can perform CRUD operations for contacts and interactions. Some scenarios you can try to test data isolation with ADA in action are given below.
Before proceeding, we also need another user named Gary. So first sign-out (if you're already signed in as Jay). Now call sign-up to setup Gary (don't forget to verify Gary's email the same way you've verified Jay's email earlier). Now sign-out Gary to proceed with ADA scenarios below.
- Sign-in as Jay.
- create a contact (John) and note down the returned Id.
- Call get contacts and confirm that you've got the John record in the response list.
- Sign-out as Jay and then sign-in as Gary.
- Call get contacts and confirm that you don't see John – it doesn't belong to Gary so isn't listed.
- Try calling edit contact endpoint with John's Id and it should respond with 403 - unauthorized. Gary doesn't own John contact so can't edit it either.
- Sign-out as Gary and then sign-in as Jay.
- Now try calling edit contact with John's Id, it will succeed – because Jay owns the contact John. Just try it for yourself.
Cross-Site Scripting (XSS) Injection Detection
- Sign-in as Jay (or any other user) if not already.
- Try creating a contact with name as 'Kenny <a>'; it'll fail because the name contains '<a>' XSS characters.
The sample demonstrates some of the key features of the security pipeline including HMAC based authentication, Activity Data Authorization (ADA), user verification and Cross-Site Scripting (XSS) detection.