ISECON 2006 Online Content Editing - An Evaluation and Comparative Study Dynamic Page Builder An Evaluation and Comparison. Samuel Sambasivam David C. Mills

ISECON 2006 Project Goals  The main goal was to provide a solution for cross browser compatibility  To compare and analyse the Dynamic Page Builder product against the technology available today  To remove HTML Components if possible  To investigate the use of XML  To provide a demonstrable software example

ISECON 2006 Description  Investigate alternative software solutions in order to provide a browser based HTML page editor comparable to the Dynamic Page Builder Product.  Review the existing product and compare it against current solutions in an attempt to provide a cross browser solution FOR MORE INFO... Current Product only functions within Internet Explorer 5.5 ® and above, it can be seen at Page Builder Demo Page Page Builder Demo Page Builder Demo Page

ISECON 2006 Analysis and Design  Object Oriented approach preferred Microsoft.Net favoured due to its flexibility Microsoft.Net favoured due to its flexibility ASP.Net in particular ASP.Net in particular  Relational Database Again Microsoft SQL Server 2000 Again Microsoft SQL Server 2000 SQL Server has support for XML SQL Server has support for XML  Other Languages used XML, HTML, JavaScript, SQL XML, HTML, JavaScript, SQL

ISECON 2006 Design Overview The original project used Microsoft active server pages, Microsoft HTML Components, JavaScript and SQL server. The main challenge was to identify a way in which a product could be developed that would compare with the original software. The design of the new software product was restricted by one constraint and that was simply that the user should not need to download any additional software to their machine. Other than that which can be achieved through the download of a standard web page no plug in software should be used. The design of the new software has taken the restriction into account and provides a solution to meet this goal. It is based on the Microsoft.Net Architecture and utilises Active Server Pages.Net (Visual Basic), Extensible mark-up language, SQL, and JavaScript. The editor interface that can be seen* is a User Control that I developed specifically to address the issue of browser compatibility. * Please refer to related documents at the end of this presentation (New Demonstration).

ISECON 2006 Design Overview Cont. This control utilises XML in order to read configuration data, Visual Basic on the middle tier in order to render the presentation layer and JavaScript as part of the presentation layer in order to invoke to appropriate browser functionality. The core of editable content is provided by an API (Application Program Interface) call to the either Microsoft Internet Explorer ® or any of the Mozilla ® family of browsers. This is achieved by detecting the users browser when they call the editor page (this is displayed along with their IP address on once the they have logged in). The browser information is passed to the control and a text writer is utilised within the control in order to render the appropriate JavaScript (either Internet Explorer ® compatible or Mozilla ® compatible).

ISECON 2006 Design Overview Cont. The flow of the editor code is relatively simple there is one container page that has the editor control embedded within it. When the page is called it instantiates the editor control that performs the tasks detailed in the previous slide. Once the JavaScript has been rendered to the presentation layer the actual editor is invoked, this is a case of including the ‘designMode = on’ property in a standard iFrame. From this point the editor functionality is provided by a call to execCommand. ExecCommand takes three parameters CommandName, UserInterface, and Value. This is true for both browser types however Internet Explorer ® supports the UserInterface parameter far more gracefully than Mozilla ®.

ISECON 2006 Design Overview Cont. The Mozilla ® Browser’s simply expect the UserInterface to be set to false otherwise it will return an error. There are some moves towards including the Microsoft ® only contenteditable attribute within the next version of the W3C Dom*. This would be of great benefit as it allows a greater level of granularity, and individual elements within a page can be set to editable (not just an iFrame, Div or Span). The code you will see in the demonstrations on the supporting web site under project test has the contenteditable attribute included as part of a test that proves Mozilla ® browsers will simply ignore it. FOR MORE INFO... The various versions of the W3C DOM can be found here and the Microsoft version can be found here. here

ISECON 2006 Security Design This turned out to be the most complex part of the project, the original utilised the most rudimentary security which had to be addressed on order to cater for session management and access to the site and editor in general. To address security I have implemented a detailed session management component, this not only caters for the length of a users session, but also how they are authenticated on the web site and most importantly whether they are able to access any of the individual pages within the site. The component sits in the middle tier (in the main.Net assembly) which is where traditional COM components would have been, one of.Nets most powerful features is the fact that all of the traditional COM components are rolled up into one assembly dll.

