Structure
The default working directory presented to a client when the rXg file system is accessed via SSH is the administrator's home directory. A subdirectory called portals
is present in every administrator's home directory that is linked to the location of where all captive portal as stored. A single persistent storage location is used for all custom captive portals on an rXg and is shared by all administrators.
Within the portals
is a series of subdirectories. Each subdirectory contains a custom captive portal. The name of the subdirectory will be the same as the 'Controller name' as defined when creating the portal. Using SSH, it is possible to login to the rXg and edit the custom portal files directly using the built-in text editor vi. However, in most cases, administrators will want to use a SCP or SFTP client to copy the files from the rXg to a local computer for editing.
If you are using an SSH command line tool such as OpenSSH, a command like the following will copy the contents of the custom portal named by CONTROLLER_NAME into the local current working directory.
scp **ADMIN\_LOGIN** @rxg.domain:~/portals/ **CONTROLLER\_NAME**.
Most GUI SSH clients have enable bulk copying of entire directory trees from a remote file system. Typically, this is accomplished by logging into the remote server and then dragging and dropping the desired folder onto a destination on the local machine.
We recommend that the administrators copy the entire directory tree of a custom portal onto a local workstation, making changes, and then copying the entire directory tree back to the rXg. Although this requires more transfer time between the administrative workstation and the rXg, adhering to this protocol helps prevent numerous classes of common issues that result in strange portal behavior.
The folder structure for a custom captive portal looks like the following:
CONTROLLER_NAME/
images/
javascripts/
static/
stylesheets/
views/
CONTROLLER_NAME.erb
CONTROLLER_NAME.rb
images/ The directory where artwork assets are stored. javascripts/ The directory where the client-side JavaScript code assets are stored. The portal.js.erb
file is the only file that needs to be referenced by the portal. All other files that are present in this directory are automatically assembled into a single URI that is referenced in the layout via the Rails asset pipelining mechanism. static The directory where file resources are stored that can be accessed from the WAN. Downloadable files etc. stylesheets The directory where cascading style sheet assets are stored. Both CSS and Sass/SCSS are supported. Additional stylesheets may be placed into this directory and referenced for asset pipelining. Each file that should be included must be listed at the top of the portal.css.scss.erb
or the portal_mobile.css.scss.erb
file. views/ The directory where HTML files with embedded ruby templates for the views, and partials are stored. Templates for views are named according to the controller action that is requested. For example, when the end-user browser requests /portal/CONTROLLER_NAME/session_info/
, the session_info.erb
file is picked for rendering. Partials being with an underscore character (_
) and are included by file name within the view through one or more render partial
rails statement. CONTROLLER_NAME.erb The desktop portal layout. This file is the foundation of the portal and incorporates the HTML and embedded Ruby that will be present in all rails generated views.CONTROLLER_NAME.rb The controller file for the custom captive portal. Existing actions may be customized and new actions may be created by editing this file. This file may be ignored if only cosmetic changes are desired. The rXg portal is implemented in Ruby on Rails. Becoming versed in rails is a critical aspect of portal customization. Mastery of rails enables the administrator to create entirely new functionality that suit your exact needs. However, it is possible to customize the presentation of a portal without knowing any knowledge or experience with Ruby on Rails. Knowledge of HTML and CSS are all that is required to change the look and feel of the default portal. Dramatic results may be achieved through modification of the CSS alone.