Warning: session_start(): Failed to decode session object. Session has been destroyed in /var/www/vhosts/cms-security.ca/httpdocs/igeneral.php on line 1035
CMS Security-web application for web developers

CMS Security (CMSS)

Our CMSS application is used to modify the contents of a website.

  • Installed on a user’s computer.
  • Communicates with a database and it stores information of a website and its content.
  • Uses a WYSIWYG (What You See Is What You Get) editor 
  • Ensure a user friendly interface for modifying html code.
  • Uses optional coding modules such as JS/CSS/PHP/HTML editors for advanced users or site administrators.

CMSS adds an extra level of security to the existing CMS

  • Ensures that the system remains functional
  • Compatible with new technology
  • Has the option to centralize updates while making it faster and easier to backup sites with a CMS

Multiple users

  • Cascading Style Sheet (CSS) may have multiple layers of security depending on the logged in user and the specific requirements of the owner’s website. For example, one user may have access only to a certain section of the website, such as the news section, one other user may not be allowed to add additional pages or change certain page information (such as the pages url) etc.

Increased security

  • CMSS application installed to be customized by a network technician for restricting access to the CMSS application or interface. Secure Sockets Layer (SSL) can also be setup for secured database and file connections.
  • The database application has several permissions (select/update/delete/insert) while the web hosting files have a read-only version of the database content (select only). This ensures that the passwords to modify the database effectively reside within the application thus limiting risks to the point of installations of the application. Internet Protocol (IP) addresses may also be used in order to limit access to the database.
  • One (or more) additional database(s) can be configured to store information that is pertinent to the owner of the website, such as CMS login passwords, customized fields. These additional databases can be limited to the application and not accessible thus increasing security to this privileged information. A user’s password (and any sensitive information) may also be either hashed and/or encrypted using cryptography practices.

Validations

  • Other security measures and validation tools can be used such as sending a secondary security password to an email (usage is blocked until the secondary password is also entered by its user), temporarily blocking of a login after a certain amount of failed attempts (an administrator needs to unblock the user, or a certain time-out needs to pass before a password retry), limiting access by a timer or only during certain hours of the day etc.

Permissions

  • CMSS may be implemented for transactional aspects of a website (client login, shopping carts etc.). As such, regular security can be used by configuring one (or more) database(s) with the proper permissions.  The CMSS application may also be merged to an existing application thus removing the need for multiple applications (pertinent to the owner of the website).

Language

  • The application (in part) stores website information in as many languages that are required. This information includes (but is not limited to) the url, page title, page name, page description, keywords, page category, multiple page orders, start & end dates, page date, short & long descriptions (html or plain text), product prices and page contents (html or plain text).

Multiple Access

  • Any of the text fields in the database may be configured to use a friendly WYSIWYG editor to display and modify the contents or a JS/CSS/PHP/HTML editor. As such, the editors can be hosted on a server. Multiple CMSS applications can access the editor to load and get the raw text of the editor. The editors can be centralized for easy upgrading. The editors do not have direct access to the database. Before saving the text, a validation is done to ensure nobody else has modified the page. If another use has modified the page, then the user has the option to cancel or overwrite the content. Previous versions of the text can be viewed. According to another aspect of the invention, newsletters may be created (formatted with the WYSIWYG editor) and sent. Custom fields may also be added for extra configuration options without having to modify the application. The custom fields can be text, numeric, dates, boolean, and a text field can be formatted using any of the existing modules such as JS/CSS/PHP/HTML.

Logged in user

  • A file manager may be attached to the WYSIWYG editor to manage the files such as upload, modify, delete and rename files. The file manager can be secured by using a security token from a logged in user, the IP addresses of the user, and any other features that can be installed for added security, such as a secondary login system.

Tracking

  • CMSS application can essentially do what other CMS systems can do such as, but not limited to, create new pages, delete pages, modify or edit pages, save pages, copy pages, redirect a page to another page, order pages or change order of pages, upload images & documents, put pages offline (manually or with specific dates or times) and can be automatically backed up on each change. Additionally, actions can be logged in order to track who and when the changes were made.

Viewing

  • The list of pages can be viewed by selecting a sorted list. The list can be sorted using any of the available columns (title, url, name, etc.), grouped or filtered by categories. The application can be branded by adding images in its layout. The images can either be fixed or downloaded for a dynamic change.

Direct Access

  • The step of running a client-side application for an online content management system is automatically done, there is preferably no locally stored data. There is also preferably no synchronizing of data. The CMSS application preferably does not rely on locally stored data, therefore can be used on any system without the need to synchronize data. The installation of the CMSS application gives direct access to the Content Database. It also does not have any problems that synchronization can have, like synchronizing an older version, or having site variations from one installation to another.

User flexiblitiy

  • CMSS has no need to have offline access to data which prevents collisions in a multi-user environment where many persons are modifying the same content. The speed is not an issue, since there is only the need to upload images and documents, this step is a required step in order to have the information on the server. Reading a database content is not slow, and ensures data integrity and you can easily ensure that no other user has modified the data before a change is applied. The CMSS application has no need to have local versions of files or images etc. which can cause inconsistencies in the system. Contents of the file server are usually regularly backed up, if the backup system is synchronized a User Computer, then they would have access to all of documents. Using current Synchronizing methods (such as Dropbox™) can make the backed up data available offline to any users that is synched with the synchronizing method. This method is not necessary and used only if a Client requires easier and faster access to their documents. Using the previous example of a synchronizing method, this can be achieved using such backup techniques already. CMSS does not need or require this option, although the option is readily available to do so.

Management

  • CMSS application preferably does not manage files, it manages HTML code to view web pages and has an interface to upload documents on a Web Server. It is not associated with a file managing system and does not relate in the fact that the purpose has little or nothing to do with media content. As such, the CMSS application does not use synchronization, the application modifies data directly in the HTML code.

Repository

  • In the CMSS, no repository is used or needed. There are no objects that have a need to be in a repository. The Client Web Owner has complete rights on what they want to have on the website. There is no need to have any versioning tools.