SuperCRM Web App
A customer relationship management (CRM) software is primarily used to manage contacts (customers) and the interactions with them. This demo demonstrates a multi-tenant MVC web app 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 web app on ASP.NET Core MVC.
Tips to try out the demo:
Authentication And Verification Checks
- Let's sign up as a user named Jay (specify Type as 'Individual' and a valid email). Successful sign up or sign in calls respond with a Auth Cookie which is then sent by the browser with subsequent requests aiding in authenticating those requests automatically.
Before you can access protected actions like Contacts, you need to verify Jay's email first. (You can try visiting Contacts which will demonstrate the ASK's user verification check in action.)
You should have received an email with a verification link; click on it to verify your email. In case you don't , you can choose to resend it from the verify page.
- If you had entered an incorrect email, you can change it – this action 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 sign up as Gary (specify Type as 'Team', Business Name as 'Altrika LLC' and a valid email). Verify Gary's email. Now sign Gary out to proceed with ADA scenarios below.
- Sign in as Jay.
- Open Contacts page, click on 'New Contact' and add a contact with following details: Name: 'John Doe', Email: '[email protected]', Phone: '(555)-555-5555', AcquiredFrom: 'Social' and Notes: 'Interested in the product'. Click on the Id cell of this new contact just added into the grid and copy the whole 36 characters long contact id.
- You can also try out the edit action – click on the Edit button on the John's record, make some change in the notes for example and click on Save.
- Sign out as Jay and then sign in as Gary.
- Open Contacts and confirm that you don't see John – it doesn't belong to Gary so isn't listed.
- Click on 'New Contact' and add a contact with following details: Name: 'Jim Pane', Email: '[email protected]', AcquiredFrom: 'Social' and Notes: 'Interested in the product'.
- Click on the Edit button for the Jim's record and change the Id value to the John's contactId we had copied earlier. Click on Save and it should respond with 403 - unauthorized. Gary doesn't own John contact so can't edit it either.
- Cancel the Edit form and try editing it again but this time without changing Jim's Id. As you click on Save, it should succeed as Jim is owned by Gary.
- If Gary can't edit contact John, so as Jay can't edit contact Jim (because Jim is owned by Gary not Jay). You can verify this by trying similar steps – copy Jim's contactId, sign in as Jay, click on any contact record's Edit button, change its Id to Jim's contactId and click on Save. It'll lead to 403 - Unauthorized as well.
You can try similar tests with interactions.
Cross-Site Scripting (XSS) Injection Detection
- Sign in as Jay (or any other user) if not already.
- Open Contacts and try creating a new contact with following details: Name: 'Kenny <a>', AcquiredFrom: 'Social'. It'll fail because the name contains '<a>' XSS characters.
The sample demonstrates some of the key features of the security pipeline including Auth cookie based authentication, Activity Data Authorization (ADA), user verification and Cross-Site Scripting (XSS) detection.