Transcript Project Overview

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
ISECON 2006
Analysis and Design

Object Oriented approach preferred



Relational Database



Microsoft .Net favoured due to its flexibility
ASP .Net in particular
Again Microsoft SQL Server 2000
SQL Server has support for XML
Other Languages used

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 2006
presentation (New Demonstration).
ISECON
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 http://dynamicpagebuilder.co.uk 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.
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.
User experience / Logical flow
Enter site at the
welcome page.
Attempt to Sign In via
welcome page.
Default.aspx
Default.aspx
When the default page is first
entered the following checks
are performed, Is the user
already logged in? If so do
they have access to view this
page?
Sign In
Successful
Yes / No
No
Error message displayed
returned to Sign In.
Default.aspx
Yes
Default in use
Yes / No
At this stage the menu
control has been replaced
dependant on the user’s
status. The user will now be
able to navigate to pages
they are allowed to view.
(See Page Access String)
If the user fails to enter the
correct password with a valid
user name more than three
times they are locked out
from the system.
No
Sign In control removed
and welcome message
displayed.
Default.aspx
ISECON 2006
Yes
Sign In control replaced
with change password
control user asked to
change password
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.
Under the hood
First time into page, all
defaults are set Sign In
control and standard
menus are displayed.
Sign In attempt.
Username and
password set Post page
(second pass into page.)
The first time the page is
loaded Session Manager is
called in order to establish if
a cookie is present on the
client machine.
usr_sp_login_check
is called using these
as parameters.
No
Successful
Sign In
Page displays
welcome message
and creates
Session entry’s
tbl_user
Stored procedure
returns 1,2,3,4 or 909
to the page.
Create Cookie
encrypt session ID
and write encrypted
session ID to cookie.
Add predefined
session details to
the session
manager database.
Key to return values
1 - login failed password does not match username
2 - Default password is in use user must change their password
3 - This is an internal user and the password matched return all
relevant details.
4 - This is an external user and the password matched return
all relevant results.
909 - The password has been entered incorrectly more than 3
times for a valid user the user is locked out.
Page calls Session Manager
component which returns an
encrypted GUID created by
the data base. See Session
Manager diagram for more
detailed information.
tbl_ssn_sessionData
Welcome
message is
displayed to user.
Any Page that is now called will access the session management database in order to establish whether the
user can view it. All predefined session variables will be made available to the code behind.
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.
Session Manager Component
tbl_session
tbl_sessionData
Session Manager
Component
tbl_sessionStore
Exposed methods of Session Manager
CreateSession
EncryptValue
StoreSession
UpdateSession
CheckUserAccess
GetSessionValue
GetSessionValues
GetSessionVariables
SignOff
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
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


Original Project Plan


Can be found here
Original Dynamic Page Builder Demo


Can be found here
Can be found here
New Demonstration (Cross Browser)

Can be found here
ISECON 2006