Table of Contents

Media-iBox - Content Management System (CMS)

The Media-iBox CMS is a highly customizable Content Management System that allows full control over the Data Model, with a set of default components that don’t require any previous programming experience with the system, but it also allows a developer to easily extend it with custom components.



CMS Architecture

    C4Dynamic
    title CMS Overview architecture
    Container_Boundary(b, "CMS Servers") {
        Container(c1, "AuthorizationServer", "", "Stores user registration information, hashed authentication credentials, etc.")
        Container(c2, "Data API", "", "RESTful-based WEBAPI that allows any app to integrate with the CMS through HTTP")
        Container(c3, "Frontend Server","","")
    }
    Container_Boundary(c, "Database") {
        ContainerDb(c4, "Auth","","")
        ContainerDb(c5, "Data","","")
        ContainerDb(c6, "Frontend","","")
    }
    Container_Boundary(d, "Microservices") {
        Container(c7, "Concurrency","","Allows users to see if there are other users editing or viewing the current data displayed in the edit page.")
        Container(c8, "Permission","","Responsible for querying and persisting user permissions")
        Container(c9, "EditHistory","","Logs data related to changes made by operators in the CMS")
        ContainerDb(c10, "MongoDB","","")
        Container(c11, "FileManagement","","File management allows you to upload and download files securely (authenticated)")
        Component(c12, "Storage", "Blob Storage", "aws s3, disk, ftp, etc...")
    }
    
    Rel(c1, c3, "")
    Rel(c1, c2, "")
    Rel(c2, c3, "")
    Rel(c1, c4, "")
    Rel(c2, c5, "")
    Rel(c3, c6, "")

    Rel(c4, c8, "")
    Rel(c7, c3, "")
    Rel(c2, c9, "")

    Rel(c2, c11, "")
    Rel(c9, c10, "")
    Rel(c11, c12, "")

    Rel(c1, c7, "")
    Rel(c2, c7, "")
    Rel(c3, c7, "")

The Media-iBox CMS is composed of two main parts:

  • CMS Server, which were historically available and used since MIB v3.0;
  • Micro Services, which are being created from scratch to add new features (ex: Concurrency) or to move responsibilities out of the original servers (ex: Permission and Edit History).

Authorization Server

The Authorization Server has the following responsibilities:

  1. OAuth server, to control the access to other Media-iBox servers (that require authentication);
  2. User and Groups management UI, including permission management per API/Server;
  3. Login and Password Recovery UI.

It depends on the following services/servers:

  • Permission Service: it provides the current permissions for the user/group, per API when rendering the UI, and it also provides the endpoint which the Authorization Server uses to save this information;
  • Data API and FrontEnd Server: they provide the endpoint where the Authorization Server can gather every permission that it is allowed to be configured per user/group (normally, http://<myapi.com>/configurablepermissions).

It also has its own set of data tables (starting with AUTH_) in a SQL database.

Data API

The Data API stores and manages all the content for the CMS. It is a model-agnostic, metadata-dependant Data API, as specified here.

It depends on the following services/servers:

  • Authorization Server: it provides the endpoints to check the user's Access Token and user's information, like UserID, groups, etc.
  • Permission Service: it provides the endpoints to get a user's allowed permissions to the Data Model in the Data API.
  • Edit History: it provides the endpoints the Data API has to call to save information of what is being altered during its operation.

It also has its own set of tables (mostly starting with ADM_) in a SQL database, alongside the custom Data Model.

FrontEnd Server

Provides the UI rendering for the operator, and also hosts the customizations and bussiness logic for the operation.

It depends on the following services/servers:

  • Authorization Server: it provides the endpoints to check the user's Access Token and user's information, like UserID, groups, etc.
  • Data API: it provides all the endpoints to store and query data to be shown and used by the operator in the UI.
  • Permission Service: it provides the endpoints to get a user's allowed permissions to the Menu and Edit History pages.
  • Edit History Service: it provides the endpoints for querying the history of changes, based on MediaTypes.
  • Concurrency Service: it provides the endpoints to inform which user is editing which media type.

It also has it's own set of tables in a SQL database.

Permission Service

Provides a collection of permissions per-user/group, per-api, but it really doesn't know the meaning of each permission. It just returns a list of keys (which are MediaType/Sources IDs), compiled from the users permissions + their groups permissions, and what these permissions are (allowed/not allowed, read/write/delete, etc.).

It doesn't depend on any other Media-iBox service to operate, but as it was part of the Authorization Server in past releases, it still shares the same SQL database with it.

Edit History Service

Provides a set of methods to save and query changes to the other Media-iBox servers/services, and may also be used by other non-Media-iBox services, as long as it correctly saves/retrieve information as a set of <MediaType/Collection>/<id>, as the implementation is based on MibObjects entities.

It doesn't depend on any other Media-iBox service to operate, only a MongoDB instance to store its data.

Concurrency Service

Provides a set of methods to allow visualizing which user is editing which MediaType(s) at the current moment, independent of which page is being used to edit it. It also doesn't have any type of locking mechanism.

As it is mission-critical, every data is only stored in-memory while the service is in operation. If it is not available at any moment, the FrontEnd will just not show the Concurrency icon.

Edit this page