Config 3.1: Roles and Gates

hugo Configure

In config.json,  roles are defined by

"Roles": {
  role name: gate object,
  role name: gate object, ...
}

So each role is protected by a gate which is an object consisting of the following key-values:

  • Id_name, the unique ID name for this role;
  • Type_id, the role type id; optional
  • Is_admin (=true or false), if this is an admin role;
  • Length, visitor’s IP number can be packed into 8 hex characters. How many used for validation.
  • Surface, the cookie name to save this role in browser;
  • Domain, the domain name for this cookie;
  • Path, the URL path that the cookie is valid; optional
  • Duration, the active period for this cookie;
  • Max_age, the same as Duration but for browser that supports Max_age; optional
  • Secret, secret string to sign the cookie using SHA1;
  • Coding, secret string to encrypt the cookie;
  • Userlist, an array. If defined, only those specific user Ids can login. optional.
  • Logout, after logout, where to redirect the visitor to. Default: the home page /.
  • Attributes, an array of role’s parameters saved in the cookie;

When a visitor presents her ticket at the gate, it will use those information to validate it and de-crypt it into incoming X-Forwarded headers, which could be further used in other middleware.

Here is the list of headers:

  • X-Forwarded-Time: when this ticket was generated as Unix time stamp.
  • X-Forwarded-Duration: how long the ticket was assumed to be valid, in seconds.
  • X-Forwarded-Request_Time: the current time stamp.
  • X-Forwarded-User: the unique user ID, which is defined to be the first element in Attributes.
  • X-Forwarded-Group: the rest of elements in Attributes concated by separator |.
  • X-Forwarded-Hash: SHA1 signature from Attributes, timestamp, IP and secret. This was setup at the authentication and saved in the cookie.

Meanwhile, the elements in attributes will acquire values from the gate and be passed on as incoming variables. If visitor has already passed a variable of the same name in query, it would be overriden by the gate value, since the later can’t be forged. For example, if visitor claims that she has a different user ID in query, the gate will override it by the one in the cookie that was setup at the authentication time.