The Access Rules Dashboard

You configure a set of URL patterns with access rules through DjaoApp rules dashboard. Access rules work at the application level. For example:

User is subscribed to "Plan A"

On receiving a request, DjaoApp matches the URL requested to the list of URL patterns, in order, first match wins. When no matching pattern is found, the request is denied automatically. It never reaches your server, cutting down traffic from most bots looking for security vulnerabilities in your application.

When the access rule associated to a matching URL pattern does not require any authenticated user, the request is passed through as-is.

When the rule requires for an authenticated user, DjaoApp automatically redirects the request client to a login screen as necessary.

With an authenticated user is hand, DjaoApp then checks a user is subscribed to a plan, is a manager of an organization or any other rule associated to the matching URL pattern; then forwards the HTTP request decorated with session data.

Definition of Access Rules

The Access Rules Dashboard gives platform owners (i.e. profile managers for broker profiles) complete control over all access rules that platform staff, platform subscribers and platform guests must follow. One of its key features is its page permission capabilities. One can quickly assign page permissions to the public, to specific subscriber or provider groups or a specific user. As shown in the following screenshot, the profile manager for notes.io has given subscribers permission rights to every pages under /app/, while other pages are public. More precisely, URL paths starting with / (all pages) except paths starting with /app/ are public.

Each rule in the Access Rules panel has five fields:

rank
When a visitor browse a page, access rules are evaluated in order from top to bottom until one is matched. The ordering of rules is thus really important.
path
The pattern an URL path is matched against.
access rule
When URL path matches the path pattern, conditions under which access is granted.
forward
In some situations, after access is granted, you want to forward the HTTP request to a different server. Otherwise pages which are granted access are served locally.
engage tags
It is often useful to track which features of an application are used often, which features are underused, where users drop in an onboarding workflow, etc. By specifying a comma separated list of engage tags, activity can be recorded and aggregated for later analyisis.

The Authenticated access rule is often used when starting. It means only users that have logged in successfully can access pages under the associated path prefix.

Under the Web Application section, The Authentication input field controls specifies who can login and who can register to the site.

Registration enabled
Any visitor can create an account on the platform
Login-only
Only users with an active account on the platform can login
Only site managers can login
Only users with a profile manager role on the broker can login

In most cases, while you are pre-launch, you will want to restrict access to developpers and product managers by setting the field to Login-only. Once you are ready to open your platform to the customers, you will want to switch to Registration enabled. In case something goes really wrong and you want to prevent anyone from logging in except first responders to a platform incident, switch the setting to Only site managers can login.

Subdirectory and Page View Rights Assignment

With the Rules Dashboard the broker profile manager can assign subdirectory or page permission rights to anyone they wish. This is done with the Path text box and the Rules Access dropdown on the Rules Access panel.

For example, if the broker profile manager decides to grant public access to a specific set of pages starting with /tutorials/, the broker profile manager clicks on Add Access Rule..., then types /tutorials/ in the Path accessed input field, and clicks the Create button.

By default Any is selected in the Access Rule dropdown. If later the business is selling the tutorials as courses, the broker profile manager can easily click on the Access Rule dropdown and change from Any to Subscribed to courses, assuming a courses subscription plan was created. For every subscription plan created (see creating a plan), an Access Rule option named Subscribed to Plan title is automatically created.

Path prefix patterns

The URL path prefix pattern can represent a path to a single page or to a subdirectory.

Here some examples of paths and the URLs they will match and not match.

path matches does not match
/tutorials/ /tutorials/
/tutorials/calculators
/app/
/
/ /tutorials/
/app/
/
-
(/ matches everything)

Variables can be placed inside the URL path prefix patterns. This allows substitution and is necessary to use role-based access rules.

For example, let's say the broker profile manager wants to create a set of pages that are only accessible by Susie, another set of pages only accessible by Jimmy, etc. In fact the broker profile manager wants to create a set of pages which are only accessible to registered users that have been granted a specific role for a organization account. the broker profile manager will create a path that contains the :organization variable. For example:

