51
ENG
c.pCO sistema +0300057EN rel. 1.2 - 29.05.2017
9. ACCESS MANAGEMENT FOR IP SERVICES
c.pCO controllers integrate a Web Server and a FTP Server:
• Web server: used to access the les (HTML pages, images, JavaScript
code, etc.) stored under the /HTTP/ directory of the public partition in
the le system. These pages can show dynamic contents generated
by CGI calls (Common Gateway Interface), managed by the controller
rmware in order to read/write variables of the application and create
logs and custom dynamic pages. These pages are accessed in a LAN by
using a browser, entering the c.pCO controller IP address or hostname;
• FTP server: used to access the public partition in the le system, to
read, edit, create and delete les and directories, including web pages.
FTP can also be used to transfer a .ap1 le, for example, to update the
image of the operating system or the application program. The les are
accessed using an FTP client, such as “FileZilla”.
For protecting the contents of the public le system against unauthorised
access, the system administrator can create dierent users, and assign
each user dierent access proles, dierentiated for each service and
adapted to the individual directory.
Access conguration is performed in two steps
1. create users in c.design;
2. create authorisation les in the directories of the public le system
that need to be protected.
9.1 Accounts management
c.pCO does not have any account congured by default, consequently
the entire public le system has read/write access to the default user
(“anonymous”) and web access without authentication. This simplies
the operations for rst installation of the application program and web
pages via FTP/HTTP protocol. Subsequently, accounts can be created
so as to restrict access to the public le system. The accounts who can
access the IP services are created in c.design. Open c.design and access
the conguration editor.
Fig. 9.a
Click “c.pCO Cong. Editor”: the user conguration page will be shown.
Enter the user name and password and conrm by clicking “Add user” for
each new user.
Fig. 9.b
Example: the following three users have been created:
User name Password
dave davepasswd
bryan bryanpasswd
ron ronpasswd
Select the directory where the application program les are located and
click “Upload” to load these accounts into the c.pCO controller.
Note:
• max number of users: 5;
• max number of characters in the user name: 15;
• max number of characters in the password: 15;
• in addition to the users saved in the database, the FTP server retains
the default user, called “anonymous”. This special user allows public
access to certain directories and to new c.pCO controllers without any
users congured. The anonymous user does not require authentication
(any password can be entered) and access will be restricted to the
directories that have no authorisation les (ftaccess, as illustrated
below).
The authorisation les contain a list of users who can access the current
directory. Only the users listed in the authorisation le can access the
corresponding directory.
Note: an authorisation le only prevents access to the les in the
directory where this is located, and not the les in any sub-directories. To
disable access to the various sub-directories, the authorisation le needs
to be copied to each of these.
The authorisation le is a simple text le, called:
• “htaccess”, when it authorises users of web server services;
• “ftaccess”, when it authorises users of FTP server services.
Authorisation le structure
The authorisation le contains a list of user names who are authorised to
access the directory in question, one on each line. There is no extension
(e.g. ".txt”).
Example: the authorisation le for the three users created previously will
have the following layout, and be called “ftaccess” or “htaccess”.
ftaccess/htaccess
dave
bryan
ron
Whenever a user needs to access a le (web) or directory (FTP), the
following procedure is applied to grant/deny access:
1. verify whether the authorisation le (htaccess or ftaccess) exists in the
requested directory. If no le exists, access is granted;
2. if the le exists, this is opened and read sequentially to check whether the
user making the request is included in the list; if not, access is denied;
3. if the user is included in the authorisation le, the system looks up the
user name in the user database. If not found, access is denied;
4. if the user is known, authentication by password is required; if the
password is correct, access is granted.