ISECON 2006 Security Design Cont. The user will be asked to Sign in when they visit the site, unless a cookie is found on their machine in the initial page load checks. Once they provide a user name and password the following things happen. First the default.aspx page of the site will make a call to the database and check the details against the user information stored these two sets of data are compared. If the username is incorrect the user will simply be informed that their sign in attempt has failed, no more detail is provided. If the username is correct but the password is wrong the user is informed that their sign in attempt has failed. The user table on the database is also updated with a counter, this provides a limit to the number of times sign in can be attempted to three (it can easily be amended to more or less attempts by modification of one parameter). If the user has attempted to log on unsuccessfully more than three times they will be locked out and informed that they must request their sign in to be reset. The diagram on the next slide shows the user experience.

ISECON 2006 Security Design Cont.

ISECON 2006 Security Design Cont. In a little more detail the diagram on the next slide shows how the program flows and the interaction between the front end and the database. When an initial login attempt is made the only database call that is made is a single call to retrieve the users details, this is provided through a stored procedure as I have chosen not to embed any SQL within the application code in order to maintain the correct level of code separation. The stored procedure usr_sp_login_check is called and contains a simple search for the username where it is like the username supplied from the sign in screen. If the user information is found then the next stage of the process is invoked and the users details are returned in order to match the password stored on the user table with the password provided through the user interface. The next slide provides a look at the flow that takes place when a sign in attempt is made.

ISECON 2006 Security Design Cont.

ISECON 2006 Security Design Cont. Once the user has provided a matching username and password with the data stored in the user table the process continues. As you will have seen in the diagram on the previous slide once a login is successful the default.aspx page will write a cookie to the users machine this contains an encrypted GUID that is created by the Session Manager component. This is the only information the cookie contains. The GUID is generated by the ssn_sp_insertSession Stored procedure and passed back to the component which then encrypts it and passes it back to the presentation layer in order to store the data on the users machine. This then allows the default.aspx page to invoke several calls to the component that add the data fields retrieved from the user table in the database to the session table. These fields are then available for use throughout the application. Update Session performs two main tasks it inserts / updates units of session data and secondly it updates the timestamp used to measure how long the users session has been running for. This timestamp is compared against the session time out parameter that is passed into the component from the deafult.aspx page. (This could be passed from any page and therefore allows for various session time outs dependant on the page being viewed.)

ISECON 2006 Security Design Cont. The diagram below shows that relationship between the three Session management tables and the component. The other important methods of the component are encryptvalue and GetSessionVariables. These are explained on the next slide.

ISECON 2006 Security Design Cont. EncryptValue calls a private function within session manager ‘EncryptString’ this in turn encrypts the value. It uses a simple convert to ASCII value, add an arbitrary number and then perform XOR translation. The reason that EncryptValue calls EncryptString is that DecryptValue also calls EncryptString in order to convert the encrypted value back again. Whilst the session manager component is capable of storing and retrieving one or many values, I decided to produce a Class that would contain all relevant details for a given user session (Session Variables) the GetSessionVariables method of the component populates this class from the user table and passes an instance of it to the front end in order for it to be stored in the session data. I have provided the entire ASP.Net project in a separate compressed file for inspection should you wish to view the above component it can be found in the component folder within the sessionmanager.vb file. FOR MORE INFO... The ZIP file that contains the files mentioned can be downloaded here here

ISECON 2006 Learning Outcome  I have successfully identified a way in which a cross browser solution can be provided.  I have developed a deeper understanding of online editing and the fact that it is solely dependant on vendor functionality provided as part of the browser DOM  I have identified Web Services and XML as a source for further investigation  Most importantly I have identified that there is actually no need to store HTML/XHTML in the database but simply open and close the documents via ftp.  It is noteworthy that W3C have included open and save functionality within DOM level 3 and this is also an area for further investigation.  I also proved that it is not necessary to use HTML components in order to expose editable content within the web browser thus making it possible to provide an editor that functions in many browsers not just Internet Explorer ®.

ISECON 2006 Conclusion  It is possible to provide an online content editor that functions with the major browsers, without the need to use software plug ins or PHP (compiled code).  While this academic project has been able to prove that a cross browser non PHP / Plug in editor is possible, it must be noted that due to the dominance of Internet Explorer ® it is perhaps not commercially viable.  There are a number of excellent alternatives and among the best are those that utilise PHP as a base. Most of these products allow for the simple inclusion of the code in the CGI bin.

ISECON 2006 Related Documents  Main Dissertation Document Can be found here Can be found here Can be found here Can be found here  Original Project Plan Can be found here Can be found here Can be found here Can be found here  Original Dynamic Page Builder Demo Can be found here Can be found here Can be found here Can be found here  New Demonstration (Cross Browser) Can be found here Can be found here Can be found here Can be found here