Overview of the HTTP pipeline

Let's assume you have a SaaS product that helps users manage their todo list.

A user, named Alice, has bookmarked the URL to her todo dashboard (ex: https://todo.djaopp.com/app/xia/dashboard/). She clicks on the bookmark.

The browser issues a DNS lookup to retrieve the IP address of the server responsible to respond to requests for the domain todo.djaopp.com (How to use my own domain?), then sends an HTTP request to that server, asking for an URL path called /app/alice/dashboard/.

When the todo.djaopp.com server receives the HTTP request, either the user is authenticated or not. In case Alice is not yet authenticated, she is redirected to the login page.

Djaoapp immediately adds to your application 3 ways for users to authenticate with your SaaS product and all the appropriate themed pages for users to manage their credentials.

• Session Cookies
• JSON Web Tokens
• API Keys

Let's assume you decided to authenticate a user named Alice through a POST request to /api/auth/. At this point, your backend business logic has nothing to do. Everything is handled by djaoapp and a valid token is returned to the browser.

Now your front-end user interface (UI) is doing a GET request to the backend server passing the authentication token along, to retrieve the user profile information (ex. GET /api/users/alice). Again, your backend business logic has nothing to do. Djaoapp checks that the authenticated user (i.e. alice) has permissions to access the profile information and returns it.

1. checks the authenticated user has permissions to make that request (see defining access rules).
2. retrieves personal information from djaoapp database about the authenticated user (full name, roles, etc.)
3. encodes the authenticated user personal information into either a session cookie or a JSON Web Token
4. forwards the original HTTP request, modified to include the previously generated session data as HTTP Headers. (there is a Testing section under the Rules dashboard that will generate headers passed to your backend.)

Once your backend server receives the djaoapp forwarded request, it will decode the session data with its DjaoDjin secret key (see Frameworks integration) and process the request according to your business logic.

Example

GET /api/todos/alice/ HTTP/1.1
Authorization: Bearer <JWT>

Code inside djaoapp is triggered that decodes <JWT> to

{
  "username": "alice"
}

After djaoapp applies the access rules (defined for your backend logic in the Rules dashboard), it decides to forwards the request as:

GET /api/todos/alice/ HTTP/1.1
Authorization: Bearer <JWTBackend>

Where <JWTBackend> can be verified with your DjaoDjin secret key and the session data decodes to:

{
  "username": "alice",
  "roles": {
    "manager": [{
      "slug": "alice",
      "printable_name": "Alice Lee",
      "subscriptions": [{
        "plan": "open-space",
        "ends_at": "2020-12-31T00:00:00Z"}]
    }]
  }
}

The above examples is interpreted as: “A request user alice is a manager of the billing profile alice, itself subscribed to the open-space plan.”

A support team member should be able to access a customer profile and billing information but a customer should not be able to access another customer profile - obviously. When you have a single integrated database, there is a non-negligeable risk, especially as business rules complexify, that through bugs and/or SQL injection, security and privacy of customer data are not maintained. By separating the concerns between djaoapp and your application, security and privacy are easier to enforce.

Frameworks integration