path matches does not match
/app/:organization/ /app/devs-are-fun/calculators
/app/devs-are-fun/
/app/djaodjin/calculators
/app/djaodjin/
/app/
/tutorials/devs-are-fun/

Access rule dropdown

There are several different Access Rule options a broker profile manager can select for any given page or subdirectory. The most common and easiest to use are Any, Authenticated.

Any
Allows public access by anybody on the Internet to a specific page matching the associated path prefix.
Authenticated
Users have to be successfully logged in before accessing a specific URL matching the associated path prefix.
Active with valid credentials
Users must have a verified e-mail address, set a password and successfully logged in before accessing a specific URL matching the associated path prefix.

A broker profile manager that wants to strike a balance between providing self-serve demos and capturing leads will setup frictionless registration. It provides the opportunity for a visitor to start using the product solely with a name and an e-mail address (no password). Later on users are sent through an e-mail verification and password setting workflow to use more of the product.

DjaoApp will do the heavy lifting to present a login screen when a visitor browses to a page marked with a Authenticated or Active with valid credentials access rule, optionally sending the user through an e-mail verification workflow (Active with valid credentials) before redirecting her to the original page she browsed.

Billing-based access rules

An online platform is not really a business until it starts charging subscribers. Once the broker profile manager has created a few subscription plans, Subscribed to ... options will appear in the access rule dropdown.

Subscribed to Plan title
Users have to be successfully logged in and have a role to a profile with an active subscription to Plan title before accessing a specific URL matching the associated path prefix.
Subscribed or was subscribed to Plan title
Users have to be successfully logged in and have a role to a profile with an active or expired subscription to Plan title before accessing a specific URL matching the associated path prefix.

DjaoApp will do the heavy lifting to present a login screen when a visitor browses to a page marked with a Subscribed to access rule, optionally sending the user through a billing checkout workflow before redirecting her to the original page she browsed.

Role-based access rules

When the broker profile manager creates a path with a :organization variable in it, the following access rule options are available.

  • Direct role for :organization restricted to GET
  • Direct role for :organization
  • Provider or Direct role for :organization restricted to GET
  • Provider or Direct role for :organization
  • Provider role for :organization restricted to GET
  • Provider role for :organization
  • Self or role associated to :user restricted to GET
  • Self or role associated to :user

The above list is duplicated for each role defined on the platform. By default there is only one global role named profile manager .

All access rule description that end with "restricted to GET" indicate that only a subset of HTTP methods are allowed (GET). These methods are not suppossed to modify persistent data.

Users that show up under a profile role page have a direct role on that profile. Respectively the profile will appear under the connected profiles page for the user.

When a subscriber request support because "something does not work", it is often convinient, if not necessary, for a provider team member to access the subscriber application pages as the subscriber sees them. The provider or direct access rule extends access to pages to users listed with a role for a provider of a plan the profile is subscribed to.

Special cases

Some pages, like the Update Password Page, should only be accessible by that user (Self). None-the-less, it is not uncommon for users to for users to forget passwords, and for some reasons to be unnable to get through the Recover Credentials workflow on their own. In those cases, it is useful to give the ability to a provider support team members to set a temporary password for a user. This can be achieved by setting the access rule to the Update Password Page to Self or role associated to :user

There are administrative pages, like the Refund Charge page, that should obviously be accessible to a provider support team members but not to paying subscribers. In those cases, the Provider role for :organization access rule is used.

Agreement-based access rules

As a platform provider, the broker profile manager requires all users to sign their Terms of Use (ToU) when they first register, then again when those terms change.

Agreed to Agreement
A user that has agreed to Agreement

DjaoApp will do the heavy lifting to present a login screen when a visitor browses to a page marked with an Agreed to access rule, optionally sending the user through an agreement workflow before redirecting her to the original page she browsed.