FlashNuke Doc v070724

FlashNuke
The Flash CMS
Project Documentation
Questa opera è stata rilasciata sotto la licenza Creative Commons Attribuzione-Condividi allo stesso modo 2.5
Italia. Per leggere una copia della licenza visita il sito web http://creativecommons.org/licenses/publicdomain/ o
spedisci una lettera a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
FlashNuke: The Flash CMS
Index
INDEX ......................................................................................................................................................................................... 2
STATUS OF THIS DOCUMENT ...................................................................................................................................................... 9
VERSION CHANGE LOG ............................................................................................................................................................... 9
RELEASE NOTES .......................................................................................................................................................................... 9
1. INTRODUCTION AND HISTORY OF THE PROJECT .............................................................................................................. 10
1.1. PURPOSE OF THIS DOCUMENT ..................................................................................................................................... 10
1.2. REFERENCES ................................................................................................................................................................. 11
2. REQUIREMENTS ANALYSIS DOCUMENT (RAD) ................................................................................................................. 12
2.1. USER REQUIREMENTS .................................................................................................................................................. 12
2.2. SYSTEM REQUIREMENTS.............................................................................................................................................. 14
2.3. QFD ANALYSIS.............................................................................................................................................................. 15
2.3.1. NORMAL REQUIREMENTS........................................................................................................................................ 15
2.3.1.1. RN001: GRAPHICAL USER INTERFACE STRUCTURE ................................................................................................................. 15

2.3.1.2. RN002: PLUG-IN COMPONENTS ........................................................................................................................................ 16
2.3.1.3. RN003: PLUG-IN SKINS .................................................................................................................................................... 16
2.3.1.4. RN004: MULTILANGUAGE INTERFACE ................................................................................................................................. 17
2.3.1.5. RN005: USER REGISTRATION, AUTHENTICATION AND PRIVILEGES .............................................................................................. 17
2.3.1.6. RN006: ADMINISTRATION PANEL....................................................................................................................................... 17
2.3.1.7. RN007: URL REWRITING ................................................................................................................................................. 17
2.3.1.8. RN008: COMPONENTS INSTALLATION ................................................................................................................................. 18
2.3.1.9. RN009: SYNCHRONOUS AND ASYNCHRONOUS REQUESTS ....................................................................................................... 18
2.3.1.10. RN010: RDF/RSS FEEDS ............................................................................................................................................. 18
2.3.1.11. RN011: SESSION STATE BACKUP .................................................................................................................................... 18
2.3.1.12. RN012: DOWNLOAD MANAGER .................................................................................................................................... 18
2.3.2. EXPECTED REQUIREMENTS ...................................................................................................................................... 19
2.3.2.1. RE001: COMPONENT SDK................................................................................................................................................ 19

2.3.2.2. RE002: ALTERNATE ACCESSIBLE VERSION OF WEBSITE ............................................................................................................ 19
2.3.2.3. RE003: PRIVACY SAFETY ................................................................................................................................................... 19
2.3.2.4. RE004: INSTALLATION SCRIPT ............................................................................................................................................ 19
2.3.2.5. RE005: BASIC COMPONENTS............................................................................................................................................. 20
2.3.2.6. RE006: SYSTEM AND ERROR LOG ....................................................................................................................................... 20
2.3.2.7. RE007: USER BAN .......................................................................................................................................................... 20
2.3.2.8. RE008: ERROR REPORTING ............................................................................................................................................... 20
2.3.2.9. RE009: SYSTEM RESTORE BACKDOOR ................................................................................................................................. 20
2.3.3. INTERESTING REQUIREMENTS ................................................................................................................................. 21
2.3.3.1. RI001: PORTABILITY OF DATA SOURCE ................................................................................................................................. 21

2.3.3.2. RI002: POP-UPS ............................................................................................................................................................. 21
2.3.3.3. RI003: TRANSPARENCY EFFECTS AND ANIMATIONS................................................................................................................. 21
2.3.3.4. RI004: ENCRYPTION OF SENSITIVE DATA.............................................................................................................................. 21
2.3.3.5. RI005: LOGIN FLOOD PROTECTION ..................................................................................................................................... 21
2.3.3.6. RI006: USER GROUPS ...................................................................................................................................................... 21
2.4. USE CASES ANALYSIS.................................................................................................................................................... 22
Distributed under Creative Commons 2.5 BY-SA IT Page 2

2.4.1. ACTORS.................................................................................................................................................................... 24
2.6.1.1. GENERIC USER................................................................................................................................................................. 24

2.6.1.2. REGISTERED USER ............................................................................................................................................................ 24
2.6.1.3. USER ADMINISTRATOR ...................................................................................................................................................... 24
2.6.1.4. [SUPREME] ADMINISTRATOR .............................................................................................................................................. 24
2.4.2. USE CASES................................................................................................................................................................ 24
2.4.2.0. TEMPLATE (COPY & PASTE) ..................................................................................................................................................... 24

2.4.2.1. UC001: ENTER WEBSITE .................................................................................................................................................. 24
2.4.2.2. UC002: SWITCH BETWEEN FLASH AND ACCESSIBLE VERSION.................................................................................................... 25
2.4.2.3. UC003: CHANGE THEME .................................................................................................................................................. 26
2.4.2.4. UC004: CHANGE LANGUAGE ............................................................................................................................................. 26
2.4.2.5. UC005: LOAD MODULE ................................................................................................................................................... 26
2.4.2.6. UC006: REGISTER ........................................................................................................................................................... 27
2.4.2.7. UC007: CHECK USERNAME AVAILABILITY ............................................................................................................................ 27
2.4.2.8. UC008: CONFIRM EMAIL ADDRESS..................................................................................................................................... 28
2.4.2.9. UC009: RECOVER LOST PASSWORD .................................................................................................................................... 28
2.4.2.10. UC010: LOG IN .......................................................................................................................................................... 29
2.4.2.11. UC011: PASSWORD LOGIN (EXTENDS UC010)................................................................................................................. 29
2.4.2.12. UC012: DIGITAL SIGNATURE LOGIN (EXTENDS UC010) ..................................................................................................... 29
2.4.2.13. UC013: RESTORE SESSION STATE................................................................................................................................... 30
2.4.2.14. UC014: CHANGE PASSWORD ........................................................................................................................................ 30
2.4.2.15. UC015: CHANGE SIGNATURE ........................................................................................................................................ 30
2.4.2.16. UC016: REVOKE SIGNATURE ......................................................................................................................................... 31
2.4.2.17. UC017: LOG OUT ....................................................................................................................................................... 31
2.4.2.18. UC018: SAVE SESSION STATE........................................................................................................................................ 31
2.4.2.19. UC019: EDIT OWN PREFERENCES AND PROFILE ................................................................................................................ 32
2.4.2.20. UC020: EDIT ANOTHER USER’S PROFILE.......................................................................................................................... 32
2.4.2.21. UC021: BAN USER...................................................................................................................................................... 32
2.4.2.22. UC022: UNBAN USER ................................................................................................................................................. 33
2.4.2.23. UC023: CHANGE CONFIGURATION ................................................................................................................................. 33
2.4.2.24. UC024: MANAGE COMPONENTS ................................................................................................................................... 33
2.4.2.25. UC025: VIEW COMPONENTS ........................................................................................................................................ 34
2.4.2.26. UC026: INSTALL COMPONENT ...................................................................................................................................... 34
2.4.2.27. UC027: UNINSTALL COMPONENT .................................................................................................................................. 34
2.4.2.28. UC028: GRANT ADMINISTRATOR PRIVILEGES ................................................................................................................... 35
2.4.2.29. UC029: REVOKE ADMINISTRATOR PRIVILEGES .................................................................................................................. 35
2.4.2.30. UC030: DOWNLOAD A FILE........................................................................................................................................... 35
2.4.2.31. UC031: UPLOAD A FILE ................................................................................................................................................ 36
2.4.2.32. UC032: MANAGE FILES ............................................................................................................................................... 36
2.4.2.33. UC033: DELETE FILE .................................................................................................................................................... 36
2.5. CLASS DIAGRAM .......................................................................................................................................................... 37
2.5.1. VIRTUAL CLASS COMPONENT ............................................................................................................................................. 39

2.5.1.1. PROPERTIES .................................................................................................................................................................... 39
2.5.1.2. METHODS ...................................................................................................................................................................... 39
2.5.1.3. STATE DIAGRAM .............................................................................................................................................................. 41
2.5.1.4. LINKS AND COMPOSITION................................................................................................................................................... 41
2.5.2. CLASS BLOCK................................................................................................................................................................... 41
2.5.3. CLASS MODULE ............................................................................................................................................................... 42

2.5.4. CLASS FEEDGENERATOR .................................................................................................................................................... 42
2.5.4.1. METHODS ...................................................................................................................................................................... 42
2.5.5. CLASS USER .................................................................................................................................................................... 43
2.5.5.1. PROPERTIES .................................................................................................................................................................... 43
2.5.5.2. METHODS ...................................................................................................................................................................... 44
2.5.5.3. STATE DIAGRAM .............................................................................................................................................................. 46
2.5.6. CLASS PARTIALADMINISTRATOR (INHERITS USER) ................................................................................................................... 48
2.5.6.1. METHODS ...................................................................................................................................................................... 49
2.5.7. CLASS SUPREMEADMINISTRATOR (INHERITS PARTIAL ADMINISTRATOR) ...................................................................................... 49
2.5.7.1. METHODS ...................................................................................................................................................................... 49
2.5.8. CLASS USERGROUP .......................................................................................................................................................... 50
2.5.8.1. PROPERTIES .................................................................................................................................................................... 50
2.5.8.2. METHODS ...................................................................................................................................................................... 50
2.5.9. CLASS LANGUAGE............................................................................................................................................................. 50
2.5.9.1. PROPERTIES .................................................................................................................................................................... 51
2.5.10. CLASS THEME .................................................................................................................................................................. 51
2.5.10.1. PROPERTIES ................................................................................................................................................................ 51
2.5.10.2. METHODS .................................................................................................................................................................. 51
2.5.10.3. LINKS AND COMPOSITION .............................................................................................................................................. 52
2.5.11. CLASS FILE ...................................................................................................................................................................... 52
2.5.11.1. PROPERTIES ................................................................................................................................................................ 52
2.5.11.2. METHODS .................................................................................................................................................................. 53
2.5.12. SINGLETON CLASS FILEMANAGER........................................................................................................................................ 53
2.5.12.1. METHODS .................................................................................................................................................................. 53
2.5.13. CLASS SESSION ................................................................................................................................................................ 54
2.5.13.1. PROPERTIES ................................................................................................................................................................ 54
2.5.13.2. METHODS .................................................................................................................................................................. 54
2.5.14. STRUCTURE HOST ............................................................................................................................................................ 55
2.5.14.1. MEMBERS .................................................................................................................................................................. 55
2.5.15. SINGLETON CLASS SYSTEMLOG ........................................................................................................................................... 55
2.5.15.1. METHODS .................................................................................................................................................................. 56
2.5.16. SINGLETON CLASS ERRORLOG (INHERITS SYSTEMLOG) ............................................................................................................ 56
2.5.16.1. METHODS .................................................................................................................................................................. 56
2.5.17. CLASS SYSTEMEVENT ........................................................................................................................................................ 56
2.5.17.1. PROPERTIES ................................................................................................................................................................ 57
2.5.17.2. METHODS .................................................................................................................................................................. 57
2.5.18. CLASS SYSTEMERROR (INHERITS SYSTEMEVENT) .................................................................................................................... 57
2.5.18.1. PROPERTIES ................................................................................................................................................................ 57
2.5.18.2. METHODS .................................................................................................................................................................. 57

2.5.19. SINGLETON CLASS BANNEDUSERLIST ................................................................................................................................... 57
2.5.19.1. METHODS .................................................................................................................................................................. 58
3. SYSTEM DESIGN DOCUMENT (SSD) .................................................................................................................................. 59
3.2. DECOMPOSITION AND DISTRIBUTION ......................................................................................................................... 59
3.3. PLATFORM CHOICE ...................................................................................................................................................... 59
3.4. ANALYSIS OF REQUIREMENTS AND FEASIBILITY ........................................................................................................... 60
3.4.1. RN001: INTERFACE MODEL .............................................................................................................................................. 61

3.4.2. RN002: PLUG-IN COMPONENTS ........................................................................................................................................ 61
3.4.3. RN003: PLUG-IN SKINS .................................................................................................................................................... 61
3.4.4. RN004: MULTILANGUAGE INTERFACE ................................................................................................................................. 62
3.4.5. RN005: USER REGISTRATION, AUTHENTICATION AND PRIVILEGES .............................................................................................. 62
3.4.6. RN006: ADMINISTRATION PANEL....................................................................................................................................... 63
3.4.7. RN007: URL REWRITING................................................................................................................................................. 63
3.4.8. RN008: COMPONENTS INSTALLATION ................................................................................................................................ 64
3.4.9. RN009: SYNCHRONOUS AND ASYNCHRONOUS REQUESTS ...................................................................................................... 65
3.4.10. RN010: RDF/RSS FEEDS ................................................................................................................................................. 65
3.4.11. RN011: SESSION STATE BACKUP ........................................................................................................................................ 65
3.4.12. RN012: DOWNLOAD MANAGER ........................................................................................................................................ 65
3.4.13. RE001: COMPONENTS SDK .............................................................................................................................................. 66
3.4.14. RE002: ALTERNATE ACCESSIBLE VERSION OF WEBSITE ............................................................................................................ 67
3.4.15. RE003: PRIVACY SAFETY................................................................................................................................................... 68
3.4.16. RE004: INSTALLATION SCRIPT ............................................................................................................................................ 68
3.4.17. RE005: BASIC COMPONENTS............................................................................................................................................. 69
3.4.18. RE006: SYSTEM AND ERROR LOG ....................................................................................................................................... 70
3.4.19. RE007: USER BAN .......................................................................................................................................................... 70
3.4.20. RE008: ERROR REPORTING ............................................................................................................................................... 70
3.4.21. RE009: SYSTEM RESTORE BACKDOOR ................................................................................................................................. 71
3.4.22. RI001: PORTABILITY OF DATA SOURCE ................................................................................................................................. 71
3.4.23. RI002: POP-UPS ............................................................................................................................................................. 71
3.4.24. RI003: TRANSPARENCY EFFECTS AND ANIMATIONS................................................................................................................. 72
3.4.25. RI004: ENCRYPTION OF SENSITIVE DATA ............................................................................................................................. 72
3.4.26. RI005: LOGIN FLOOD PROTECTION ..................................................................................................................................... 72
3.4.27. RI006: USER GROUPS ...................................................................................................................................................... 73
3.5. RESPONSIBILITIES ........................................................................................................................................................ 73
3.6. IDENTIFYING CONVENTIONS ........................................................................................................................................ 73
3.6.1. COMPONENTS: STORAGE, IDENTIFICATION AND ADMINISTRATION ............................................................................................. 74

3.6.2. AVATARS ........................................................................................................................................................................ 75
3.6.3. USER AND SESSION IDENTIFIERS .......................................................................................................................................... 75
3.6.4. DIRECTORY LAYOUT .......................................................................................................................................................... 75
3.6.5. BASICS OF COMMUNICATION PROTOCOL ............................................................................................................................... 76
3.6.6. ERROR HANDLING, LOGGING AND NAMING ............................................................................................................................ 77
3.6.7. WEBSITE CONFIGURATION VARIABLES................................................................................................................................... 77
4. CLIENT/SERVER INTERFACE .............................................................................................................................................. 79

4.2. COMMON CLASSES AND INTERFACES .......................................................................................................................... 79
4.2.1. IDICTIONARY ................................................................................................................................................................... 79

4.2.2. IUSER ............................................................................................................................................................................ 80
4.2.3. ACCESSPOLICY ................................................................................................................................................................. 80
4.3. LIST OF PROCEDURES ................................................................................................................................................... 80
4.3.1. GETNEWSID():STRING ..................................................................................................................................................... 80

4.3.1.1. PARAMETERS .................................................................................................................................................................. 80
4.3.1.2. EXCEPTIONS .................................................................................................................................................................... 81
4.3.2. SIGNUP(SID: STRING, NEWUSER: IUSER) .............................................................................................................................. 81
4.3.2.1. PARAMETERS .................................................................................................................................................................. 81
4.3.2.2. EXCEPTIONS .................................................................................................................................................................... 81
4.3.3. LOGIN(SID: STRING; USERNAME: STRING; CODE: STRING): IUSER .............................................................................................. 82
4.3.3.1. PARAMETERS .................................................................................................................................................................. 82
4.3.3.2. EXCEPTIONS .................................................................................................................................................................... 83
4.3.4. LOGOUT(SID: STRING) ...................................................................................................................................................... 83
4.3.4.1. PARAMETERS .................................................................................................................................................................. 83
4.3.4.2. EXCEPTIONS .................................................................................................................................................................... 83
4.3.5. EDITUSERPROFILE(SID: STRING, NEWPROFILE: IDICTIONARY, [UID: INTEGER]) ............................................................................. 84
4.3.5.1. PARAMETERS .................................................................................................................................................................. 84
4.3.5.2. EXCEPTIONS .................................................................................................................................................................... 84
4.3.6. DELETEACCOUNT(SID: STRING, CODE: STRING, [TARGET: INTEGER]) .......................................................................................... 84
4.3.6.1. PARAMETERS .................................................................................................................................................................. 85
4.3.6.2. EXCEPTIONS .................................................................................................................................................................... 85
4.3.7. SHOWSAVEDSESSIONS(SID: STRING): IDICTIONARY ................................................................................................................ 85
4.3.7.1. PARAMETERS .................................................................................................................................................................. 85
4.3.7.2. EXCEPTIONS .................................................................................................................................................................... 86
4.3.8. LOADSESSION(SID: STRING, SESSIONCODE: STRING): IDICTIONARY ............................................................................................ 86
4.3.8.1. PARAMETERS .................................................................................................................................................................. 86
4.3.8.2. EXCEPTIONS .................................................................................................................................................................... 86
4.3.9. SAVESESSION(SID: STRING, PAYLOAD: IDICTIONARY)............................................................................................................... 87
4.3.9.1. PARAMETERS .................................................................................................................................................................. 87
4.3.9.2. EXCEPTIONS .................................................................................................................................................................... 87
4.3.10. DELETESESSION(SID: STRING, SESSIONCODE: STRING) ............................................................................................................. 87
4.3.10.1. PARAMETERS .............................................................................................................................................................. 87
4.3.10.2. EXCEPTIONS................................................................................................................................................................ 87
4.3.11. CHANGEPASSWORD(SID: STRING, OLDCODE: STRING, NEWPASSWORD: STRING) ......................................................................... 88
4.3.11.1. PARAMETERS .............................................................................................................................................................. 88
4.3.11.2. EXCEPTIONS................................................................................................................................................................ 88
4.3.12. CHANGESIGNATURE(SID: STRING, OLDCODE: STRING, NEWPUBKEY: BYTE[])............................................................................... 89
4.3.12.1. PARAMETERS .............................................................................................................................................................. 89
4.3.12.2. EXCEPTIONS................................................................................................................................................................ 89
4.3.13. CHANGELOSTPASSWORD(SID: STRING, USERNAME: STRING, NEWPASS: STRING) ......................................................................... 89
4.3.13.1. PARAMETERS .............................................................................................................................................................. 89
4.3.13.2. EXCEPTIONS................................................................................................................................................................ 90
4.3.14. CHANGELOSTSIGNATURE(SID: STRING, USERNAME: STRING, NEWKEY: BYTE[]) ............................................................................ 90
4.3.14.1. PARAMETERS .............................................................................................................................................................. 90
4.3.14.2. EXCEPTIONS................................................................................................................................................................ 90
4.3.15. CREATEGROUP(SID: STRING, GNAME: STRING): INTEGER ......................................................................................................... 91
4.3.15.1. PARAMETERS .............................................................................................................................................................. 91
4.3.15.2. EXCEPTIONS................................................................................................................................................................ 91

4.3.16. OVERLOADS GETGROUPMEMBERS(SID: STRING, GNAME: STRING): STRING[].............................................................................. 91
4.3.16.1. PARAMETERS .............................................................................................................................................................. 91
4.3.16.2. EXCEPTIONS................................................................................................................................................................ 92
4.3.17. OVERLOADS GETGROUPMEMBERS(SID: STRING, GID: INTEGER): STRING[] ................................................................................. 92
4.3.17.1. PARAMETERS .............................................................................................................................................................. 92
4.3.17.2. EXCEPTIONS................................................................................................................................................................ 92
4.3.18. DELETEGROUP(SID: STRING, GNAME: STRING)....................................................................................................................... 93
4.3.18.1. PARAMETERS .............................................................................................................................................................. 93
4.3.18.2. EXCEPTIONS................................................................................................................................................................ 93
4.3.19. PROCESSREQUEST(SID: STRING, PAYLOAD: IDICTIONARY): IDICTIONARY ..................................................................................... 93
4.3.19.1. PARAMETERS .............................................................................................................................................................. 95
4.3.19.2. EXCEPTIONS................................................................................................................................................................ 95
4.3.20. PROCESSADMINREQUEST(SID: STRING, COMPNAME: STRING, PAYLOAD:OBJECT): OBJECT ............................................................ 95
4.3.20.1. PARAMETERS .............................................................................................................................................................. 96
4.3.20.2. EXCEPTIONS................................................................................................................................................................ 96
4.3.21. GETINITDATA(): IDICTIONARY ............................................................................................................................................ 97
4.3.21.1. PARAMETERS .............................................................................................................................................................. 97
4.3.21.2. EXCEPTIONS................................................................................................................................................................ 97
4.3.22. SEARCHUSER(SID: STRING, NAME: STRING): STRING[] ............................................................................................................ 97
4.3.22.1. PARAMETERS .............................................................................................................................................................. 97
4.3.22.2. EXCEPTIONS................................................................................................................................................................ 98
4.3.23. OVERLOADS GETUSERINFO(SID: STRING, USERNAME: STRING, [ONERRORTHROWEXCEPTION: BOOLEAN = TRUE]): IUSER .................. 98
4.3.23.1. PARAMETERS .............................................................................................................................................................. 98
4.3.23.2. EXCEPTIONS................................................................................................................................................................ 98
4.3.24. OVERLOADS GETUSERINFO(SID: STRING, UID: INTEGER): IUSER ................................................................................................ 99
4.3.24.1. PARAMETERS .............................................................................................................................................................. 99
4.3.24.2. EXCEPTIONS................................................................................................................................................................ 99
4.3.25. REPORTCLIENTEXCEPTION(SID: STRING, EX: EXCEPTION) ......................................................................................................... 99
4.3.25.1. PARAMETERS .............................................................................................................................................................. 99
4.3.25.2. EXCEPTIONS.............................................................................................................................................................. 100
4.3.26. UPLOADFILE(SID: STRING, FILENAME: STRING, PAYLOAD: BYTE[], POLICY: ACCESSPOLICY, [MIME: STRING], [OWNERMODULE: STRING]):
GUID 100
4.3.26.1. PARAMETERS ............................................................................................................................................................ 100
4.3.26.2. EXCEPTIONS.............................................................................................................................................................. 101
4.4. WSDL ......................................................................................................................................................................... 101
4.5. EXAMPLE OF CLIENT/SERVER INTERACTION .............................................................................................................. 101
5. FLASHNUKE CORE CLIENT ............................................................................................................................................... 104
6. FLASHNUKE CORE SERVER .............................................................................................................................................. 104
7. SQL DATA BASE PROJECT ............................................................................................................................................... 104
7.1. PURPOSE OF THIS DOCUMENT ................................................................................................................................... 104
7.2. THE IMPORTANCE OF PREVENTING SQL-INJECTIONS ................................................................................................. 105
7.3. IDENTIFYING ENTITIES AND RELATIONSHIPS .............................................................................................................. 107
7.4. BUILDING THE E-R DIAGRAM ..................................................................................................................................... 108
7.5. LOGIC DATABASE DESIGN .......................................................................................................................................... 109
7.5.1. FNUKE_USERS TABLE ....................................................................................................................................................... 109

7.5.2. FNUKE_SESSIONS TABLE ................................................................................................................................................... 110
7.5.3. FNUKE_SAVED_SESSIONS TABLE ........................................................................................................................................ 110

8. ACCESSIBLE VERSION ..................................................................................................................................................... 111
9. ERROR REPORTING SERVICE PROTOCOL......................................................................................................................... 111
10. AN EXAMPLE MODULE: NEWS ................................................................................................................................... 111
11. FLASHNUKE SOFTWARE DEVELOPMENT KIT (SDK) ..................................................................................................... 111
12. ATTACHMENTS, CODE SNIPPETS AND PROTOTYPES .................................................................................................. 111
12.1. GUI MODEL ...................................................................................................................................................................... 111

12.2. USE CASE AND CLASS DIAGRAMS........................................................................................................................................... 111
12.3. CLIENT-SIDE DYNAMIC LOAD AND INTERACTION: PARENT AND CHILD ............................................................................................ 111
13. ABOUT DIGITAL SIGNATURE ...................................................................................................................................... 113
14. EXCEPTION REFERENCE .............................................................................................................................................. 115
14.1. CLIENT ............................................................................................................................................................................. 115

14.2. ACCESSIBLE ....................................................................................................................................................................... 115
14.3. SERVER............................................................................................................................................................................. 115
15. TODOS ....................................................................................................................................................................... 115

Status of this document
This document has comprehensively described the purposes and goals of the FlashNuke Project, and also fully de-
signed all the high-level relevant aspects of the software product. After that, we started the concrete work, designing
the global architecture and, separately, its main components. At this time, only the WSDL client/server interface has
been completed. We have spent some time designing the database layout, but it’s missing the PL/SQL procedures
required for accessing data. We will complete the database in a later release of this document.
Version Change Log

 Version 0.0.0.070724: Initial release
Release Notes
None, yet


1. Introduction and history of the Project
This document has been written to provide technical documentation for the developers of the code name: Flash-
Nuke Project. FlashNuke is a Content Management System (1), based on the Adobe Flex™ (2) technology, and de-
signed to build Rich Internet Applications (RIAs) (3) using the Macromedia Flash platform.
Always more webmasters are not satisfied by their HTML sites. The most important problems they complain about
are transfer load, user-friendship and graphical appeal. When a user1 navigates a standard HTML site, every action
consists in loading a new page from the server. In most cases, the server is overloaded by processing thousands of
lines of code that do not significantly change the page appearance. For example, an RSS reader embedded in the
page will, at every click, load the external RSS feed and parse it using XML. Some advanced scripts cache the RSS files
into the database, but when the feed is not often updated this still causes a overhead to the database. The server
has to transfer all the HTML code (we suppose images and CSS style sheets to be cached) of the page even to just
display a single short error message to the user.
On 2003, a guy nicknamed Raulken was chatting with Antonio Anzivino, and they talked about the possibility to
move his web portal from HTML to Flash to increase the graphical appeal and the performance of the whole website.
The project did actually start in early 2004, but was stopped because of various reasons, including the one that the
program Macromedia Flash MX was not suitable to develop RIAs easily. Now that Adobe acquired Macromedia (4)
and developed a platform to build RIAs using Flash, the scenario changed and, as we will see in the requirements
analysis, the development cost of this program will be heavily reduced.
As for the first draft, we have opted in for Open Source distribution and releasing under the GNU GPL 2.0 license.
1.1. Purpose of this document

The purpose of this document is to define, understand and formalize all the user and system requirements needed
to develop and release the Open Source CMS FlashNuke. These will be the basis of the project, and will be used to
build the final documents: Requirements Analysis Document (RAD), that describes the system’s features, the System
Design Document (SDD), that decomposes the projects in more sub-projects, for which the Object Design Document
will not be written at this time. This project also requires the production of a Software Development Kit (SDK) due to
its plug-in nature. The SDK is intended to be distributed to the developers that want to build new components for
FlashNuke and have to follow its coding model.
Due to the differences between standard software development models and Open Source software development
model, we are not planning to examine costs and resources for development. Open Source software usually follows
the release early, release often philosophy, meaning that during the development phase many alpha or beta version
will be released at developers discretion. Also, when the development team is not large and the project is not yet
popular, no roadmap is decided. Everyone can discuss the project documentation and participate to the develop-
ment phase.
1
With the word user we mean the person that, using a web browser on a device connected to the Internet (a desktop PC, a lap-
top, etc), has access to the website and is able to browse it
1.2. References
1. Wikipedia, the free encyclopedia. Content Management System. Wikipedia. [Online] [Cited: 14 April 2007.]
http://en.wikipedia.org/wiki/Content_management_system.
2. Adobe Corporation. Adobe Flex. Adobe Website. [Online] http://www.adobe.com/products/flex/.
3. Wikipedia, the free encyclopedia. Rich Internet Application. Wikipedia. [Online] [Cited: 14 April 2007.]
http://en.wikipedia.org/wiki/Rich_Internet_application.
4. Adobe Corporation. Adobe Acquired Macromedia. Adobe Corporation Website. [Online] 5 December 2005.
http://www.adobe.com/aboutadobe/pressroom/pressreleases/200512/120505AdobeAcquiresMacromedia.html.
5. Burzi, Francisco. PHP-Nuke. [Online] http://phpnuke.org.
6. Wikipedia, the free encyclopedia. Skin. Wikipedia. [Online] [Cited: 14 April 2007.]
http://en.wikipedia.org/wiki/Skin_%28computing%29.
7. W3C: World Wide Web Consortium. Resource Description Framework. World Wide Web Consortium. [Online]
http://www.w3.org/RDF/.
8. —. W3C Semantic Web Activity. World Wide Web Consortium. [Online] 2001. http://www.w3.org/2001/sw/.
9. Wikipedia, the free encyclopedia. Plugin. Wikipedia. [Online] [Cited: 15 April 2007.]
http://en.wikipedia.org/wiki/Plugin.
10. W3C: World Wide Web Consortium. Web Accessibility Initiative. World Wide Web Consortium. [Online]
http://www.w3.org/WAI/.
11. Wikipedia, the free encyclopedia. Brute force attack. Wikipedia. [Online]
http://en.wikipedia.org/wiki/Brute_force_attack.
12. —. Dictionary attack. Wikipedia. [Online] http://en.wikipedia.org/wiki/Dictionary_attack.
13. Internet Engineering Task Force. RFC 2822 Internet Message Format. IETF. [Online]
http://tools.ietf.org/html/rfc2822.
14. Wikipedia, the free encyclopedia. Stylesheet. Wikipedia. [Online] [Cited: 8 May 2007.]
http://en.wikipedia.org/wiki/Stylesheet.
15. The PHP Group. PHP: Hypertext Preprocessor. [Online] http://www.php.net.
16. Sun Corporation. Java.com. [Online] http://java.sun.com.
17. Microsoft Corporation. .NET Framework Developer Center. [Online] http://msdn.microsoft.com/netframework/.
18. The Mono Project. Mono. [Online] http://www.mono-project.com.
19. W3C: World Wide Web Consortium. Web Services. [Online] 2002. http://www.w3.org/2002/ws/.
20. Widenius, Michael "Monty" and Axmark, David. MySQL Reference Manual: Documentation from the Source.
s.l. : O'Reilly, 2002. ISBN 0596002653.

21. Melnik, Vadim. Flex Internals. [Online] 24 March 2006. [Cited: 29 April 2007.]
http://www.docsultant.com/site2/articles/flex_internals.html.
22. Invision Power Services. Invision Power Board. [Online] http://www.invisionboard.com/.
23. Wikipedia, the free encyclopedia. Globally Unique Identifier. Wikipedia. [Online]
http://en.wikipedia.org/wiki/Globally_Unique_Identifier.
24. W3C: World Wide Web Consortium. W3C XHTML2 Working Group Home Page. World Wide Web Consortium.
[Online] http://www.w3.org/MarkUp/.
25. Wikipedia, the free encyclopiedia. Advanced Javascript And XML. Wikipedia. [Online]
http://en.wikipedia.org/wiki/Ajax_%28programming%29.
26. W3C: World Wide Web Consortium. P3P: The Platform for Privacy Preferences. World Wide Web Consortium.
[Online] http://www.w3.org/P3P/.
27. Wikipedia, the free encyclopedia. MD5. Wikipedia. [Online] http://en.wikipedia.org/wiki/MD5.
28. —. Avatar (icon). Wikipedia. [Online] http://en.wikipedia.org/wiki/Avatar_%28icon%29.
29. —. Knowledge Base. Wikipedia. [Online] http://en.wikipedia.org/wiki/Knowledge_base.
30. —. Wiki. Wikipedia. [Online] http://en.wikipedia.org/wiki/Wiki.
31. Wireshark. [Online] http://www.wireshark.org/.
32. Wikipedia, the free encyclopedia. Digital signature. Wikipedia. [Online] [Cited: 25 April 2007.]
http://en.wikipedia.org/wiki/Digital_signature.
2. Requirements Analysis Document (RAD)

This document will analyze the software requirements for FlashNuke. These are all the features required by the peo-
ple that requested the project. Due to the open nature of the project, further requirements may be added during the
analysis phase at analysts’ discretion, usually if they do not complicate excessively the program.
After listing the requirements, the main problem will be decomposed in sub-problems, the technical feasibility will
be evaluated by code-prototyping some features, and a development plan for all the subprojects will be done
2.1. User Requirements

By following discussions on webmaster forums, interviewing expert site administrators and considering our own ex-
perience as web developers, we have completed the following user requirements. As in the Open Source develop-
ment for general-public application, we have to stay open to further requirements.
The program is a Content Management System based on Adobe Flash platform, used for building web portals of
any size. We define a web site as a portal when it offers different services within the same interface. The reference
model is the Open Source PHP-based CMS PHP-Nuke (5) by Francisco Burzi.

FlashNuke has to allow the webmaster2 to install additional components (i.e. a Forum or a photo gallery) as plug-ins,
without recompiling the code and following a procedure explained later in this paragraph. Also, the appearance of
the page has to be changeable applying the concept of skin (6)3 to the interface: it must be interchangeable and new
skins have to be installed easily without recompiling.
The interface, like PHP-Nuke’s, is built-up by blocks and modules. A block is a small component displayed on the side
of the interface, that provides useless information or access to site services to the user. Some examples of common
blocks: last topics on Forums, login, summary of private messages, etc. A module is an application component that is
displayed in the middle of the interface, taking as most space as possible on the screen. An example module is a Fo-
rum, where the user can browse topics written by other people, reply to them or open a new topic.
The CMS must support multiple languages. A default language can be set, and the recommended language to dis-
play may be detected analyzing the client.
For every action that involves a navigation action (such as browsing images), if it has a sense, a direct link must be
generated in order to bookmark the page or provide direct access to the specific func-
tion/document/message/image/whatever to other users. An example of direct link could be
http://tempurl.org/news?id=254102. Such a link can automatically display a news article on the user interface.
Users may register to the website or browse anonymously. Each registered user is identified by a unique user name,
and can authenticate himself using an alphanumerical password or a digital signature. He must provide a valid email
address to the system, but it’s a choice of the Administrator4 to require the confirmation of the email address. Each
user has a profile that stores some basic information, like displayed name, avatar, biography, date of birth, etc. The
user must have the ability to delete his profile and all information related to him (except logs) from the website data
base, in order to fit the requirements of most strict privacy laws, like Italian law 196/2003 that explicitly requires this
feature.
Users may choose to let the system back their session state up. This means that, when the user closes the browser
windows and enters the site again, after login he may be offered to restore the status of the website as it was left
the first time.
The website Administrator may nominate other Administrators among the registered users, and may decide access
policies for the site, including:
 Which modules can be accessed (and which block can be viewed) by anonymous users
 Which modules can be accessed (and which block can be viewed) by registered users
 Which components may be administered by a specific Administrator
 If the whole website may be administered by a specific Administrator
Each module has to be able to provide Administrators a specific Control Panel that can be accessed by the website
main Administration Panel. Each control panel has responsibility over its component’s features and configuration.
The following is the installation procedure for new components. It has been designed to be the most simple:
2
With the word webmaster, we mean the person or the organization that owns the website and is able to create, edit and de-
lete files on the server that hosts the website itself
3
We will assume that the words skin and theme are synonyms
4
With the word administrator, we mean the user that is authorized to make changes to the website. Often the webmaster is an
administrator too, but he may elect other administrator without electing them webmasters
1. The Administrator uploads onto the server, using FTP or a similar protocol, all the files belonging to the com-
ponent into an appropriate directory for the component
2. The Administrator, with his own credentials, enters the Control Panel and selects the new component to in-
stall
3. The system checks the digital signature of the component, and, if the user confirms, execute a specific in-
stallation script included in the component that configures it for first execution
Components must have an uninstall script.
It is a security requirement that the access to the data source is differentiated according to the privileges of the user
who is logged in. If he is not an Administrator, the data source must be accessed only using default stored proce-
dures. Else it can be accessed directly with its standard interface. This prevents some common attacks based on
sending bad input data that sometimes allow the cracker to get Admin privileges over the site.
When a user interacts with the portal (i.e. clicks on a command button), the request may be processed real-time
(synchronous request) or delayed (asynchronous request). The difference is that the asynchronous request is proc-
essed, together with other pending asynchronous requests, after 10 seconds (or a different interval configured by
the Administrator) by the first request or when a synchronous request is made. Here is an example: at a certain time
the user is writing a message for the Forums, and a block showing last Forum topics is displayed on the side. The
block just repeatedly requests for the last 10 topics posted, and it will reasonably use the asynchronous request
method. If it takes more than 10 seconds to the user to write a message and press the Submit button, a number of
updates will be done. When he finally posts the message, both the update request and the message posting request
(which is reasonably synchronous) are processed.
Another requirement is that multiple component requests can be processed in parallel for better performance.
When a component (or the core program) is unable to handle an error condition, that error has to be logged on the
server. Administrators can view the error log with full details on the error, and, up to their choice, report the error to
the development team through Internet, so they can examine the data and try to fix bugs.
Downloading a file from the server must be done only using a specific server-side script that fetches the file from a
read-protected directory, without allowing direct linking to the protected element. An option has to allow the Ad-
ministrator to prohibit direct linking to the download script from external sites.
It must also have a generator of RSS/RDF (7) feeds according to Semantic Web (8) specifications. Components must
use the main feed engine to provide specific feeds for their features (i.e. pictures in the gallery).
The final release of the application, however, should provide as many features as possible to allow the webmaster to
run a complete portal without having to develop the components himself. These are at complete discretion of the
developers and the analysts. Everyone in the community may recommend us new features and components to in-
clude in the official release.
2.2. System Requirements

A Rich Internet Application is a program that needs a Webserver and a data storage to run. The server stores all the
files of the application and all data required to run it. A piece of software runs on the client and the rest is executed
on the server to provide client interaction. The data source has to store all the data processed by the portal in a non-
volatile memory, not only to prevent data loss caused by server restart, but because the HTTP protocol used for
websites is stateless. It means that every communication between the client and the server does not consider the
past history of the transaction. This also implies that the program needs to make use of the concept of session. Usu-

ally, web applications use special marks to identify a session, which is associated to a specific user and/or program
state by the server, which keeps session data. Giving the client the responsibility of reporting its state to the server
may lead to a security risk, because client’s claims may be altered by a malicious user using a simple hack script.
Also, Rich Internet Applications based on Adobe Flash technology require a separate development for the client and
the server side, unlike classic scripting languages such PHP or ASP.NET that generate client code dynamically. The
Adobe Flex framework provides a development model that suits the needs of Rich Internet Applications, which inter-
faces remind the one of operating systems’ Graphical User Interface (GUI). The server side of the program can be
developed using any scripting language that runs over HTTP or even, thanks to Flex capabilities, with a dedicated
TCP/IP application. Whatever the choice is, a common protocol must be defined before implementing the client and
the server side.
The data source can be built up with various techniques: dedicated data files on server, XML repository and SQL da-
tabase are the most common. The SQL database is the easiest way to store data without wasting time projecting a
brand new program for storing data. More, PL/SQL stored procedures fit the requirement that if the user has no
admin privileges, the component cannot access the database directly running arbitrary SQL queries.
The error reporting feature requires the development team to build, and not necessarily distribute, a software sys-
tem that receives and stores all error reports that can be used by developers for debugging purposes. This system
must be developed as a separate project, independently from FlashNuke but using a common protocol.
We will define that protocol when implementing the client side. Design and development of the error reporting sys-
tem will be done separately during FlashNuke main components’ development.
2.3. QFD Analysis
2.3.1.Normal Requirements
The following requirements have been explicitly requested among the user requirements.
2.3.1.1. RN001: Graphical User Interface structure

The user interface must be bades on the following model (code snippet #1)

Picture 1 – An example of FlashNuke user interface
2.3.1.2. RN002: Plug-in Components

As described previously, the main requirement of FlashNuke is the possibility to expand it with new components ac-
cording to the plug-in model (9). The components must be loosely coupled to the main application. Recompiling ei-
ther the core5 or a component must not affect the other one. This means that the components must be stored in
files that are separate from the rest of the program, and loaded dynamically when needed.
A default module, chosen by the Administrators, is loaded when the user enters the website.
2.3.1.3. RN003: Plug-in Skins

Like components, visual skins must also follow the plug-in model. Artists can create and distribute skins over the
network. A visual skin has to affect as many aspects of the interface as possible. Some examples are text colour, font,
table border and shape, position and disposition, etc.
Skins have to be installed in a dedicated directory. The server scans for themes and produces the user a list. How-
ever, a default skin is displayed when the site is loaded.
5
Core: the part of the application that only provides support to the features of FlashNuke, but no specific feature. Exactly like
the kernel in an operating system. Both client and server have a core.
2.3.1.4. RN004: Multilanguage interface
The interface must support multiple languages. Simply all the text must change according to selected language. A de-
fault language can be selected by Administrators. However, they can enable the user to change the language manu-
ally or allow FlashNuke to automatically detect users’ favourite language. Components must be translatable.
2.3.1.5. RN005: User registration, authentication and privileges

FlashNuke must allow users to register to the website. A registered user is uniquely identified by his user name, and
must provide a valid email address, though email verification can be enabled or disabled by Administrators. The user
name is chosen by the user himself, but, of course, it must have not been taken by someone else yet. When logging
in, a user must provide his user name and either an alphanumerical password or a digital signature. The password
and the signature can be changed to improve security. However, if the user loses his password/signature, he must be
able to recover it (or having created a new one) by confirming his identity another way.
The following are the access level for FlashNuke:
 Anonymous user: a user that entered the site and has not logged in (yet)
 Registered user: a user that has authenticated
 Partial Administrator: a registered user that has Administrator privileges only on some components
 Supreme Administrator: a registered user that has Administrator privileges over all components and Flash-
Nuke main settings. We will generally call Administrators both partial and supreme ones. Specific differences
will be mentioned when needed
In order to change a user’s access level (electing or revoking an Administrator), a user must have Supreme Adminis-
trator or Partial Administrator over Users privileges.
Supreme Administrators can decide which access level is required to access a component.
2.3.1.6. RN006: Administration Panel

FlashNuke must provide Administrators an Administration Panel where they, according to their specific access level,
can administrate components (i.e. moderate Forums or nominate new Moderators). Each new component installed
may carry a specific Administration6 Panel, which has to be installed and uninstalled together with the component.
Some of the basic panels that Administrators can use:
 Site configuration: general parameters of the website, like site name, administrator email, default language,
default theme, enable or disable email verification
 User management: list of registered users, profile editing, privileges management
 Blocks management: disposition of blocks, access level
 Modules management: default module setting, access level
 Components management: installation and removal of components
Other panels will be added according to the needs.
2.3.1.7. RN007: URL Rewriting

The web portal must allow the user to bookmark and share direct URL addresses that load FlashNuke in a specific
desired state. This requirement is better explained by an example:
6
Sometimes we will refer to is as Control Panel
The user navigates the website and finds an interesting topic on the Forums about a problem a friend of him had.
With HTML websites, the user just copies the URL address in his browser’s address bar to paste it into a chat window
or email client. Or he can just bookmark it using web browser’s Favourites feature for personal reference. With
Flash-based websites, the URL never changes since a single SWF file (inside an HTML container) is loaded and the
browser is never affected by actions done by the user on the Flash movie.
FlashNuke must provide the possibility to translate a URL address into a state of the SWF movie considered as a fea-
ture. As for the example provided in the user requirements specifications, a URL like
http://tempurl.org/news?id=254102 must load the News module and display the article ID 254102. No specific tem-
plate has been defined yet.
2.3.1.8. RN008: Components Installation

New modules to be installed may require actions to be able to execute. Such actions may include preparing the data
source to host the data the component uses. Everything required to run the component must be included in an
automated installation script that automatically installs the new component. Of course, only a Supreme Administra-
tor may install new components after the webmaster uploads the files onto the server.
2.3.1.9. RN009: Synchronous and Asynchronous requests

Every action done by the user on the GUI may require server-side processing. The interface (and its components)
may require server processing on-the-fly or delayed.
We define Synchronous Request a server request, that usually returns information to the interface, that is done
when it is generated.
We define, instead, Asynchronous Request a server request that is postponed to be processed after a maximum de-
lay of 10 seconds (the Administrator may change the maximum delay) or when a Synchronous Request is generated.
2.3.1.10. RN010: RDF/RSS Feeds

FlashNuke must provide RDF/RSS feeds for news aggregators, according to the principles of Semantic Web. RSS pro-
vides quick access to updated content. It requires the correct implementation of RN007 in order to generate proper
URL/URIs.
2.3.1.11. RN011: Session state backup

This is a special feature for registered users. When the user leaves the portal by closing the web browser (or after a
system hardware or software failure like power loss), the view state of the interface is saved, and the user will be
prompted, after his next login, to restore the previous session.
2.3.1.12. RN012: Download Manager

FlashNuke is required to manage the files available for download with a mechanism that prevents direct linking7 of
files available for download8.
Direct linking is a problem for many webmasters, because people use to provide others (for example on their blogs)
the direct link to a file, consuming server’s bandwidth and often causing economic damage. Webmasters, even if dis-
tributing their files publicly, prefer that the user first displays a page containing the effective download link and
maybe some advertising. Other times, files must be kept private, away from unwanted visitors: often the user is re-
quired to register first, before downloading!
7
A direct link is a hotlink that points directly to the file where it’s stored on the server. It causes immediate download of the file
8
They can be the attachments of a forum topic, or pictures in a gallery
FlashNuke download manager must be configurable to optionally check that the user is not coming from an external
website.
2.3.2. Expected Requirements
2.3.2.1. RE001: Component SDK

FlashNuke works as a middleware. It is designed mainly to allow other developers to create new components that
will work within the web portal. FlashNuke must be extensible with no limit to satisfy every webmaster’s needs.
In order to allow other developers to code for the FlashNuke platform, a comprehensive documentation on how to
create new components that will run within a FlashNuke-based portal and interact with other components installed.
Such documentation must be published in the form of a Software Development Kit (SDK), including all source files
needed to compile new components.
2.3.2.2. RE002: Alternate Accessible version of website

The website must be usable by users with specific needs of accessibility. The web browser may not support Flash,
the device used to browse the website may be inadequate (i.e. a cell phone), or the user is affected by a handicap
that requires a specific assistive technology that is not compatible with Flash.
In this case, an alternate version of the website must be provided. This Accessible version must show the same con-
tent as the Flash version, but with no Javascript support, no Flash and simple graphics to enhance readability (10).
2.3.2.3. RE003: Privacy safety

This program is thought to be distributed in every country. Some have specific laws that rule over personal data ac-
quisition, processing, storage and distribution. FlashNuke, in order to not require substantial modifications to its
structure, must be designed to protect every user’s privacy, according to the principle the of informed consent9, in-
cluding the following rules:
 The website must require a minimum set of personal data in order to work properly. Other information must
be optional
 The user must be informed a priori10 about what data is collected by the system and how it’s used. Examples
include system logs, newsletters and showing everyone on the home page that the user is connected
 The user must opt-in. Nothing can be done with personal data without prior user explicit consent. For exam-
ple, the user’s email address may not be shared with marketing partners unless he gave explicit consent to
receive newsletters
 After opting-in, the user must be able to opt-out. He must be able to refuse any more treatment of his per-
sonal data and delete them (including his whole account) from the system
 The software must protect personal data against theft
 The webmaster should always act as he’s directly responsible, as a custodian, of users’ personal data
2.3.2.4. RE004: Installation script

In order to make the installation process of the FlashNuke CMS easier for non-experienced webmasters, an auto-
mated installation program is expected to be implemented. This program, under the form of an Installation Wizard,
9
This expression is often used in medical environment. However, it has a similar meaning in market and legal environments.
Here it simply means that the user who’s being provided a service is informed about what’s being done with his personal data
and the traces left by himself before accepting the service provision
10
Before the data is collected
must guide the webmaster step-by-step and configure FlashNuke for the first usage, including the setting of the Ad-
ministrator account that will be used to configure the website.
This script should use a web interface, because it’s not often possible (particularly under Windows) to directly access
the server’s command shell
2.3.2.5. RE005: Basic Components

Since FlashNuke is a general-audience software, it must be distributed ready for use. Analysts have to work on find-
ing which are the very basic services that a CMS should feature. All components will be developed independently
from the FlashNuke architectural project, and then included in the final package that will be freely available for
download.
2.3.2.6. RE006: System and Error Log

For security reasons, a website must have a System Log, browsable by the Administrators, that keeps track of user
actions in order to prevent dangerous or illegal actions such as attacks, finding the user that made an attack or trying
to find the vulnerability that has been used to attack the website. The System Log, however, should not be designed
as a privacy threat for users.
The Error Log, instead, is used to track error conditions that prevent regular usage of the website in order to find out
the cause of the error (often a bug in the system).
2.3.2.7. RE007: User Ban

Every website should have a function to preventing unwanted users from accessing the site. There are various rea-
sons that lead the Administrators to the decision of keeping someone out of a website. For example, a user that tries
to share illegal data (i.e. warez, child pornography) on a Forum, more than be reported to local authorities, should
always be kept away from those Forums.
2.3.2.8. RE008: Error Reporting

When the system, or one of its components, goes into an error state that prevents regular processing, the error is
logged as stated by RE006. However, the development team may be interesting in finding and fixing the problem
that caused the error, if internal to the system. The error reporting feature allows the Administrator to send a de-
tailed error report on the errors to the development team of FlashNuke and/or the component that went in error
condition.
2.3.2.9. RE009: System Restore Backdoor

Sometimes, due to server errors or misconfiguration, the website is unable to run at all. Administrators can’t get
logged in because the data source where the accounts are stored may be down. In order to provide Administrators a
way to restore (if possible) the system from a server crash without actually requiring server access, which could be
sometimes impossible, FlashNuke should implement a dedicated diagnostic interface that is completely independent
from the system and its malfunctioning. Administrators may log in and try to fix the problem, if possible.
The need of this feature has been suggested by the experience of a webmaster that, using Mambo CMS, is never
able to check and restore connectivity to his SQL DBMS when it goes offline, because Mambo displays a generic error
message. He needs to contact technical support or use SSH to fix the problem (sometimes due to table corruption).

2.3.3. Interesting Requirements
2.3.3.1. RI001: Portability of data source

An interesting requirement, not explicitly mentioned before, is the possibility for the webmaster to use a different
platform for data source unlike the one used during development. The webmaster can choose his preferred platform
at installation time without compiling the program with special options (or simply not recompiling it, using the same
binaries)
2.3.3.2. RI002: Pop-ups

In order to make the GUI more attractive and user-friendly, the GUI designers should consider the possibility of using
pop-up windows to interact with the user. Error messages, choices and other quick commands should be made using
a pop-up window or box that appears over the interface without changing its view until an action is done.
2.3.3.3. RI003: Transparency effects and animations

Marketing studies have reported that users are impressed by interfaces that change their state quickly, smoothly
and using special effects like transparencies or transitions. GUI designers should consider to do the possible to im-
plement such a feature, combined with the possibility of allowing themes to define their own effects and parameters
to make the website appear completely different by changing the theme.
2.3.3.4. RI004: Encryption of Sensitive Data

In order to protect the system against identity theft and unauthorized access, sensitive data, such as passwords,
should be encrypted or one-way hashed. If the security of the data source is compromised, the attacker must not be
able to obtain information login credentials or other sensitive information.
2.3.3.5. RI005: Login Flood Protection

In order to avoid brute force (11) or dictionary (12) attacks, login attempts should be protected against flood. It
means that a user may not login again after a failed attempt without waiting for a minute.
2.3.3.6. RI006: User Groups

Another interesting requirement, useful as support for modules, is to introduce the concept of group of users into
FlashNuke. Each group has a leader, the person who created the group itself, who can add and remove people from
his groups. User groups can be used by components to determine access level or perform group-actions, like mass-
messages. Particularly, users belonging to a group may have exclusive download access to some files.

2.4. Use Cases Analysis
Analyzing the user requirements for FlashNuke, we have generated the following UML Use Case Diagram. We will
then discuss each use case.
At a System Domain Model abstraction level, we have found that the only actor in the FlashNuke environment is the
user as we have defined it previously. The user, however, may obtain a specific role according to his access level.
Roles are hereditary, as shown in the diagram.
It must be noticed that the use cases that we’re describing here are general use cases made with the interaction of
the user with the basic system.
Each new component will add new use cases to each role a user can have.

«uses»
Enter website Register Check username
availability
Change Theme «uses»
Change language Confirm email

address
Switch between Flash

Load Module and Accessible version
Generic User
Recover lost
Password
Log In
Download a file
«extends»«extends»
«extends»
«uses» Upload a file
Digital Signature
Password login
login
Restore session
state
Change Password
«uses»
Registered User
«uses»
«extends» «extends»
Change Signature Revoke Signature
Edit own profile
and preferences
«extends»
Log Out
Manage files «uses»
Edit another
«uses» user's profile
Save session state
File Administrator User Administrator «extends»
«extends»
Ban user
Delete file Unban user Revoke

Grant Administrator privileges
Administrator privileges
«extends» «extends»
Change
configuration
«uses» View components
«extends»
Manage components
Administrator Install component
«extends»
Uninstall component

2.4.1. Actors
2.6.1.1. Generic User

In order to not make ambiguities, we will use the definition of Generic User for this role. A Generic User is just a user
that browses the website using his client. He is generally not logged in.
2.6.1.2. Registered User

A user becomes a Registered User after logging in. During the login phase, the user claims to be one of the registered
users and proves his identity using a password or a digital signature. We will analyze these two login methods later.
Before being able to login, a user (who is still not identified) has to register to the website, choosing a unique user-
name and providing at least his email address.
2.6.1.3. User Administrator

The User Administrator is a user that has all the Registered User privileges, plus the ability to manage the user ac-
counts of the website. Only a Supreme Administrator may nominate a User Administrator.
2.6.1.4. [Supreme] Administrator

A Supreme Administrator has full powers over the website. He can do exactly everything. We won’t consider com-
ponent-specific Administrators, that will be managed by their respective components independently.
In order to be an Administrator, a registered user must be explicitly nominated Administrator by a Supreme Adminis-
trator, with the only exception of the user that installs FlashNuke, who is automatically nominated Administrator.
The Administrator role may be revoked at any time by other Supreme Administrators.
2.4.2. Use Cases

2.4.2.0. Template (copy & paste)
 Name:
 Actors:
 Brief Description:
 Pre-conditions:
 Event flow:
o
 Post-conditions:
 Related use cases:
2.4.2.1. UC001: Enter Website

 Name: Enter Website
 Actors: Generic User
 Brief description: the user opens the website’s home page by typing its address in his browser’s address bar
or by following an HTML link
 Pre-conditions: none

 Event flow:
o Normal flow (Adobe Flash Player 9 installed)
 Flash Player loads the main file of FlashNuke
 FlashNuke client loads configuration
 FlashNuke GUI synchronizes with the server and starts a session
 FlashNuke loads the default theme and sets the default language
 FlashNuke requests the components that have to be displayed
 IF a specific service is requested11 (not the home page, i.e. displaying a specific news article),
then FlashNuke requests the service and overrides the module to load, then initializes12 it
 FlashNuke loads13 and displays14 each component on the GUI, and applies theme and lan-
guage
o Alternate Flow #1 (Adobe Flash Player not installed or not up-to date, but the browser supports
Flash)
 The user is prompted to install/upgrade Adobe Flash Player or to browse the Accessible ver-
sion of the website
 IF the user chooses to install/upgrade the player, the installation procedure is executed and
then the page is reloaded (use case restarted)
 ELSE the user is redirected to the Accessible version (use case UC002 is executed)
o Alternate Flow #2 (Browser doesn’t support Flash)
 The user is informed that Flash Player cannot be installed, and then is redirected to the Ac-
cessible Version (use case UC002 is executed)
 Post-conditions: the website is loaded and ready to be used
 Related use cases: UC002
2.4.2.2. UC002: Switch between Flash and Accessible version

For simplicity reasons, we have merged two symmetric use cases into one
 Name: Switch between Flash and Accessible version

 Brief Description: this case describes the switching from Flash version and Accessible HTML version of the
website (#1) and vice versa (#2)
 Pre-conditions (#1): the Flash version of FlashNuke is loaded
 Event flow (#1):
o The user selects the command to access the HTML version
o Flash GUI is unloaded
o The browser is redirected to an HTML page showing the same exact content of the Flash GUI
 Post-conditions (#1): the HTML version is loaded
 Pre-conditions (#2): the HTML version of FlashNuke is loaded
 Event flow (#2):
o The user selects the command to access the Flash version
11
We described the URL Rewriting in RN007
12
The module initialization phase will be analyzed when examining the client design and the communication system. For now,
we won’t care about it
13
We will refer to component loading as just downloading the required files from the server, without displaying the component,
which is in an non-initialized state
14
After a component is initialized with appropriate data, it can be effectively displayed. The user notices the component has
been loaded only when it’s displayed.
o The browser is redirected to the Flash GUI using a special URL to restore the system state
o The Flash GUI is initialized (UC001 executed) and the previous software state is restored with the
same exact content of the Accessible version
 Post-conditions (#2): the Flash GUI is loaded
2.4.2.3. UC003: Change Theme

 Name: Change Theme
 Brief Description: with this use case, the user is able to change FlashNuke theme choosing one among the
installed themes
 Pre-conditions: FlashNuke GUI15 is loaded
 Event flow:
o The user is displayed with a list of available themes
o The user selects a theme
o FlashNuke GUI applies the visual style to all of its components
 Post-conditions: FlashNuke GUI is displayed with a different theme
 Related use cases: none
2.4.2.4. UC004: Change Language

 Name: Change Language
 Brief Description: with this use case, the user may select a different language among the available ones to
navigate the website
 Pre-conditions: FlashNuke GUI or Accessible version is loaded
 Event flow:
o The user is displayed with a list of available languages
o The user selects a language
o FOR each component displayed
 The component is reloaded displaying text in the new language
 Post-conditions: FlashNuke is displayed in a different language
2.4.2.5. UC005: Load Module

 Name: Load Module
 Brief Description: the user loads a module onto the interface to use a service provided by the CMS
 Pre-conditions: FlashNuke is loaded
 Event flow:
o Normal (module initialized to initial state)
 The user selects the module from the module list, or activates a use case (in another com-
ponent) that requires loading the module
 The module previously displayed is unloaded
 The new module is loaded
 FlashNuke requests the initial state data from the server16
15
The accessible version must not support themes.
 The module is initialized to its initial state with the data obtained from the server
 The module is displayed
o Alternate (module initialized to a specific state)
 The user activates a use case (in another component) that requires loading the module
 The module previously displayed is unloaded
 The new module is loaded
 FlashNuke processes (server-side) the specific request and obtains data to use for module
initialization
 The module is initialized to a specific state according to the data
 The module is displayed
 Post-conditions: the new module is ready for use
2.4.2.6. UC006: Register

 Name: Register
 Brief Description: the user that wants to register to the FlashNuke-powered website obtains a new account
 Pre-conditions: FlashNuke is loaded, and the user is not a Registered User
 Event flow:
o The user selects the command to register
o The user fills a form with the following parameters:
 Chosen username
 Chosen password OR chosen Digital Signature
 Email Address
o The user selects the confirmation command
o The system checks if the username does not exist yet (UC007 executed)
o IF the username already exists, then an error message is displayed and the use case terminates in er-
ror
o The new user (class) entry is created into the data source
o IF the confirmation of the email address is required, then
 The user (class) goes in the state of being unconfirmed
 The use case UC008 is executed
 Post-conditions: the new user (class)17 is created and the user (actor) is ready to log in
 Related use cases: UC007, UC008
2.4.2.7. UC007: Check Username Availability

 Name: Check Username Availability
 Actors: none
 Brief Description: the system searches if someone has already registered with a certain username
 Event flow:
o The system load the list of registered users
o FOR each user in the list
 IF that user has a username matching the one to be examined, UC006 terminates in error
16
To understand what this means, imagine loading the list of articles in a News module, or the list of Forums in a Forum module
17
In this case, we mean an instance of the User class, as we will define later. We apologize for the ambiguity
o UC006 proceeds
 Post-conditions: the event flow of UC006 is affected
2.4.2.8. UC008: Confirm Email Address

 Name: Confirm Email Address
 Brief Description: the user completes the registration18 procedure by confirming that he’s the real owner of
the email address
 Pre-conditions: The option to require email address verification must be enabled
 Event flow:
o The system generates an authorization code and associates it to the user instance
o The system sends an email message to the address provided by the user containing the code and the
instructions to activate the account
o The user checks his inbox with his email client and follows the activation instructions
 Post-conditions: The user goes in the registered and confirmed state
2.4.2.9. UC009: Recover Lost Password

 Name: Recover Lost Password
 Actors: Generic User19
 Brief Description: this use case allows the user to change his password after losing his previous password or
digital signature
 Pre-conditions: the user must have already registered before (UC006)
 Event flow:
o The user requests a password change
o The user fills a form with either his username or the email address associated to it, and the new cho-
sen password20
o IF the user specified his username
 The system checks if that username exists
 IF the username does not correspond to any account, the use case terminates in error and
an error message is displayed
 ELSE the system obtains the email address associated to that account
o ELSE, IF the user specified his email address
 The system checks if someone registered with that email address
 IF nobody did (the email address does not exist), the use case terminates in error and an er-
ror message is displayed
o The system generates a secret authorization code and stores it associated to the user account
o The system sends an email message containing the secret code to the user’s email address
o The user checks his inbox with his email client
o The user follows the instructions in the message
o The system changes the password for that user
18
We may use the synonym sign up instead of registration
19
Even if the physical person acting as the user is a Registered User because he owns an account, the system doesn’t know his
identity yet and treats him as an anonymous user
20
In order to avoid complicating the specifications, we force a user to change his login method to a new password. A new digital
signature can be chosen later
 Post-conditions: the password for that user is changed
2.4.2.10. UC010: Log In

 Name: Log In
 Brief Description: the user authenticates on the website to obtain the status of Registered User and all the
privileges that come from that status
 Pre-conditions: the user has already registered (UC006), and is not banned
 Event flow:
o The user selects the login command
o The user enters his username or selects his one from a list of users that have logged in recently from
that machine
o The system checks if the username exists and obtains the authentication method chosen by the user
o IF a previous login attempt failed AND user didn’t wait 60 seconds, the use case terminates in error
and that is written on the log
o IF the user does not exist, the use case terminates in error and an error message is displayed
o EXTENSION POINT: the user proves his identity
o IF validation fails, the use case terminates in error, a log entry is written and an error message is dis-
played
o ELSE, UC013 is executed
o The user is added to the list of online people
o The user is logged in
 Post-conditions: the user changes his role from Generic User to Registered User or Administrator
2.4.2.11. UC011: Password Login (extends UC010)

 Name: Password Login
 Brief Description: the user authenticates using a password to prove his identity
 Pre-conditions: the user must have chosen to login using an alphanumerical password when he registered,
or changed password, or recovered a lost password
 Event flow:
o The user enters his password
o IF the provided password matches the stored password, THEN the validation succeeds, ELSE it fails
 Post-conditions: event flow of UC010 is affected
2.4.2.12. UC012: Digital Signature Login (extends UC010)

 Name: Digital Signature Login
 Brief Description: the user authenticates using a digital signature to prove his identity. This method is more
secure than using a password, but it’s rarely possible to safely use a digital signature on another computer
 Pre-conditions: the user must have chosen to login with a digital signature when he registered, or changed
the signature
 Event flow:
o The system generates a security code
o The user’s browser signs the security code and provides a signature to the system
o The system checks if the signature is compatible with the security code
o IF the signature is authentic, THEN the validation succeeds, ELSE it fails
 Post-conditions: event flow of UC010 is affected
2.4.2.13. UC013: Restore Session State

 Name: Restore Session State
 Actors: Registered User
 Brief Description: the user is made able to restore the previous session state21 of FlashNuke
 Pre-conditions: the user must have logged in correctly, and a saved session must be available
 Event flow:
o The user is prompted to choose from a list of saved sessions the one to restore
o The GUI is rendered by initializing the components to their previous state
 Post-conditions: the session is restored to the previous state
2.4.2.14. UC014: Change Password

 Name: Change Password
 Brief Description: this use case allows the user to change his password or switch from signature to password
login
 Pre-conditions: the user must have logged in
 Event flow:
o The user selects the command to change password
o The user is required to type the new password
o IF the user was using a password to log in, THEN he is required to retype his old password
o ELSE [if the user was using a digital signature], THEN UC016 is executed
o IF verification fails, the use case terminates in error and an error message is displayed
o ELSE the system changes user password
 Post-conditions: the user will have to use the new password to log in
2.4.2.15. UC015: Change Signature

 Name: Change Signature
 Brief Description: this use case allows the user to change his digital signature or switch from password to
digital signature login
 Event flow:
o The user selects the command to change the signature
o The user is required to select the new signature to use
o IF the user was using a password to log in, THEN he is asked to retype his old password
o ELSE [if the user was using a digital signature], THEN UC016 is executed
21
The exact set of displayed components, each one in a specific state. For example, if the user was displaying Forum topic #XXX
before leaving the website, FlashNuke will display that topic again
o IF verification fails, the use case terminates in error and an error message is displayed
o ELSE the system changes user digital signature
 Post-conditions: the user will have to use the new digital signature to login
2.4.2.16. UC016: Revoke Signature

 Name: Revoke Signature
 Brief Description: this use case acts as a verification for the old digital signature of the user that wants to
change his login method. Simply it verifies that the signature is authentic before revoking it
 Event flow:
o The system generates a security code and transmits it to the user’s browser
o The user uses his browser to sign the security code and transmits the signature to the system
o The system verifies if the signature is compatible
o IF the signed code matches the signature and the security code, the verification succeeds
o ELSE verification fails
 Post-conditions: event flows of UC014 and UC015 are affected
2.4.2.17. UC017: Log Out

 Name: Log Out
 Brief Description: the user terminates his session
 Event flow:
o The user clicks on the Log Out command
o The user is prompted to save the session state
o IF the user accepts, UC018 is executed
o The session is unlinked from the user
o The GUI is reloaded with all the components that an anonymous user can use
 Post-conditions: the user’s role changes to Generic User
2.4.2.18. UC018: Save Session State

 Name: Save Session State
 Brief Description: this use case is meant to save the user’s session state in order to restore it at a future
login
 Event flow:
o FOR each component displayed in the GUI, the system obtains its state and inserts it in a stack
o The stack is saved onto static memory
 Post-conditions: the session is saved and can be restored later

2.4.2.19. UC019: Edit Own Preferences and Profile
 Name: Edit Own Preferences and Profile
 Brief Description: the user can edit his personal preferences, like default language and theme, and can edit
his public profile that can be viewed by other users
 Event flow:
o The user is displayed with his profile information and preferences
o The user changes the settings to the desired values
o The user confirms the edit action
o The system saves user preferences and profile
 Post-conditions: user preferences and profile are changed
2.4.2.20. UC020: Edit another User’s Profile

 Name: Edit another User’s Profile
 Actors: User Administrator
 Brief Description: this is a special extension of UC019. A User Administrator may edit everyone’s profile
 Pre-conditions: the user must have logged in as User Administrator or higher access level
 Event flow:
o The Administrator selects the user to edit the profile of
o The Administrator is displayed with the user’s profile
o The Administrator changes the settings to the desired values
o The Administrator confirms the edit action
o The system save user preferences and profile
 Post-conditions: that user’s profile and preferences are changed
2.4.2.21. UC021: Ban User

 Name: Ban User
 Brief Description: the User Administrator may ban a user at any time, preventing him to access the website
 Pre-conditions: the user must have logged in as User Administrator or higher access level
 Event flow:
o User Ban
 The Administrator selects the user to ban
 The Administrator confirms the action
 The system inserts the user in the banned user list
o IP Address Ban
 The Administrator enters an IP address to ban
 The system inserts the IP address in the banned user list
o IP Range Ban
 The Administrator enters start and end IP addresses
 The system inserts the IP range in the banned user list

o Host Ban
 The Administrator enters the hostname to ban
 The system resolves the hostname to an IP address
 The system inserts the IP address in the banned user list
 Post-conditions: the user/host is banned
2.4.2.22. UC022: Unban User

 Name: Unban User
 Brief Description: this use case is just the opposite of UC021. A user that was previously banned may now
access the website again
 Pre-conditions: the actor user must have logged in with User Administrator privileges or higher access level.
The target user must have been banned before
 Event flow:
o The Administrator is displayed with a list of banned users and IP addresses
o The Administrator selects the one to unban
o The Administrator confirms the action
o The system removes the user from the banned user list
 Post-conditions: the user is no more banned
2.4.2.23. UC023: Change Configuration

 Name: Change Configuration
 Actors: Supreme Administrator
 Brief Description: this use case allows the Administrator to change the global configuration of the website
 Pre-conditions: the user must have logged in as Supreme Administrator
 Event flow:
o The Administrator is displayed with a list of options that can be changed
o The Administrator changes the options to the desired values
o The system saves the preferences
 Post-conditions: site configuration is changed
2.4.2.24. UC024: Manage Components

 Name: Manage Components
 Brief Description: this use case helps the Administrator manage the components available for FlashNuke
 Event flow:
o The Administrator is displayed with a list of modules available (UC025 executed)
 FOR each block, information on name, version, accessibility and disposition are displayed
 FOR each module, information on name, version, accessibility and administrators are dis-
played
o The Administrator edits the settings needed
o The system saves the new settings
 Post-conditions: new settings are saved
 Related use cases: UC025, UC026, UC027
2.4.2.25. UC025: View Components

 Name: View Components
 Brief Description: this use case
 Event flow:
o FOR each block in Blocks directory
 The system displays the component name and version
 The system checks if the block is installed
 IF the block is installed, the system retrieves its visibility and position, and displays an
uninstall command
 ELSE the system displays an installation command
o FOR each module in Modules directory
 The system displays the component name and version
 The system checks if the module is installed
 IF the module is installed, the system retrieves its visibility, and displays an uninstall com-
mand
 ELSE the system displays an installation command
 Post-conditions: the component list is shown
2.4.2.26. UC026: Install Component

 Name: Install component
 Brief Description: the user installs a new component
 Pre-conditions: the user must have logged in as Supreme Administrator. The component files must have
been already uploaded
 Event flow:
o A list of available components is shown (UC025 is executed)
o The Administrator selects the component to install
o The system checks the component’s digital signature
o IF the component is not signed or has a bad signature, the system warns the Administrator and asks
a confirmation
o ELSE [if the signature is valid], the system displays information about the author and asks a confir-
mation
o IF the user refuses to install the component, the use case terminates
o ELSE the component’s installation program is executed
 Post-conditions: the component is installed and ready for use
2.4.2.27. UC027: Uninstall Component

 Name: Uninstall component
 Brief Description: the user uninstalls a previously installed component
 Pre-conditions: the user must have logged in as Supreme Administrator. The component must be installed
 Event flow:
o A list of available components is shown (UC025 is executed)
o The Administrator selects the component to uninstall
o The Administrator is required to confirm the action
o IF the Administrator refuses, the use case terminates
o ELSE the system executes the component’s uninstall script
 Post-conditions: the component is uninstalled
2.4.2.28. UC028: Grant Administrator Privileges

 Name: Grant Administrator Privileges
 Brief Description: this use case is used to grant Administrator privileges to a registered user. It
 Pre-conditions: the actor user must have logged in as Supreme Administrator. The target user must be regis-
tered
 Event flow:
o While editing a user’s profile, the Administrator selects to grant him the Administrator privileges
o The Administrator selects which components can be administered by the new Administrator or if he
must be promoted to Supreme Administrator
o The Administrator confirms profile editing
o The system saves the profile and sets the new level
 Post-conditions: the user has now Administrator privileges
2.4.2.29. UC029: Revoke Administrator Privileges

 Name: Revoke Administrator Privileges
 Brief Description: this use case is the opposite of UC028
 Pre-conditions: the user must have logged in as Supreme Administrator. The target user must have Adminis-
trator privileges
 Event flow:
o While editing another Administrator’s profile, the Administrator selects to revoke him the Adminis-
trator privileges
o The Administrator confirms profile editing
o The system saves the profile and sets the new level
 Post-conditions: the old Administrator becomes back a normal user
2.4.2.30. UC030: Download a file

 Name: Download a file
 Brief Description: this use case describes the download process of a file using the FlashNuke download man-
ager component

 Pre-conditions: the file must have been previously uploaded
 Event flow:
o The user, aided by the interface, provides the identifier of the file he wants to download to the sys-
tem
o The system checks if the user has right privileges to download it
o IF user’s privileges are insufficient, THEN the use case terminates in error
o ELSE the file is sent to the user agent
 Post-conditions: the user agent has downloaded the file from website’s server
2.4.2.31. UC031: Upload a file

 Name: Upload a file
 Brief Description: this use case allows the user to upload a file to the system
 Pre-conditions: the file must exist on user’s client and must not exceed a certain size; the user must have
privileges for uploading
 Event flow:
o The user selects the file to upload and confirms the action
o The user agent sends the file to the server
o The system stores the file inside a protected directory and assigns it an identifier
o The system logs the upload
 Post-conditions: the file is uploaded on the server
2.4.2.32. UC032: Manage Files

 Name: Manage Files
 Actors: File Administrator
 Brief Description: the Administrator manages the available files uploaded by other users
 Event flow:
o The Administrator is shown the list of files uploaded by other users
o The Administrator views the properties of files (including uploader, date, time, size, etc.)
o The Administrator selects the file to delete and UC033 is executed
o The Administrator changes the property of other files
 Post-conditions: file properties change, and/or some deleted
2.4.2.33. UC033: Delete file

 Name: Delete file
 Actors: File Administrator
 Brief Description: the Administrator deletes one or more files
 Pre-conditions: the files must have been uploaded
 Event flow:
o The Administrator selects the files to delete
o The system deletes the file from the server and unlinks its identifier

o The server logs the action
 Post-conditions: the files are deleted
2.5. Class Diagram

Basing on the requirements listed for the system and for the use case derived by them, we have generated a System
Domain Model Class Diagram. Since we’re working in a high-abstraction level, this class diagram will contain only the
main entities, and their main properties/methods, as needed to allow the program to provide the basic services we
mentioned. Unlike for the Use Case Diagram, new components will be instances of their appropriate class (imple-
menting a common interface), but the eventual new classes they will add won’t be visible by the rest of the system.
It is important to notice now that in this Class Diagram we have two classes that implement an interface without
having different sets of methods: in UML, this is usually wrong, but we did it for a conceptual reason. Blocks and
Modules are different entities: even if we found that they can be said to be generically Components, Modules are in-
terface elements thought to provide real interaction and concrete services to the user, and Blocks are physically
smaller than modules because they just provide information and assistance to the user.
More, the Microsoft Visio 2007 we used to build the Class Diagram forced us to include some data types in the dia-
gram even for conventional reasons, like the Image class. We won’t care of the implementation now, but we in-
cluded it in order to associate those data types to class properties and methods
We will list each class and then analyze all of its properties, methods, associations and responsibilities. For some
classes, we will produce a State Diagram for better understanding the class behaviour.

Component
+Name : String
+Version : String
+Visibility : AccessLevel
#Signature : DigitalSignature
+Logo : Image
+Load()
+Unload() *
FileManager
+Install()
+Uninstall() FeedGenerator
1..* #CheckDigitalSignature() : DigitalSignature +Upload(in NewFile)
#Administer() +Download(in File : File)
+GenerateFeed() : XMLDocument +Delete(in File : File)
+SetProperties(in File : File, in NewProperties)
* Singleton
1
*
Block +Founder Module
File
1
+Name
0..1
+Type
0..1 *
* +Size : Long
+Downloaded : Integer
* +TimeOfUpload : Timestamp
UserGroup
+SetProperties()
+Name * +Download()
*
+AddUser(in User : User)
* 0..1 +Founder #Uploader 0..1
+RemoveUser(in User : User)
User
* Theme
+Username : String
+Name : String
#Password : String
-Header
-Footer
#Email : String
-Stylesheet
+Avatar : Image 0..1
+LastLogin : Timestamp +Load()
#LastHost : Host * +Change(in NewTheme : Theme)
#LastIP +SetDefault()
+About : String
+Biography : String
+Member +DateOfBirth : Date Language 1..*
+Authenticate(in username : String, in password : String) +Name
+Authenticate(in username : String, in SignedCode : String) +Code
* +LogOut() * 0..1
#UpdateProfile()
+ViewProfile()
#ConfirmEmail()
Session
#ChangeEmailAddress(in newMail : String)
#ChangePassword(in newPassword : String) +Started : Timestamp
#ChangeSignature(in newSignature : DigitalSignature) +InactivityTime : Integer
1 *
-RevokeKey() +ViewState
+AddToGroup(in group : UserGroup) * +Save()
+RemoveFromGroup(in group : UserGroup) +Load()
1
+EditAvatar(in NewImage : Image) +Login()
1..* +RecoverLostPassword(in username : String) +Logout()
«struct»Host
* +Hostname 1
+IPAddress
PartialAdministrator *
*
#AdministerComponent(in Component : Component) 1
0..1
SystemLog SystemEvent
BannedUserList Singleton -Time : Timestamp
+ViewLog() 1 *
+Ban(in User : User, in LastHostToo : Boolean)
SupremeAdministrator +Ban(in Host : Host)
+Unban(in User : User, in BannedHostToo : Boolean)
+Unban(in Host : Host)
#ChangeConfiguration()
#ViewLog() : SystemLog Singleton
#ManageComponents()
ErrorLog SystemError
-Component : Component
+ReportAllErrors() -TechnicalInfo
+Report()
1
*

2.5.1. Virtual Class Component

This virtual class provides the common methods and properties for FlashNuke components. Blocks and Modules are
components. We will describe the peculiarities of each one in their appropriate section.
2.5.1.1. Properties
2.5.1.1.1. Name: String <PK>
The name of the component. Works as unique identifier for each component category.
2.5.1.1.2. Version: String

The component’s version number. Useful when upgrading.
2.5.1.1.3. Visibility: Enumeration AccessLevel

This property controls the privileges level required to use the component. Its possible values are:
 Everyone: every user (registered or not) can use the component

 Registered: only Registered Users can use the component
 Admin: only Administrators can use the component
It is important to understand that a specific component may include features that, for technical reasons, require reg-
istration.
2.5.1.1.4. Signature: DigitalSignature

If set, this property contains all the information about the digital signature of the component.
2.5.1.1.5. Logo: Image

An image representing the component.
2.5.1.2. Methods
2.5.1.2.1. Constructor
The constructor for this class is an unusual kind of constructor. We are working at a System Domain Model level, so
no execution of code is expected. So we define the constructor for a component its physical upload into the compo-
nents’ directory.
Only the webmaster can run the constructor (since having access to server’s file system)
2.5.1.2.2. Load()
This method is used to load a component onto the Graphical User Interface (GUI). This method initializes the com-
ponent and displays it to the user. The user will then be able to use the component the way it’s designed to. This is
similar to a constructor, but as we will see in detail, the Component constructor is the physical upload of the files.
Every user with appropriate privileges can run this method after the module is installed.
2.5.1.2.3. Unload()
This method is called when the component is to be hidden from displaying, for example when changing the set of
displayed blocks or when changing the displayed module. Substantially, it works like a destructor method because an
unloading component must destroy all temporary data instantiated and free memory, but the real component de-
structor is its physical deletion from the server.

Every user that have loaded the module can run this method.
2.5.1.2.4. Install()
This method is used to install the component. Installing a component means doing the necessary actions to get it
ready for first execution. In many software systems, the installation of a component may require the unpacking of
the installation package, the copying of files to appropriate directories, and the registration of the component into
the system so other components can notice its presence.
The installation process requires the checking of the digital signature with the CheckDigitalSignature() method. The
Administrator is required to confirm the installation after viewing signature details.
Only the Supreme Administrator may run this method.
2.5.1.2.5. Uninstall()
This method is used to uninstall a component. Uninstalling a component means removing it and every element cre-
ated by it from the system. The system itself is then put into a state like the component was never installed. It gen-
erally requires the cancelling of the system registration process that the installation did, and the deletion of the files
that were created during the installation and/or the execution of the component.
Only the Supreme Administrator can run this method on installed components.
2.5.1.2.6. CheckDigitalSignature(): DigitalSignature

This method is used to check the digital signature of the component. Checking the signature, if present, is made of
two phases: first the system verifies that the component matches its signature in order to prove it has not been al-
tered, then it checks the identity of the signature owner by comparing the signature to the certificate included in the
component.
This method is called by the Install() method.
2.5.1.2.7. Administer()
This method is the main Administration method for the component. It allows an Administrator to control the behav-
iour of the module, or to perform operations that require high privileges. Each component must override this
method to provide real administration functions, such as topic lock on Forums, or picture deletion on Picture Galler-
ies.
Only the component’s Administrators and the Supreme Administrators may call this method, using their Administer-
Component() method.
2.5.1.2.8. Destructor
As for the constructor, we here define the Destructor as the physical deletion of all the files related to the compo-
nent, after it’s been uninstalled.
The destructor is run by the Uninstall() method or manually by the webmaster.

2.5.1.3. State Diagram
Install / CheckSignature Load
Installed Loaded
Uninstall
Unload
In order to better understand the common behaviour of all components, we created a UML State Diagram that
shows the global states of a component, either Block or Module.
2.5.1.3.1. Initial State

The component, after being physically uploaded, is in its initial state. It cannot work, because it needs installation.
The components exits from its initial state when the installation is executed.
2.5.1.3.2. Installed
When the component is in this state, it is ready to be loaded by the user who is browsing the website, if he has ap-
propriate access level.
The component exits this state when loaded or when uninstalled
2.5.1.3.3. Loaded
The component is loaded and ready to provide its services to the user. This is a special composite state. Every com-
ponent can be in any specific state when it’s loaded. For example, a Picture Gallery module, while loaded, may be in
the state where the user is displaying the list of categories, or a specific picture, or be in upload mode, etc. This is,
then, an abstract state that every single component must extend.
2.5.1.3.4. Final State

In this final state, the component has been uninstalled and deleted from the system. No traces of it are left: every-
thing is like before installation.
2.5.1.4. Links and composition

2.5.1.4.1. Language
A component may be presented in one or any languages
2.5.1.4.2. Partial Administrator

A component may be administered by a number of Partial Administrators
2.5.1.4.3. Supreme Administrator (inherited by PartialAdministrator)

A component may be administered by all Supreme Administrators
2.5.2. Class Block

This class represents a block on the interface. As we have defined in the beginning, a block is a small UI element dis-
played on the side of the interface to provide information or access to specific features.
A block is a component, so the Block class inherits from the Component class. The Block class, at the System Domain
Model abstraction level, does not provide further methods. However, single blocks may provide specific service with
related methods. So each block would be an instance of a class that inherits from this one.

2.5.3. Class Module
This class represents a module. As we have defined in the beginning, a module is a large UI element appearing
prominent on the interface to provide a specific service and user interaction.
A module is a component, so the Module class inherits from the Component class. The Module class, at the System
Domain Model abstraction level, does not provide further methods. However, single modules may provide specific
service with related methods. So each module would be an instance of a class that inherits from this one.

2.5.3.1.1. File
A number of files may be uploaded from within a module. As we will see later, the file will inherit module’s access
level.
2.5.3.1.2. FeedGenerator
A Module may be composed by a number of Feed Generators
2.7.3.1.1. UserGroup
A Module may create and manage a number of groups
2.5.4. Class FeedGenerator

This class represent a generator of RDF/RSS feeds. This class provides the XML output for feeds related to a module.
Each instance of the FeedGenerator class generates a unique feed. Examples are:
 News Module
o Latest news
o Most popular news ever
 Forum Module:
o Index of sub-forums
o Latest topics (global)
o Latest topics (forum-specific)
 Picture Gallery Module:
o Random pictures
o Index of categories/albums
o Latest pictures (global)
o Latest picture (album-specific/category-specific)
2.5.4.1. Methods
2.5.4.1.1. GenerateFeed():XMLDocument
This method generates an XML document containing the RDF/RSS feed requested. The generation of the feed is
done using the module’s specific methods, so no explicit responsibly is shown in this document
Everyone can use this method. It is usually invoked by RSS readers installed on clients.
The XMLDocument data type must be either defined at programming language level, or manually implemented in
FlashNuke if the platform does not provide XML APIs.

2.5.4.2.1. Module
A Feed Generator is part of one Module only
2.5.5. Class User

This class represents a Registered User. It contains the data of users that have signed up to the website.
Before continuing, it should be noticed that the Generic User, depicted as an actor in the Use Case Analysis, is not
represented by any class in the system. A Generic User may be anonymous22. Even if the Generic User is an impor-
tant entity in the system, so we simply say the following:
An empty instance of the User class represents the Anonymous user
The empty instance is usually represented by the null value in programming languages. The Anonymous user has a
special property: it refers to more than one physical user. Due to its definition and properties, the Anonymous user
cannot be banned or be member of a group.
2.5.5.1. Properties
2.5.5.1.1. Username: String <PK>
The username identifies the user. This is a primary key, so it’s a unique identifier. Apart from the obvious require-
ment that two users cannot have the same username, no specific requirement on allowed characters or length has
been defined yet. They will depend on the platform requirements.
2.5.5.1.2. Password: String

The password is used in the login process to authenticate the user. When logging in, a user must prove his identity to
confirm he’s the person that registered with the username provided.
This field is protected: it cannot be publicly visible for obvious security reasons, but can be accessed by the login
method.
This field is optional, as we will see now for the Digital Signature.
2.5.5.1.3. Signature: DigitalSignature

This field represents the digital signature of a registered user. It is used in digital signature authentication to prove
the identity of the user.
This field is protected: it can be accessed by the login method.
The DigitalSignature data type must be defined at programming language development, or else it must be manually
implemented.
2.5.5.1.4. Email: String

This is the email address of the user. This should be unique to prevent multiple registrations. An email address is a
string that matches a specific format according to RFC 2822 (13).
This property is not publicly accessible for privacy reasons. However, it can be used to send emails to the user with a
specific method.
22
A user that is using the website without registering is considered anonymous. It can be any person in the world
2.5.5.1.5. Avatar: Image
The Avatar is a small image representing the user. It is optional, and, if set, allows the system to display an image
near the username (for example, in Forum messages).
The Image data type must be supported at programming language level, or an alternate way to implement avatars
must be found by developers.
2.5.5.1.6. LastLogin: Timestamp

This indicates the last time the user logged in. It is useful to determine user inactivity.
2.5.5.1.7. LastHost: Host

This represents the last host used by the user to log in. This information is accessible only to User Administrators (or
Supreme Administrators) and is useful when banning the user.
2.5.5.1.8. About: String

This is an optional text description of the user, that will be displayed publicly to other people.
2.5.5.1.9. Biography: String

An optional biography of the user, that will be displayed publicly to other people.
2.5.5.1.10. DateOfBirth: Date

This is the optional birthday of the user. It can be used to determine his age, or to send him a Happy Birthday mes-
sage yearly.
2.5.5.2. Methods
The constructor for the user class is called during the sign up process. A new entry of the user class is created and
stored in the data source.
2.5.5.2.2. Static Overload Authenticate(username: String, password: String)

This method is used to authenticate the user when logging in. The username is verified to exist, and if the input
password matches that user’s password, login succeeds. This causes the current work session to be associated to the
user identity, and the change of the privileges associated to the work session.
This method can be invoked by an Anonymous user.
2.5.5.2.3. Static Overload Authenticate(username: String, signature: DigitalSigna-

ture)
This method is the alternate digital signature login. The username is verified to exist, and if the input signature
matches that user’s signature, login succeeds. This causes the current work session to be associated to the user iden-
tity, and the change of the privileges associated to the work session.
For detailed information on the signature verification algorithm, consult our Digital Signature reference.
This method can be invoked by an Anonymous user.
2.5.5.2.4. LogOut()
This method is used to terminate a registered user’s work session. This is used for security reasons to prevent other
people using the same machine to act as the user that was logged in.
This method can be invoked only by a Registered User.

2.5.5.2.5. UpdateProfile()
This method edits the user’s own profile. The user can edit his public information according to his needs. We have
omitted the parameters.
This method can be called only by Registered Users on themselves, or by User Administrators on other users.
2.5.5.2.6. ViewProfile()
This method shows the profile of a user.
This method can be invoked by everyone.
2.5.5.2.7. ConfirmEmail()
This method executes the email confirmation process required to activate a new user’s account. Details on the email
confirmation will be found in the Software Project Document.
This method is called by the constructor and by the ChangeEmailAddress() method.
2.5.5.2.8. ChangeEmailAddress(newMail: String)

This method is used to change a user’s email address. First the new address is checked to not be already registered
to somebody else, then the user is required to confirm the new email address with the appropriate procedure.
This method can be invoked only by Registered Users on themselves, with the exception of User Administrators, that
can call the method on anyone without having to confirm the email address.
2.5.5.2.9. ChangePassword(newPassword: String)

This method is used to change the user’s password. Should be used for security reasons to prevent other people
abuse of an account. The user is required to confirm his identity again (by typing his password or providing his signa-
ture) before completing the process.
This method can be called only by Registered Users on themselves.
2.5.5.2.10. ChangeSignature(newSignature: DigitalSignature)

This method is used to change the user’s signature. Should be used for security reasons to prevent other people
abuse of an account. The user is required to confirm his identity again (by typing his password or providing his signa-
ture) before completing the process.
This method can be called only by Registered Users on themselves.
2.5.5.2.11. RevokeKey()
This is a method used to revoke a user’s signature. It is similar to the digital signature login, but is used when a user
that was using a digital signature wants to change his signature or switch to password by setting a new one.
This method is called by either the ChangePassword() or ChangeSignature() methods.
2.5.5.2.12. AddToGroup(group: UserGroup)

This method is used to add the user to a group of users.
This method can be called only by the group’s founder.
2.5.5.2.13. RemoveFromGroup(group: UserGroup)

This method is dual to the AddToGroup() method. It removes the user from the group specified.
This method can be called by the group’s founder or by the user on himself.

2.5.5.2.14. EditAvatar(newImage: Image)
This is a general method to manage user’s avatar. It allows the user to perform the following actions:
 Upload a new avatar, if never uploaded one

 Delete the previously uploaded avatar
 Change the avatar
This method can be invoked only by Registered Users on themselves, or by User Administrators on any Registered
User. This method may be called within the EditProfile() method.
The destructor for the user class is called in the following two cases: the user deletes his own account, or when an
Administrator deletes another user’s account.
All data associated to the target user is deleted from the system.
2.5.5.3. State Diagram

The User class is critical in FlashNuke. In order to help developers understand the mechanisms of user management
in FlashNuke, we created a UML State Diagram for the User class. The diagram is made by a composite state, which
is described in the second dedicated diagram.
Retry confirmation / Reset timer
[if emailVerificationRequired] / Constructor

Unconfirmed
after: 24h / Destructor
[if !emailVerificationRequired] / Constructor

Confirm Email Address
Delete Account / Destructor
Banned by Admin
Banned Confirmed
Unbanned by Admin
Delete Account / Destructor
General State Diagram for User

Granted Administrator Privileges

Offline - User Privileges Offline - Administrator Privileges
Log Out Log In Log In Log Out
Revoked Administrator Privileges

Online - User Privileges Online - Administrator Privileges
Details for composite state Confirmed
2.5.5.3.1. Initial State

The user is in the initial state before completing the sign up process. At that time, the user still doesn’t exist in the
system. When completing the sign up process, the constructor is called and, if the email confirmation is required, the
user goes in the Unconfirmed state, else it goes in the Confirmed state at the default entry point.
2.5.5.3.2. Unconfirmed
A user is in the Unconfirmed state when he has completed the sign up process but not yet the email confirmation.
The user can’t log in or do anything else. As the user enters this state (it is not shown in the diagram), a timer is
started. When it reaches 24 hours of count, the sign up process is cancelled an the destructor is called. The user may
retry the email confirmation process and reset the timer. When the email confirmation succeeds, the user finally
goes in the Confirmed state at the default entry point.
2.5.5.3.3. Confirmed <Composite>

The composite state Confirmed groups all the states an active registered user may be in. The user is in this state after
completing the sign up process (including the email confirmation). The user may change its sub-state as we will see
later, or exit the state according to the following two events: the user is banned by an Administrator or his account is
deleted (by himself or an Admin)
2.5.5.3.3.1. Offline – User Privileges <Default Entry Point>

In this state, the user is not logged in -no active session- and has User privileges. This may affect displaying (i.e. the
icon of a light bulb turned off may be displayed).
The user exits this state by logging in or by being promoted Administrator.
2.5.5.3.3.2. Online – User Privileges

In this state, the user is online –has an active session- and has User privileges. This may affect displaying (i.e. the icon
of a light bulb turned on may be displayed).
The user exits this state by logging out or by being promoted Administrator.
2.5.5.3.3.3. Offline – Administrator Privileges

In this state, the user is not logged in -no active session- and has Administrator privileges. This may affect displaying
(i.e. the icon of a light bulb turned off may be displayed, and/or the name may be displayed with a different style).

When in this state, the user becomes an instance of the PartialAdministrator class.
The user exits this state by logging in or by being revoked Administrator privileges.
2.5.5.3.3.4. Online – Administrator Privileges

In this state, the user is logged in –has an active session- and has Administrator privileges. This may affect displaying
(i.e. the icon of a light bulb turned on may be displayed, and/or the name may be displayed with a different style).
When in this state, the user becomes an instance of the PartialAdministrator class.
The user exits this state by logging out or by being revoked Administrator privileges.
2.5.5.3.4. Banned
In this state, the user is banned and won’t be able to log in any more, until unbanned by an Administrator. When a
banned user tries to log in, the system should log the hostname from where the user attempted the log in and ban
that too to prevent registering with other accounts.
A user may exit this state only by Admin action: either the Administrator unbans him, or deletes his account com-
pletely.
2.5.5.3.5. Final State

Entering the final state is always preceded by the Destructor call. When in this state, the user has been deleted from
the system.

2.5.5.4.1. Session
A user may be associated to any number of session
2.5.5.4.2. Language
A user may select one language to display FlashNuke in during his work session. If none is selected, default is used
2.5.5.4.3. UserGroup <Founder>

A user may be founder of any number of groups
2.5.5.4.4. UserGroup <Member>

A user may be member of any number of groups
2.5.5.4.5. BannedUserList
A user may be or not in the Banned User List
2.5.5.4.6. File
A user may upload a number of files
2.5.5.4.7. Theme
A user may have at best one theme to display during his work session. If not selected, the default theme for the por-
tal is used
2.5.6. Class PartialAdministrator (inherits User)

With the PartialAdministrator class we want to describe an Administrator that has not full powers over the system.
On large website, it is important to distribute competences and responsibilities among many people. The partial

privileges are a feature required by RN005. As we have described, the partial privileges may be one or more of the
following:
 Privileges over Users (ban, unban…)

 Privileges over Files (delete, set permissions…)
 Privileges over Components (component-specific settings)
However, we did not model the first two kind of privileges. In order to do so, we assume the system is built with a
FileManager module (not the FileManager class, which is used for physical management) and a UserManager mod-
ule, or better that the File and User Administration functions will be provided under the form of a loosely-coupled
module, which will be an important part of final release.
2.5.6.1. Methods
2.5.6.1.1. AdministerComponent(Component: Component)
This method allows the Administrator to use a component’s Administration functions. Simply, this method is used to
call administrative methods on the provided component. The Administrator must have Administrative privileges over
the component in order to use this method.
This method can be called only by PartialAdministrator and, of course, SupremeAdministrator.

2.5.6.2.1. Component
A Partial Administrator may administer one or more components. File Management functions and User Management
functions are considered modules.
2.5.7. Class SupremeAdministrator (inherits Partial Administrator)

Finally, the command hierarchy terminates here, with the maximum authority over the website except the webmas-
ter. The SupremeAdministrator implements what we called Supreme Administrator, who is the user that has full
control over the website and all of its components using the Administration Panel. A Supreme Administrator may in-
voke all the methods inherited by User and PartialAdministrator classes, and other methods, that we are going to
describe now.
2.5.7.1. Methods
2.5.7.1.1. ChangeConfiguration()
This method allows the Administrator to display and change website’s global settings, including the site name, the
website email address (the sender that will be used in messages, i.e. admin@example.org), default theme and lan-
guage. The full list of website settings will be made later, during the project phase.
2.5.7.1.2. ViewLog(): SystemLog

This method is used to display both the System Log and the Error Log (which inherits from SystemLog class). These
logs contain detailed information on user activity and error conditions that could not be automatically handled by
the software.
2.5.7.1.3. ManageComponents()
This method allows the Administrator to manage components. It implements UC024, and is used to call component-
specific install/uninstall methods.

2.5.8. Class UserGroup
This class represents a group of users. Each group contains a number of users and can be created either by a user
(who has administrative privileges over the group), or by a module.
There are three special groups we won’t mention, and will be implicitly instanced in the system: the group that
represents every user of the system (registered or not), the group that includes all registered users and the one that
includes all the Administrators.
2.5.8.1. Properties
2.5.8.1.1. Name
This defines the name of the group. For groups created by users, this must be a unique property
2.5.8.2. Methods
The constructor creates the module.
The constructor can be called by any registered user or any module.
2.5.8.2.2. AddUser(User: User)

This method adds the target user to the group. The user must not be already member of the group.
This method can be called only by the group founder.
2.5.8.2.3. RemoveUser(User: User)

This method removes the target user from the group. The user must be member of the group.
This method can be called only by the group founder.
The destructor deletes the group.
It can be called only by the group founder, or by a User Administrator if the founder is a user.

2.5.8.3.1. Module
A User Group may be created by one Module. If not, the founder must be a user
2.5.8.3.2. User <Founder>

A User Group may be created by one User. If not, the founder must be a module
2.5.8.3.3. User <Member>

A group may be composed by a number of users
2.5.9. Class Language

The Language class is used to represent a language: either a language a component is displayed in, or a default lan-
guage selected by the current user or the system. Its usage is a direct consequence of the multilanguage interface
requirement, RN004. Many programming languages support languages as primitive data types.

2.5.9.1. Properties
2.5.9.1.1. Name
This represents the native name of a language. For example Italiano instead of Italian, Ελληνικά instead of Greek.
2.5.9.1.2. Code
This represents the two-letter ISO 639 code for the language. For example, it stands for Italian language, and el for
Greek language.

2.5.9.2.1. Component
A component may be written in one or more languages
2.5.9.2.2. User
A language may be chosen as default language by a number of users
2.5.10. Class Theme

This class represents a visual skin, as stated in RN003. A skin23 is used to display the UI elements (buttons, tables)
with a certain pattern of colours, fonts, borders, etc. This contributes to make a website unique, since each webmas-
ter may create his own skin and install it with simple steps. The implementation of skins (which are not used by the
Accessible version) directly depends on the potentials of the Flex framework. We will analyze the feasibility of this
feature later. For now, we are enumerating the main characteristics of a theme.
2.5.10.1. Properties
2.5.10.1.1. Name: String <PK>
This is the theme’s canonical name. It is used as unique identifier. We will define the allowed character set when im-
plementing the Theme Manager.
2.5.10.1.2. Header
This represents the theme’s header. Header, as described in RN001, is what is displayed on the top of the interface.
It usually contains a logo, or a quick-navigation menu. It’s up to the creativity of the artist to design a header that is
both attractive and useful to navigation.
2.5.10.1.3. Footer
This represents the theme’s footer. Footer, as described in RN001, is what is displayed on the bottom if the inter-
face. It usually contains a copyright notice for the theme, together with the author’s email address.
2.5.10.1.4. Stylesheet
The stylesheet (14) is used to describe how GUI elements have to be displayed, according to their nature or usage.
This is a programming language-dependent feature. Details for the stylesheet will be mentioned during the client
project phase.
2.5.10.2. Methods
Due to the plug-in nature of themes, the constructor for this class is the physical upload of its files into the system’s
directories.
23
We already said that the terms skin and theme are synonyms in software visual design environment
2.5.10.2.2. Load()
This method loads a theme for the GUI. Elements will be displayed using the rules of the stylesheet, and header and
footer will be initialized.
This method is called by the GUI when loading, or by the Change() method.
2.5.10.2.3. Change(NewTheme: Theme24)

This method is used to change the theme that is displayed on the GUI. The new theme is loaded, and all the ele-
ments will be displayed using the new theme. Usually, changing the theme requires unloading the previous one, but
we will face this detail when developing the client.
This method can be called by any user, and uses the Load() method of the new theme to load.
2.5.10.2.4. SetDefault()
This method sets a theme as default for the current user. In particular, this method creates or edit a link between
the theme object and an instance of the User class. If the user never selected a default theme, the link is created,
else the old link is broken and the new is created instead of that.
As for the constructor, the destructor for this class is the deletion of files from theme’s directory.

2.5.10.3.1. User
A theme may be set as default theme by a number of users
2.5.11. Class File

This class represents a file that has been uploaded to the website repository. We already made exhaustive examples
for the File Management system included in FlashNuke. The file is the main entity for this feature.
2.5.11.1.1. Name
This represents the file’s canonical name, including its extension.
2.5.11.1.2. Type
This represents the file type. Examples are audio files in MP3 format (.mp3), image in SVG format (.svg), BitTorrent
Metadata files (.torrent)
2.5.11.1.3. Size: Long

This represents the byte size of the file. As for the definition of the Long data type, it’s maximum limit is of about
16TB25
2.5.11.1.4. Downloads: Integer

This property is a counter. It simply counts the number of downloads for the file.
2.5.11.1.5. TimeOfUpload: Timestamp

This property contains the exact time when the file was uploaded.
24
Since the name is a primary key for the theme, the NewTheme parameter could instead be a string instead of an instance of
the Theme class, but this has no importance yet
25 64
Terabytes. 1TB = 1024GB. Then 16TB = 2 B = a very large file
2.5.11.2. Methods
The constructor is invoked during the upload of the file. It places the file into an appropriate directory on the server
and registers the file into the File Manager
2.5.11.2.2. Delete()
This method deletes the file from the system. It aliases the destructor.
This method may be called by the File Administrator, the uploader of the file or by the system, by request of the
module from where it was uploaded.
This method is aliased by the Delete() method.

2.5.11.3.1. FileManager
A file is part of the FileManager
2.5.11.3.2. User
A file may have been uploaded by a user or not
2.5.11.3.3. Module
A file may have been uploaded from within a module. This link is used to inherit the module access level. For exam-
ple, if the file has been uploaded within the Download module, it inherits the access level for the module when it
changes; so it will be accessible by all the users that can access the module if not differently specified.
2.5.11.3.4. UserGroup
A file may be downloaded by a group of users. Users with the same privileges level are considered as groups (for ex-
ample, all registered users)
2.5.12. Singleton Class FileManager

The FileManager class represents the FileManager component26 of FlashNuke, which is used to manage file uploads
and downloads. This is a singleton class: there’s only one File Manager in a FlashNuke-powered website. It handles
file upload and download with its methods.
2.5.12.1. Methods
2.5.12.1.1. Upload(NewFile)
This method is used to upload a new file into the system. This method uses the file provided by the client and the
constructor of the File class to upload and register a new file.
2.5.12.1.2. Download(File: File)

This method is used to download an existing file. The system checks that the current user has enough privileges to
download the file, then sends it to the user agent.
2.5.12.1.3. Delete(File: File)

This method is used to delete a file. It checks if the user has enough privileges to perform the action, then runs the
Delete() method for the file.
26
It has nothing to see with the Component class
2.5.12.1.4. SetProperties(File: File, NewProperties)

2.5.12.2.1. File
The File Manager is composed by a number of files
2.5.13. Class Session

The session class describes a work session.
2.5.13.1.1. Started: Timestamp
This property indicates when the session started, and is used to compute inactivity time.
2.5.13.1.2. InactivityTime: Integer

This property is calculated as the difference, in seconds, between the session start time and the current time.
2.5.13.1.3. ViewState
This property contains a snapshot of the state of FlashNuke interface. It includes the currently displayed module and
its internal view state, the current displayed blocks and their respective view states. It is used for saving & restoring
the session.
2.5.13.2. Methods
A new session is constructed each time a user enters the website. The constructor sets the Started property to the
system time.
2.5.13.2.2. Save()
This method saves the current session’s View State permanently on the data source. It will be restorable in a future
time by the same user when logging in.
This method can be called only by Registered Users on their own sessions.
2.5.13.2.3. Load()
This method loads a previously saved session for the current user. The View State is restored.
This method can be called only by Registered Users on their own sessions.
2.5.13.2.4. Login()
This method is used by an anonymous user to log in. This method simply creates the link with the User class.
We have omitted the parameters for this method for simplicity reasons.
This method can be called only by Anonymous Users on their sessions.
2.5.13.2.5. Logout()
This method is used by registered users to log out. This method simply breaks the link with the User class.
This method can be called only by Registered Users on their sessions.

The destructor deletes the session from the system. It is invoked when the user leaves the website or, more realisti-
cally, after a long inactivity time27.
There is only one problem with the destructor: as we will see later, each System Event, or Error, in the log, is linked
to the work session. Destroying the session causes the break of the logic link between the classes. There are two
possible solutions to that: the first one is to first save a permanent backup copy of the session class inside the log, so
the class won’t ever be reusable but will be browsed by Administrators; the second one, the one we chose, is to
automatically log the host and the user instead of the whole session.

2.5.13.3.1. User
A session may be associated to only one user
2.5.13.3.2. Host
A session may be associated to only one host
2.5.13.3.3. SystemEvent
During a session, a number of System Events may be logged. A single session may cause the logging of many events
2.5.14. Structure Host

This data type is used to represent a Host28 on the Internet. Hostname information is mostly used to track user ac-
tions in the System Log.
2.5.14.1. Members
2.5.14.1.1. IPAddress: String
This represents the IP Address of the host in its network form. It is a string that must match the IPv4 or IPv6 address
pattern.
2.5.14.1.2. Hostname: String

This represents the host’s canonical name. It’s a string that must not contain illegal characters for hostnames and
match the appropriate rules pattern.
2.5.15. Singleton Class SystemLog

This class is used to implement the System Log as required by RE006. The System Log is accessible only by Supreme
Administrators, and contains all the information on relevant events of the website. Each component may write new
events to the log. Here are some examples:
 A user registered
 A failed login attempt for an Administrator account
 Installation of a component (or its uninstallation)
 New forum created
 New picture gallery created
27
In web environment, when the user leaves the website, unlike what happens with classic applications, the server is not no-
ticed of it. So it’s actually impossible to detect when the user actually leaves the website. Moreover, we must consider the pos-
sibility that the remote client crashes, leaving the session open forever
28
A host is, by definition, a terminal connected to a network, no matter of its nature or role
2.5.15.1. Methods
2.5.15.1.1. VewLog()
This method shows the log to the current user. Showing the log means showing the list of events that occurred since
when the website opened, ordering them from the most recent to the oldest.
This method may be called only by Supreme Administrator.

2.5.15.2.1. Action
The error log is composed by a number of actions
2.5.16. Singleton Class ErrorLog (inherits SystemLog)

The Error Log is another implementation required by RE006. It keeps track of errors occurred during the execution of
FlashNuke. An error is an abnormal situation that cannot be automatically handled by the software. For example:
 A failed login attempt is not an error, because the system is prepared to that event
 In case the requested file is not available for download (the file system returns an error, like File Not Found),
but it’s expected to be there, an error condition is signalled and logged
 The user tries to display a private message, but the message body is not present in the data source: this is
another error
Errors are similar to system events. The Error Log has a special feature more than the System Log: it can report er-
rors to the development team. This feature, which implements RE008, is useful for debugging purposes. The devel-
opment team, analyzing the reports coming from many users, may reconstruct the conditions that lead the software
to an error and try to find a solution to that problem.
As for the SystemLog class, this one is accessible only by Supreme Administrators.
2.5.16.1. Methods
2.5.16.1.1. ReportAllErrors()
This method cycles over all the errors stored in the log and reports each of them to the designated development
team.

2.5.16.2.1. Error
The Error Log is composed by a number of errors
2.5.17. Class SystemEvent

This class simply represents an entry in the System Log. We won’t define specific properties for this class at this level
of abstraction. When implementing the software, we will have to define all the properties that characterize the large
variety of events that may occur on the system.
There is no destructor for this class, because the log cannot be erased for security reasons.

2.5.17.1.1. Time: Timestamp
The Time property indicates when the event occurred. It can be used to sort entries in the log.
2.5.17.2. Methods
The constructor is called when the system, or a component, wants to write an entry to the log. The constructor in-
serts the new object inside the System Log.

2.5.17.3.1. SystemLog
A System Event is part of the System Log
2.5.18. Class SystemError (inherits SystemEvent)

The SystemError class describes an error that may have occurred during the execution of FlashNuke. The system it-
self, or one of its components, may write entries in the Error Log, which will be browsed by Administrators.
This class inherits from the SystemEvent.
2.5.18.1.1. Component: Component
This property points to the component that generated the error. If not set, this means that the error was generated
internally by the system.
2.5.18.1.2. TechnicalInfo
This property contains all the technical info that were saved when the error was generated, and that can be useful to
debuggers. These information may contain a brief description, the value of some variables, etc.
The data type for this property must be enough free that a large variety of information may be stored inside it, with
no limitations.
2.5.18.2. Methods
2.5.18.2.1. Report()
This method reports the error to the development team of the component that generated it (or to the FlashNuke
Development team if the error was internal).
We won’t say any further about this feature at this time.

2.5.18.3.1. ErrorLog
A System Error is part of the Error Log
2.5.19. Singleton Class BannedUserList

The Banned User List is used to list the users that have been banned from the system by Administrators. Users in this
list won’t be able to login. Ban is a special treatment for people that can be considered dangerous for the website.

2.5.19.1. Methods
2.5.19.1.1. Overload Ban(User: User, LastHostToo: Boolean)
This method is used to ban a registered user, by adding him to the list. After its execution, that user won’t be able to
log in anymore or access the website at all. If the banned user attempts to log in again from another host, the login is
refused and the Ban method is called with the new host as parameter. If the LastHostToo parameter is set to true,
the last hostname the user logged in from will be banned too, using the overloaded version of this method. This
means that no user will be able to access the website from that host.
This method may be called only by a User Administrator29. This method cannot be used on a user that has been al-
ready banned.
2.5.19.1.2. Overload Ban(Host: Host)

This method is used to ban a hostname, for example in case of a repeated attack, by adding it to the list. The system
must refuse any request from the banned hostname, and of course any user (registered or not) using that host won’t
be able to even enter the website.
This method may be called by a User Administrator, or by the system itself. This method cannot be used on a host
that has been already banned.
2.5.19.1.3. Overload Unban(User: User, BannedHostToo: Boolean)

This method is the opposite of the Ban() method. It is used to unban a user that has been previously banned. He will
then be able to log in again. If the BannedHostToo parameter is set, then the host that was banned with the user will
be unbanned too.
This method may be called only by a User Administrator. This method cannot be used on a user that is not banned.
2.5.19.1.4. Overload Unban(Host: Host)

This method is used to unban a host that has been previously banned. Every user (if not banned) from that host will
be then able to use the website again.
This method may be called only by a User Administrator, or by its overloaded version. This method cannot be used
on a host that is not banned.

2.5.19.2.1. User
The Banned User List is composed by a number of Users
2.5.19.2.2. Host
The Banned User List is composed by a number of Host
29
Reminder: the Supreme Administrator, since inheriting from the User Administrator, which is an instance of Partial Adminis-
trator, has the same power. We won’t explicitly mention it anymore
3. System Design Document (SSD)

The purpose of this document is to identify and design the sub-components of the FlashNuke CMS Project. After hav-
ing analyzed the global layout of the program, we have to find what are system’s main components, and design
them as sub-projects. Another important goal of this document is the platform choice: till now, we have ignored
what will the final platform be, and all the entities designed in the System Domain Model were too generic for im-
plementation. Another important aspect of the project we will deal with in this document is the feasibility of re-
quirements. Without knowing the development platform, it is impossible to say if a requirement is really feasible, or
if it requires additional work for developers.
3.2. Decomposition and distribution

As we have seen in the previous document, FlashNuke is a Rich Internet Application. As for every web application
designed for the general public, the only available architecture is the client-server one. For each website that installs
FlashNuke, the program must physically reside on one single server, and then the required files are downloaded by
clients when needed. The standard for web applications is HTML, but we have been imposed Flash as development
platform as main user requirement. Most of server-side programming languages, since designed for HTML, requires
the developer to design only a server application that will generate HTML code for the client. This is not true for
Flash. Client and server applications are separate, even if they are physically stored on the same server. Separate
projects must be made for each component, and a communication protocol must be defined for them.
Each web application requires a data source to store permanent data in. This may be designed internally or exter-
nally to the server application. If external, a common interface (better if standardized) must be cho-
sen/implemented.
We have decided to opt in for a three-tier architecture. The architecture is composed by the client, the server and
the data base. Client and server will be developed independently, after defining the communication protocol. We
will use a standard system for data base.
3.3. Platform Choice

The System Domain Model is now complete. We have to decide, once for all, the specific platform under which
FlashNuke will run.
 Client: the client side, because of the specific requirement, will run on the Adobe Flash platform and will re-
quire the final user to install Adobe Flash Player 9 on his browser, whatever it is.
 Server: the server side of the program can be built using any scripting language or framework available, in-
cluding PHP (15), Java (16) and .NET Framework (17). We have chosen Microsoft .NET Framework 2.0, as it
allows development in VB.NET, C# and VJ# languages. A single application can be written even with all three
languages. Software developed for the .NET Framework, thanks to the Mono Project (18), can run on oper-
ating systems different from Microsoft Windows, but there may be some portability issues. More, .NET
Framework allows an easy development of the Accessible Version using ASP.NET
 Communication protocol: we chose the SOAP protocol for the Web Services (19), as we thought it’s the
most simple way to implement Remote Procedure Calls (RPCs) in web environment. As we have discussed so
far, most of the actions done by the user on the interface results in an RPC.

 Data source: FlashNuke will be using a SQL DBMS as data source. The DBMS must support transactions and,
more important, stored procedures. We chose MySQL 5 (20) which is free software. However, due to the
portability requirement RI001, the database must be designed to run on other SQL platforms.
 Error reporting protocol: nothing prohibits us to keep using Web Services. The exact format of error reports
must be analyzed in order to define full development specifications for both FlashNuke and the reporting
system. However, defining the structure of a system error may be sufficient for reporting.
The global system structure is the following: (for simplicity, the error reporting service is omitted)
Server side FlashNuke Services (default and components) SQL DBMS
FlashNuke Core Server FlashNuke Accessible Version Core
SOAP Engine SQL Driver ASP.NET
.NET Framework
HTTP Web Server
FlashNuke Services (default and components)
FlashNuke Core Client FlashNuke Accessible Version Core
Adobe Flex Framework
Adobe Flash Player JavaScript
Web Browser
Client side
Picture 2 – Global system architecture
3.4. Analysis of Requirements and Feasibility

Here we will analyze all software requirements mentioned so far and analyze their feasibility. Once we have chosen
the execution platform, we’ll have to consider its tools (i.e. default classes, libraries) and limitations in order to con-
firm that the program is not impossible to code. For some requirements that are hard to evaluate, we will produce
prototypes and we will include them in this documentation.

All the attachments and the prototypes are listed at the end of this document and are provided with the documenta-
tion package of FlashNuke. Some of them may require a special program to be opened.
3.4.1. RN001: Interface Model

The interface model we proposed is a very simple model of interface for CMS applications. There is nothing special in
that layout that Adobe Flex may not support.
The requirement is feasible
3.4.2. RN002: Plug-in Components

This is the most difficult requirement to evaluate is the support for plug-in components. Interpreted programming
languages, like PHP, do natively support the execution of new files at runtime because no machine code is gener-
ated. The same can’t be said for compiled languages. It must be noticed that a plug-in is different from what is usu-
ally called a module30. Modular programming is a technique that allows programmers to split a software in a number
of modules, in a way that each module (if a bug is found or an optimization is made) can be replaced with a new one
that does the same exact things as the previous without recompiling. In FlashNuke, we want to add completely new
features without recompiling the code.
Programming languages developers know the importance of running custom code at run-time, and various solutions
are available. We will analyze them in detail.
 Client: when running an Adobe Flash program (.swf), there may be the need to load a class that has never
been declared before from a file that is external to the assembly. Adobe Flex natively supports Flash libraries
files (.swc), but dynamic links with the module files must be done before compiling the application. Flex
Framework, however, includes a getClassByName() function that is used to create an instance of a class the
name of which is unknown at development time, and a control called SWFLoader that allows dynamic load
of SWF files at runtime. Unfortunately, the SWFLoader loads the target SWF file as a movie, executing its de-
fault code. The parent movie (the one that loads the target) may however run code from the child movie as
it’s an instance of a class (21). Anyway, in order to prove the feasibility of this requirement (loading an SWF
file which name is unknown at compile-time) we have produced a prototype that can be used as template by
coders.
 Server: since each component may have a server-side part, and this is in the 90% of cases, even the server
must be able to run custom code at runtime. Assuming we will be using .NET Framework, the Reflection is
the key feature to run custom code. In order to use reflection, an assembly containing the target class must
be created separately from the main assembly (possibly as a DLL Class Library), then the program will use a
system call to load a specific class at runtime from that DLL. We have produced a prototype to prove the fea-
sibility. It can be used as a template by coders.
 Data source: the data source must be able to expand in order to store data from new components, such as
Forum topics and messages, or news articles. Assuming we will be using a SQL DBMS, the addition of new
tables is done with a simple SQL query, as for the deletion.
The requirement is feasible
3.4.3. RN003: Plug-in Skins

Flex natively supports stylesheets for Flash applications. A stylesheet can be dynamically loaded at runtime, accord-
ing to Flex documentation. However:
30
We are talking about the general concept of module in programming languages, not FlashNuke modules!
 Can a stylesheet be changed at runtime? Or does it require reloading the program?
 Does loading a stylesheet from a main application affect the dynamically loaded child components?
The feasibility of this requirement has not been determined yet
3.4.4. RN004: Multilanguage Interface

In order to make a user interface support multiple languages, it must be coded without using plain text. Adobe Flex
does not provide default tools to create multilanguage interfaces, but a solution can be easily implemented by de-
velopers, for example using an XML dictionary and a set of function calls that is dedicated to handle language text.
Programming this way may be uncomfortable when using visual editors, and may force the developer to use direct
code editing. However, there is no need to produce a prototype.
The only problem linked by the multilanguage support happens in the following two situations: the webmaster in-
stalls a component not written in the language the website is running, or the development of a components pro-
ceeds unlike its translation (not all a component’s string messages are available in a certain language). For both
cases, we must define the following development rules:
 Each component must be developed at least in English, or at least it must have a default language (but we
insist for English)
 IF a certain desired language is not available within the component, the default language is used
 IF a string is not translated, the string in the default language is displayed
This requirement is feasible, and can be implemented at complete developer’s discretion
3.4.5. RN005: User registration, authentication and privileges

In order to keep track of a user’s state, each client must be associated to a unique session, which is associated to a
specific level of access. The data storage must keep the data of all the users (primarily username and password) and
their privileges. The server-side of the program will use the data to determine if a user action can be performed, or
sometimes to just filter the output.
The digital signature login, however, is a bit tricky to analyze. It requires a browser supporting digital certificates:
Internet Explorer and Mozilla Firefox do support digital certificates, but the same can’t be said for other browsers.
Client-side support for digital signature is made using Javascript. Flex supports calling Javascript methods (there’s an
entire chapter of documentation about it: we will cite only the ExternalInterface API), so a Flex application can actu-
ally apply a digital signature, generate a private key and extract a public key.
The server-side part of the script is easy: assuming we will be using .NET, there is a class that verifies digital signa-
tures using .NET cryptography engine. Else a verification function can be implemented following algorithm specifica-
tions.
The problem is with the Accessible version: since client actions are driven by Javascript code, and we refused to use
Javascript client-side for compatibility reasons, the Accessible version won’t support signature login, or will else re-
quire a Javascript-compliant browser to perform this authentication.
The avatars must not exceed 128x128px or they can cause display problems.
This requirement is feasible, but may violate the Accessibility criteria. A code template should be produced to help
developers

3.4.6. RN006: Administration Panel
An Administration panel is the best and easiest way to control a website. UNIX system administrators already know
the difficulties of configuring a program by directly editing its configuration files. More, a website always requires di-
rect server access (i.e. telnet, SSH, Remote Desktop) to obtain writing permissions over critical files, and the software
tools to make modifications to the website are not always available on the Administrator’s computer, especially in
the case he needs to access the website from a public place.
In order to let an Administrator operate anytime and from anywhere on the website, an Administrator panel has to
be built within the website’s user interface. The Admin functionality becomes available only when the user that logs
in has Administrator privileges. Other access attempts made by other users must be prevented and blocked.
The Administrator panel requires the implementation of the client interface and the server-side support for the ac-
tions done by the client. Admin modules may behave the same way as user modules, with the difference that every
action must be checked to prevent unauthorized access.
This requirement is feasible. However, the client-server protocol needs to consider the particular security needs of
the Administration panel
3.4.7. RN007: URL Rewriting

This requirement is very difficult to evaluate. First of all, we should introduce the URL Rewriting feature. Normally,
an HTTP server, when receiving a URL request, whether it points to a script or a static file, tries to load a physical file
located on server’s file system. URL to script files may sometimes be very complex for a user to remember. An ex-
ample could be http://tempurl.org/Default.aspx?service=901&id=134&layout=blue&sid=67ffbc09a348cd88a. This
URL does not explain what kind of page is displayed and what service is provided. Even if browsers can bookmark the
page assigning it a descriptive name, or even a full text description, it may be uncomfortable. More, search engines,
in order to prevent some abuses of ranking systems, do actually consider different URLs pointing to the same page
as the same URL, or sometimes (because different content is actually displayed) they assign a reduced score.
Search engines can be fooled by URLs that point to a different page for every content (for example
http://tempurl.org/news-054.html and http://tempurl.org/news-064.html, and this is the technique that is used to
pretend those pages are made manually by the web designer. The problem is that those HTML files do not actually
exist on the server, and it will be very server-overloading to create a new file for each page that must be linked. The
solution is to tell the server that, for a certain pattern, a correspondence with another effectively working URL exists.
The server must then interpret a certain URL pattern another way. Assuming we will use .NET Framework 2.0, a spe-
cial web.config directive works this way: it can actually rewrite URL in order to process a single file or maybe even an
instance of the HttpHandler class. The problem is that a Flash movie is always initialized at its start point by the Flash
Player.
The solution we found combines the usage of server-side scripting and client-side Javascript. Simply the server-side
script (i.e. Default.aspx file) generates a client code that contains not only the Flash Player instance linked to the
FlashNuke main SWF file, but a server-generated Javascript code that can be used by FlashNuke’s Flex APIs to obtain
data, like the module that has to be displayed and its initial state. The module itself may still access the Javascript
code and obtain its initial state without being passed any parameter.
We have generated no code yet, but all the information we provided is sufficient to prove the feasibility of this re-
quirement. However, we still want to include some pseudo-code to make an example:
//The actual URL is http://tempurl.org/news-1210.html

//This should display news article #1210

//The server has recognized the pattern /news-([0-9]*).html and rewrote it to
Default.aspx?module=news&id=$1
//Now Default.aspx is loading with QueryString parameters set
write(flashPlayerCode); //<object> tag for Flash Player
write(“<script type=\”text/javascript\” language=\”JavaScript\”>\n”);
for each parameter in Request.QueryString {
write(“var “+ param + “ = \”” + Request.QueryString(param) + “\”;\n”);
}
write(“</script>\n”);
/*This code wrote the following HTML:

<script type=”text/javascript” language=”JavaScript”>
var module = “news”;
var id = “1”;
</script>
*/
//Now the client side initializes Flash Player. FlashNuke, when rendering com-
ponents, does something like this
if module != null {
mod = load the module whose name is in the module variable
mod.requireInitialState = true;
} else {
mod = load default module
}
//The module, since the flag to require an initial state is true, expects an ID
parameter
displayNews(id);
This requirement is feasible
3.4.8. RN008: Components Installation

The possibility of an automated installation of components must be examined carefully. The installation of a compo-
nent requires the webmaster to upload the component’s files into a proper directory on the server, then access the
Administration panel and proceed with the installation.
There are two main possibilities for packaging and uploading components: the first one requires the webmaster, af-
ter downloading the package from the Internet, to unpack it and upload the files in the components’ directory (in
order to avoid problems, each component should be installed in a separated directory); the second one requires the
webmaster to upload the compressed package into a temporary directory (or even letting FlashNuke fetch the file
directly from the Internet) and then, as first installation step, let the system uncompress the files.
Both ways are feasible, but the second one requires the implementation of a compression library. Since we’re work-
ing in Open Source environment, there is the possibility to integrate an existing library into the project, like the
SharpZipLib Project for .NET.
The installation requires a digital signature check of the package. Assuming we’ll be using .NET, the Assembly class
provides a method to check a DLL’s digital signature. This may check only the server-side part of the component,
leaving the client-side at risk of alteration.

This requirement is partially feasible. The digital signature check requires a comprehensive study about possible
implementations
3.4.9. RN009: Synchronous and Asynchronous Requests

In order to implement this requirement, all requests directed to the server must be handled by FlashNuke GUI and
not by its components. All asynchronous requests must be buffered by the GUI, which will then start a timer or wait
for the first synchronous request to come. When the response comes from the server, the GUI must then deploy the
single response to each component using a default call that will be defined in the client implementation
This requirement does not apply to the Accessible Version.
3.4.10. RN010: RDF/RSS feeds

The generation of RDF/RSS feeds is independent from the Flash GUI, since a feed is an XML file generated by the
server. Even if the server doesn’t support XML APIs, generating a feed is still possible operating with direct text (but
the developer must pay attention to the syntax).
At a System Domain Model analysis, we have found that no information, maybe except users’ public information, is
interesting enough to implement a feed for it, but, as we analyzed, modules are the ones that produce feeds for
their data, like news and pictures. The options are two: either each module has its own feed generator, independent
from the rest of the program, or a central feed generator is implemented, and it then uses the module’s feed gen-
erator to obtain the data to display.
The second solution is the one that we chose for ease of programming.
Anyway, it is required that feed elements have a specific URL. This does not directly require the implementation of
URL Rewriting, but, as we saw in the analysis of that requirement, it is important that FlashNuke can be initialized to
a specific state by the URL.
It would be recommended, for search engines performance, to use Accessible Version URLs in feeds. For example,
the Invision Power Board (22) forum script automatically forces search engines to index its lo-fi version, which is
read-only and accessible. From there, users access the hi-fi version which is the full version of the board.
This requirement is feasible, even because RN007 is feasible
3.4.11. RN011: Session state Backup

The problem with this requirement is not the backup, since FlashNuke state can be encoded and saved into the data
source, but the restore. However, as we have seen in the analysis of RN007, a module may be able to be initialized to
a specific state using the Javascript technique. In this case, since the session restore is not requested when the HTML
host page is loaded, Javascript can’t be used. Instead, the FlashNuke GUI may follow the example mentioned there
to load the previous module and set it to a specific state after downloading data from server.
This requirement is feasible, but requires attention to module development
3.4.12. RN012: Download Manager

The Download Manager is a very sensitive component of FlashNuke, as we will define its important responsibilities.
First of all, it requires FlashNuke to globally manage all the files available for download: a unique archive for all files
must be implemented inside the data source. Each file must be uniquely identified, i.e. by a numerical ID or a GUID

(23), since the filename may cause problems with URL generation and interpretation. As we said in RN012 definition,
each FlashNuke component may manage files for download, and may set specific access policies for each file.
We need now to define those policies once for all. First of all, when a component is accessible only by Registered Us-
ers or Administrators, its files should inherit the component’s access level: if the Forum is globally inaccessible by
anonymous users, downloading files attached to messages should be allowed only to Registered Users; however, if a
forum31 is accessible to moderators only, the file cannot just be accessible to Registered Users; when sending a file
over a Private Message, its content should be visible only to the recipient (or maybe the sender too, if a history of
sent messages is kept). In the second case, since we’re talking about a small group of people, the most simple solu-
tion would be of simply not implementing additional protection, trusting that the members of the group won’t share
the secret file with anyone else; in the third case, it’s up to the two users involved in the communication to keep the
file secret if they want.
The alternate solution is to implement an additional security layer where each file has its specific download policy
(even using authorization tickets: what happens in large-scale download websites that manage terabytes of data and
need to provide a minimum-quality bandwidth to users). This can be useful against the history function of browsers
installed on public machines. This, however, may introduce the concept of group of users, that FlashNuke must
manage globally. For example, the Forum module uses FlashNuke core to create the group of moderators, or the
group of users that can access forum #X and then manages users according to the Moderator/Administrator’s needs.
A user32 may then be member of many groups (or just none) at the same time. A file could be then downloaded by:
 Every user with a specific access level (even just everyone)

 One or more groups of users
 One or more specific users
The technical problem with download managers is server overloading. Our experience teaches us that using a script
that fetches a file from disk and then sends it to the client is extremely memory-consuming, especially for large files.
The script must then be optimized in order to save memory and/or limit concurrent transfers.
The implementation of this download mechanism also requires the implementation of an upload mechanism. The
feasibility analysis must be focused on the analysis of the possibility of uploading files using a Flash interface, since
file upload using HTML is a common practice. This requirement will still be feasible, because if upload can’t be per-
formed using Flash the alternate way would be of opening a pop-up window for HTML upload.
That’s not the case of Flex, which implements the FileReference class. This class is designed to allow file upload using
HTTP POST method. It then requires a server-side script that accepts incoming files via HTTP POST and stores them.
This requirement is feasible, but attention must be paid to performance implications
3.4.13. RE001: Components SDK

FlashNuke can be considered as an operating system. It supports the execution of programs that are developed in-
dependently from the system itself. As for every operating system available, full documentation on how to develop
new application must be produced and freely distributed to software developers.
31
When we use the expression the Forum, we mean the global Forum module installed in FlashNuke. When we use the expres-
sion a forum (possibly using lower case), we mean an area inside the Forum grouping a number of topics in a specific discussion
area
32
Of course we mean a Registered User
The system must be designed to support the execution of unknown components, in the meaning that the services
those components provide are unknown at development-time. This is what RN002 basically requires. However, that
requirement does not consider that it’s imperative to distribute the documentation to the general public.
The best form in which that documentation should be distributed is the Software Development Kit (SDK). The SDK,
carrying comprehensive examples and code templates, not only provides the developer the classes and the inter-
faces required to build new software, but helps him understand FlashNuke’s architecture in order to fully use all the
software’s features.
Obviously, this requirement is feasible
3.4.14. RE002: Alternate Accessible version of website

The problem of accessibility is worldwide accepted as a primary objective to achieve when designing and developing
a website. Accessibility itself is often used as an important evaluation criteria.
Wikipedia defines Web accessibility as follows:
Web accessibility refers to the practice of making Web pages accessible to people using a
wide range of user agent software and devices, not just standard Web browsers. This is espe-
cially important for people with disabilities such as visual impairment. In order to access the
Web, some users require special software or devices in addition to a standard web browser,
or specially designed web browsers. Design for accessibility is a sub-category of good design
for usability.
The needs that Web accessibility aims to address include:
 Visual: Visual impairments including blindness, various common types of low vision
and poor eyesight, various types of colour blindness;
 Motor/Mobility: e.g. difficulty or inability to use the hands, including tremors, muscle
slowness, loss of fine muscle control, etc., due to conditions such as Parkinson's Dis-
ease, muscular dystrophy, cerebral palsy, stroke;
 Cognitive/Intellectual: Developmental disabilities, learning disabilities (dyslexia, dys-

calculia, etc.), and cognitive disabilities of various origins, affecting memory, atten-
tion, developmental "maturity," problem-solving and logic skills, etc.;
 Auditory: Deafness or hearing impairments, including individuals who are hard of

hearing;
 Seizures: Photoepileptic seizures caused by visual strobe or flashing effects.
Wikipedia, however, does not cite in that article the technical need of a user who’s using a user agent that doesn’t
support some advanced technologies like Flash, Javascript, etc. Since we’re working with Flash, the main problem is
not to force the user to install the Adobe Flash Player, either because his browser/operating system doesn’t support
it or just because he doesn’t want to. Even if this is the case of a very reduced percentage of users, this must be kept
in count.

Also, even if assistive technologies are developing towards the compatibility with Flash-based websites, it is almost
impossible today to index a Flash-based website in a search engine (the search engine’s crawler may be considered
as a user with an old browser).
In order to make a Flash-based website accessible, the only way is to actually develop a separate website, all based
on HTML (possibly XHTML (24) for compatibility with all modern browsers that strictly follow W3C standards), with
simple graphics and no use of Javascript tricks.
Developing the alternate website using the AJAX (25) technology is not recommended because it massively uses
Javascript which could be a problem for elder user agents.
The Accessible version must provide the same services provided by the Flash version. Since FlashNuke is based on
loosely-coupling its components, an alternate version must be developed for each component. Assuming we will use
.NET Framework, the Accessible version can be built using ASP.NET and may require the development of a single
Web Control for each component.
This requirement is feasible. However, it affects RE001 because the Accessible version needs to run loosely-
coupled components
3.4.15. RE003: Privacy Safety

Privacy is a very important aspect of any website. Nobody wants his mailbox filled by spam because a webmaster
sold the email addresses of his users out. Also, many people don’t want their web activity to be monitored and
traced for unwanted purposes, like direct marketing. Finally, some countries apply special enforced privacy laws to
defend users’ rights against savage usage of personal data.
However, browsing a website cannot always be completely anonymous, because both technical and security rea-
sons. The technical reason is based on the nature of Internet protocols and the fact that a user’s activity is monitored
and logged at least by his Internet Service Provider (ISP). The security reason stands on the server that hosts the
website. HTTP servers always maintain a log of web activities to help system administrator prevent, discover and re-
pair the consequences of an attack.
In order to defend user’s privacy, a set of options to define the level of information that can be automatically col-
lected and stored by the system must be implemented, together with an information method that automatically in-
forms the user about the particular situation.
More than working on user interface to clearly inform the final user about privacy condition, the Platform for Pri-
vacy Preferences (26) (P3P) can be implemented in FlashNuke to aid browsers. It is then important, and under the
sole responsibility of the webmaster, that what’s stated in the privacy information document does actually reflect
the website’s behaviour.
This requirement is feasible, and requires developers to study P3P specifications for the implementation
3.4.16. RE004: Installation Script

The installation script is a valid tool to set a FlashNuke-powered website up in minutes. After uploading all the files
related to FlashNuke, the installation script can be executed by the webmaster in order to automatically configure
the whole system. Always more web-based programs implement a setup wizard.
Other programs, in fact, require the webmaster to upload the files, then edit the configuration files, set directory
permissions, run the DB SQL script and some manual queries to set the Administrator account up.

Since the installation script must be executed only once, it is not required to build it using a Flash interface. Simple
HTML with not excessive art-working is enough for the installation script, which could even be written in English
only, if we assume that almost every webmaster knows a bit of English.
This requirement is feasible, and can be developed at a later time than the portal
3.4.17. RE005: Basic Components

No operating system is ever provided with its kernel only. All publicly distributed OS’s carry a set of default programs
for general use, like a word processor, a web browser, a calculator and even some nice wallpapers! Those compo-
nents are completely independent from the system, and developed after the kernel.
It has no sense to distribute a fully working web portal that doesn’t actually do… anything!! After the development
of FlashNuke core, developers may put their efforts (and spend their precious time) building the default compo-
nents.
We have identified the following as the most important modules for a general-audience CMS:
 Site news
 Forum
 Picture Gallery
 File Download area
 FAQs
 Private Messages33
 Custom Home Page
…and also the following blocks (some of them don’t actually require a fully engineered project, because every inex-
perienced programmer may build them up in a single day of work)
 Last news
 Last forum topics
 Last downloads
 Last pictures/Random pictures
 Quote of the day
 Calendar and Clock
 People Birthdays
 RSS Reader34
 Weather
 Stock Market watcher
This requirement is obviously feasible. It requires the completion of FlashNuke core and Components SDK
33
Actually, private messages between users, as for inter-process messages in operating systems, are a basic feature that is gen-
erally managed directly by the operating system. Even if we knew the importance of private messages from the beginning, we
also knew that it’s possible to develop this feature as a separate module. However, since the private messages module will be
included in the final release, it can be considered as a system feature
34
It display RSS feeds from external sources
3.4.18. RE006: System and Error Log
The system log can be built inside the data source. For every action that should be logged (for example, the nomina-
tion of an Administrator), an entry is written onto the log. All actions are time stamped, and are associate to the user
that did the action and the IP address he was using.
The system log can include the error log. The Administrators may consult the error log and, if necessary, report one
or more errors to the development team of either FlashNuke or the component that generated the error.
Each error must then be identified in order that multiple reports regarding the same error are considered as a single
error. Multiple reports, however, should not be discarded because they are often very helpful to discover hidden
bugs. Anyway, all the aspects of the Error Reporting feature will be shown in RE008.
Each component should be able to write entries into the Log, and those should be visible to component’s Adminis-
trators more than Supreme Administrators. For example, the lock of a Forum topic is an event that should be logged
to prevent moderator abuse.
3.4.19. RE007: User Ban

In order to implement this requirement, a list of banned users and host must be kept by the system, reasonably
within the data source. Every time a user tries to enter the website, his IP address is searched in the list: if it’s pre-
sent, all requests are refused. When the user tries to log in, his username is searched in the banned user list. If a user
that was banned tries to re-enter using a different host, that one should be blocked. Administrators may even block
IP ranges or subnets for best security, so the IP address is searched within ranges.
3.4.20. RE008: Error Reporting

The Error reporting feature is built on a client-server architecture, where the client is the server machine that hosts
the FlashNuke-based website, and the server is a program run by the development team at a known host. When the
Administrator browses the Error Log, he can choose errors to report to the development team. They will be sent
over the Internet (using any protocol, even with an email message). The report should contain additional informa-
tion, like the URL of the website where the problem happened and the FlashNuke version used. Custom FlashNuke
builds (recompiled by the webmaster) should not use the Error Reporting feature.
The development team, using a special program, will monitor reports coming from websites and will analyze the
problem trying to identify and solve the problem. Direct contact with webmaster and open discussions on Forums
are efficient tools in these cases. However, the development of the server-side of the error reporting system is com-
pletely up to every development team, which is not required to distribute the program.
FlashNuke Core team should still develop and distribute the error reporting server to simplify the work of other
teams.
This feature requires each error to be uniquely identified for traceability purposes!
This requirement is feasible, but it’s enough complex as a brand new project. We will deal only with the client side
in this documentation

3.4.21. RE009: System Restore Backdoor
We haven’t explicitly defined it so far, but it’s obvious that user accounts and login credentials are stored within the
data source, because every website does so. The problem with a SQL DBMS is that sometimes the DB may go down
for a crash or an error condition, or just table corruption. This affects the whole website, and sometimes it’s caused
by a problem that can be fixed using the DB’s standard interface, i.e. by running a REPAIR TABLE query. In these
cases, it is important to not force the webmaster (which, differently from an Administrator, has server access cre-
dential) to access the server and fix the problem from its command shell, even because sometimes the shell is not
available to webmaster, and that’s the case of many cheap or free hosting providers.
As long as possible, FlashNuke functionality should be restored using a web interface. First of all, there’s no need to
use Flash in this case, and HTML with poor graphic design is enough to fit an emergency situation’s needs.
The main problem is login: since the data source is unavailable, an alternate (but still secure) method has to be
found. A password is the best choice, because digital signatures may be unsupported by some browsers, and/or the
Administrator may not have the signature with him if in a public place. The big problem is with eavesdropping, and
there is nothing to do with that, more than changing the password often, except using en encrypted connection,
such as SSL. Using one-way cryptography is useless against eavesdropping.
A good solution would be to mark the password with a timestamp and encrypt the result with a one-way algorithm:
if they match the current time and the server’s password, then login succeeds.
The emergency password must be stored in a file on the server that absolutely must not be accessible via HTTP GET:
this is the weakest ring of the chain!! Directories must be protected against browsing!
3.4.22. RI001: Portability of data source

This requirement can be implemented using some kind of abstraction when coding. We already mentioned the ac-
cess to the data source only using default procedures when not an Administrator. Such a technique is feasible, but
what about the direct access to data source that may be required by Administrators?
Using a SQL DBMS, we want FlashNuke to run on MySQL, Oracle, MS SQL Server, etc. without sensing the difference
and without recompiling.
This requirement is feasible, because an abstraction layer can be used on the server-side script to mask DBMS-
specific calls. For example, the .NET Framework provides a set of virtual classes in the System.Data namespace, that
are inherited by DBMS-specific classes and drivers. Even if ODBC (like JDBC for Java) is a valid method to completely
abstract the DBMS platform, the usage of the specific DBMS driver is preferred.
However, using .NET Framework, there is a big problem with SQL stored procedures: for a strange reason, the syntax
between MySQL and MS SQL Server is different because of a “@” character, and also the class to execute stored
procedure cannot be instantiated by the connection class, but its constructor must be called manually, forcing to
implement a switch statement. All the problems related to the data source abstraction will be faced during the
server development.
This requirement is feasible, but may need attention during server development
3.4.23. RI002: Pop-ups

This requirement belongs to the group of interesting requirements that make a software attractive, appealing and
beautiful. It’s not a functional requirement, but a feature that should be implemented within the GUI.

The feasibility is proven by Flex’s PopUpManager class, which can be used to display a class (that implements the
IFlexDisplayObject interface) in front of the others, preventing the user to access other components displayed below
the popup. Classes that have to be pop-upped can be designed as operating system’s dialog boxes to let the user ex-
perience the same ease of use of his computer’s OS.
This requirement is feasible, and a code template will be released ASAP
3.4.24. RI003: Transparency effects and animations

The feasibility of this requirement depends on the possibility for Flex of handling special effects for components.
Since there are entire chapters of documentation that describe these Flex capabilities, there’s no need to go deep in
the subject. However, we just want to cite the Alpha property of displayed controls, which can even be handled by
the Theme Manager and defined in the stylesheet, and the concepts of state and transition, that can be used to im-
plement special effects using ActionScript 3.0.
This requirement is feasible. UI Designers are encouraged to send us code prototypes
3.4.25. RI004: Encryption of Sensitive Data

Before determining if and how can data be encrypted, we need to define what data is sensitive and must then be
encrypted. In order to make a website fully protected, all its data source should be encrypted. However, small web-
sites or large websites hosted on server that implement strong security layers, there’s no need to encrypt data that
should be decrypted prior to usage, because the key would be there, near to the data protected by it. It’s like closing
a door with a key and leaving that key in the keyhole.
However, the really sensitive data that should be protected are passwords: both inside the data source, where a
hacker could penetrate using an exploit, and also over the connection.
In order to protect the Internet connection, the best way is to use a protected channel like SSL. However, not all the
servers support SSL. An implementation of a cryptographic algorithm may be done “manually” by developers (since
we’re using ActionScript 3.0), but this solution is totally uncomfortable. Since the weak ring of the chain are pass-
words, we can focus on them only and leave the rest unencrypted.
The password must then be one-way encrypted, i.e. using MD5 (27) algorithm, into the data source, and the login
procedure must be designed in order to not transmit neither the full password nor its encrypted version over the
connection, but transmitting a code that
 Cannot let anyone obtain the password or its digest back

 Depends on other varying information, like machine’s IP address, timestamp, etc
It must be noticed that the Accessible version requires some Javascript to implement such login procedure, and we
refused to use Javascript for compatibility reasons. A compromise would be of implementing this feature for brows-
ers that support Javascript. Dynamically, a plain-text or a secure authentication is performed if the browser supports
Javascript or not.
This requirement is feasible, but may violate the Accessibility criteria
3.4.26. RI005: Login Flood Protection

This requirement is very simple to implement. It can use the System Log. Simply, as we will describe in Use Case
Analysis later, when the user fails a login, the event is logged and, when he tries again the system refuses the login
(even if credentials are correct) if the user didn’t wait 60 seconds.

3.4.27. RI006: User Groups

There’s nothing special to say about this requirement’s feasibility. It just requires an appropriate interface to manage
groups. We will not implement a request/approval mechanism for entering groups yet. This will be done in later ver-
sions of FlashNuke.
However, the most important aspect of groups is that they can be created by modules to manage internal require-
ments, such as access levels. So, there will be two kind of groups: those for which the founder/administrator is a
user, and those for which the founder/administrator is a module.
3.5. Responsibilities
As for every distributed software, we need to define the specific responsibilities for each subsystem in FlashNuke.
We already said the FlashNuke is a Rich Internet Application, built on a platform which is specifically designed for
those applications. As for every Internet application, which is designed to be used by the general public, particular
attention must be paid to security and robustness. However, the paradigm of RIAs is to leave the hard work to the
client, if possible.
So we’re now defining the responsibilities of the three subsystems:
 Flash Client: the client is responsible of providing user interaction through a Graphical User Interface and re-
quest data from the server. As for the RIA paradigm, if some operations are very CPU or network intensive,
they should be performed by the client to not overload the server. For example, parsing an external RSS feed
should be done by the Flash client, not by the server. However, not every operation can be performed by the
client in order to prevent manipulation of data. For example, the server cannot trust a client calculating the
arithmetic media of ratings for a news article, since the final result could be easily faked.
 HTML Client: the HTML client operates when the Accessible Version is used. This must provide only an es-
sential set of services to the user, necessary to provide the most important features to client that do not
support Flash (including assistive technologies), and sufficient to make the user not suffer the particular
condition. Since Javascript cannot be used in this version, all the computational work must be done by the
server. The HTML client is only responsible to request the server with the new pages to display.
 Server35: the server has to provide the client with the data needed for processing. Since running over HTTP,
transactions are always initiated by the client. Data is exchanged through the SOAP protocol, and everything
received from the client must be intensively checked in order to avoid manumission. For example, the server
must validate the login credentials at every request prior to accepting it, but it must avoid consuming exces-
sive CPU time. The server is also responsible of managing the website’s database. When running the Acces-
sible Version, the server is responsible of generating the user interface too.
 DBMS: the DBMS is responsible of storing permanent data, which is needed by the server for processing.
3.6. Identifying conventions

In this paragraph, we are going to define useful conventions for FlashNuke.
35
Including only the processing logic, not the client files that are transferred when user enters the website
3.6.1. Components: storage, identification and Administration
As we have defined previously, Blocks and Modules are components. They can be installed in FlashNuke at any time
and dynamically loaded as shown in the ParentChild example. Components have to communicate with the server,
exchanging data.
First of all, we need to clarify Components can not only be installed by the webmaster, but can be brought with the
system to provide basic work features. For example, the Administration Panel with the Website Configuration must
be included in the basic system package. There is no reason to deny considering the Administration Panel itself as a
Module, since we want to display it in place of the currently-displayed module. This means that the Compo-
nent.Administer() method mentioned in System Domain Model level class diagram will result in actually displaying a
new module on screen.
More than the Administration Panel, some components, like the login block, are vital to the system. In order to fit an
implicit extensibility requirement, we need to be open to all possibilities and so we define the following kind of com-
ponents:
 Blocks internal to the system

 Blocks installed by the webmaster
 Modules internal to the system36
 Modules installed by the webmaster
 Administration Interfaces internal to the system
 Administration Interfaces installed along with components
We already said that each component is uniquely identified by its name. There is only one channel of communication
between the client and the server: each request, coming from any component, is routed through a single server pro-
cedure. To allow parallelism (and save some server resources, for reasons we will explain later), multiple requests
are routed at the same time through the same channel. We also said that components’ files reside inside specific di-
rectories on server’s file system.
The best solution is the following:
Each component will be stored inside a directory with the name of the component, that will
work as identifier. All the components will have their directories stored inside a Components/
subdirectory of the website. A file inside the module, called manifest.xml, will store basic in-
formation on the component, including a tag that determines if that’s a block or a module.
The client-side script will be compiled at least in Default.swf, while the server-side script will
be compiled at least in Default.dll, with a set of functions to be used by the server for interac-
tion.
Since the Administration controls are executed under special circumstances, and must receive
special attention to protection, we will separate the channels of communication. A compo-
nent’s name, over the Admin channel, refers to the Administration Panel of that component, if
present. The client-side of the admin script must be compiled at least into Admin.swf.
System-internal components are referred by their names, which cannot be used for compo-
nents (for example, if the login block is called LoginBlock, a LoginBlock/ directory is ignored;
however, a loginblock directory may be theorically considered as a separate component)
36
We haven’t defined any yet
All file and directory names must be considered case sensitive.
Since not every file system supports case sensitive names, but we need to develop for every platform, developers
must code presuming the file system is case sensitive, but must choose directory names in order to not collide with
existing ones. For example, if a module called Gallery is present, developers of the gallery must refer to it with capi-
tal G, but other developers should not distribute their alternate picture gallery as GaLLerY.
We paid attention to case sensitivity because FlashNuke will mostly run on Windows, which is not case sensitive, but
is designed to run on UNIX using the Mono Framework, and UNIX is case sensitive.
3.6.2. Avatars
FlashNuke can associate a user to a picture (the so called Avatar (28)) representing him.
Supported formats for pictures are all the ones supported by Adobe Flash. Images must not
be larger than 128x128 pixels to avoid display problems. A default avatar, representing an
unknown user, is assigned to users that didn’t select a personal avatar. Each theme may
override the default avatar to combine its look with the global graphic appearance.
The preferred format is PNG. The user is allowed to choose an avatar from a default gallery
(included in the release) or to upload a custom avatar to the server, but the Administrator
may choose the options to enable. External linking is disabled for privacy reasons (external
images may be associated to scripts that are able to track down the user who’s displaying them).
SWF avatars are not allowed for security reasons. A Flash avatar, even if fantastic-looking, may carry dangerous
scripts within it.
3.6.3. User and Session Identifiers

We have defined several links between the instances of various important classes, like the User and the Session. In
client/server communication, it’s usually much bandwidth-consuming passing the whole class instead of an identi-
fier. Several server operations require the identification of the current working session or a user.
We have decided the following to permit easier handling of data sent over the network:
 A session is identified by Session ID, a 40-character alphanumeric string

 A user is identified by a User ID, a long37 number
Of course both must be unique.
3.6.4. Directory Layout

We have already defined a part of the server directory layout by defining naming conventions for Components. Now
it’s time to define, once for all, the full directory layout for the server. For each directory we will define the recom-
mended permissions between brackets, with the following convention: R read38 – W write – X execution39 of
ASP.NET DLLs. R/W/X must never be set for security reasons. Developers must follow the case sensitivity convention.
Components may obviously include other files, such as images/icons, inside their directories.
 ./: Server Root. [R/X]
37 64
The long type is, by definition, an integer represented on 64 bits (8 bytes). From 0 to approx. 2
38
In web environment, reading permissions means that the files inside the directory can be accessed using their relative URL. If
a file is not readable, the server returns error 403 - Forbidden
39
Usually this flag is not required by Internet Information Services for DLLs
o Avatars/: contains the avatars of users. [R/W40]
 [A lot of images]
 Custom/: this directory holds custom avatars. [R/W]
 [UID.xxx]: avatars are renamed to User ID
o Components/: stores components
 [A Component]: stores the files for the component. [R/X]
 Accessible.dll: Accessible Version script for component
 Default.swf: main client file for component
 Default.dll: main server file for component
 manifest.xml: contains information on the component
o Files/: stores files [W]
 [GUID]: each file is renamed to its identifier when uploaded
o Storage/: this directory is used by components as a writable space to create and store internal files
(for example, logs or caches). [W]
 [Component name]: each component stores files under a directory named like itself.
 Private: this directory is write-only, and used for private files. [W]
 Public: this directory stores files that can be read from HTTP. [R/W]
o Themes/: directory for themes
 [A Theme]/41: this directory stores a single theme. Its name identifies the theme itself. R
o Accessible.aspx: this file loads the Accessible version of FlashNuke
o Engine.asmx: this file is the main Web Service script
o Default.aspx: this files holds the HTML container of FlashNuke
o Default.swf: this file contains FlashNuke Core Client
o Download.aspx: this script allows downloading a file42
o Global.asax: default ASP.NET global class file. Required by the platform
o web.config: default ASP.NET configuration file. Required by the platform
3.6.5. Basics of communication protocol

The client/server protocol is a critical part of the application. When designing the protocol, it must be noticed that it
runs over HTTP, which is a non-transactional stateless protocol. This means that some information about the client
state must be transmitted at every request. In order to reduce as much as possible the overhead introduced by this
weakness, we decided to model the protocol following this pattern:
When executing a server request, the client always sends the Session ID to the server. If the
session is inactive (i.e. timeout), the server returns an error and refuses the entire request. The
client, both in this case and when it’s first loaded, requests a new Session ID to the server. Af-
ter obtaining it, a login may be performed sending the Session ID and the credentials. After
that, the Session ID will be used to maintain the user session state: the server will store the
association between the UID and the SID. For security reasons, the server must compare the
current IP address of the remote client to the one associated to the session to prevent attacks
40
We made this directory writable in order to create an Avatar Management component to add and delete avatars from com-
mon gallery
41
Before defining the content of the theme’s directory, we need to deeply study Flex theming. We don’t have such information
yet, but we will deal with this during client development
42
Instead of using an ASP.NET page, it can be considered to map the Download.aspx file to an instance of the HTTPHandler class
3.6.6. Error handling, logging and naming
We define an error an exception thrown by FlashNuke or one of its components that cannot be handled by the sys-
tem. For example, when the program tries to access the database but a table is damaged an exception is thrown and
it cannot be handled, resulting in an error. Instead, following the example of the paragraph above, if the server re-
fuses the current SID, the program automatically requests a new one to the server and the execution is resumed,
and that doesn’t result in an error.
When FlashNuke throws an exception from inside its code, that exception should be identified by a unique 32-bit
hexadecimal value with the following convention:
 The first 24 bits identify the package that generated the exception (for example: Core Client, Core Server,
News Client, News Server, Core Accessible, Forum Accessible), and the other 8 the specific exception
o Class 000000 represents Core Client (0x000 to 0x0FF)
o Class 00000A represents Core of Accessible Version (0xA00 to 0xAFF)
o Class 00000F represents Core Server (0xF00 to 0xFFF)
For example, a PermissionDeniedException returned when trying to use administrative features may have code
0xF53A.
When the error is logged, its instance should be identified by a GUID (23). This allows easier reporting and tracking
by the debug team when using the Error Reporting service43.
Notice: we said that an exception is marked by a unique identifier. This is intended for an easier track down of the
error. The identifier must be associated not to the instance of the exception, neither to its class, but to the part of
code where it’s generated. In the above example, the PermissionDeniedException has code 0xF53A when thrown
from the server-side of administrative panel, but when it’s returned due to an invalid operation in the News module
(i.e. rate an article again), it may have code 0xA457C, where [0xA4000-0xA4FFF] is the class associated to the server-
side of News module.
Because of this, proper documentation must be produced to track exceptions and their origin points. A full list of
known exceptions must be included in documentation. If possible, an online Knowledge Base (29) under the form of
a wiki (30) should be created in order to allow cooperative development of documentation
3.6.7. Website configuration variables

The website must be configured with proper parameters to run. They all are stored within the web.config file.
Here are the parameters:
 Site name: name of the website (ie. FlashNuke Web Community)

 Site URL: URL of the website (ie. http://www.fnukecommunity.org)
 Website’s Email: used as sender in all outgoing messages (ie. admin@fnukecommunity.org)
 Database Type: identifies the Database type among the supported ones (ie. MySQL)
 Low Privileges Database Connection String: contains the connection string used to access the DBMS when
running in normal mode
 High Privileges Database Connection String: contains the connection string used to access the DBMS when
running with Administrator privileges
 Welcome Message: a text message to be displayed prominently on the Home Page
43
It’s just necessary that an exception has a unique ID only within the website it has been generated at. When we will build the
Error Reporting Service, we will automatically distinguish exceptions with the same GUID sent by different websites
 Default language: determines the default language to use when rendering the portal
 Default theme: determines the default theme displayed, if no choice is made by the user
 Require email confirmation: if enabled, all users that want to register must validate the email address (con-
fimed opt-in)

4. Client/Server Interface

The first aspect of the project we will deal with is the client/server interface. In the previous chapters, we have de-
fined all the main aspects of the software, including the operations that involve interaction between client and
server, and we have chosen the communication protocol for them: SOAP. The purpose of this document is to define
the full list of functions that must be implemented on the server to accept client request, along with the full list of
parameters and the exceptions that may be thrown in case of errors. Since we are going to define a public interface
for a web service, attention must be paid to security: it doesn’t take much time to create a hacked client that calls
server-side methods maliciously sending wrong or unexpected parameters to perform illegal operations. Most of the
exceptions we will define for methods will be thrown only in case of an attack, since the client interface automati-
cally hides illegal operations.
4.2. Common classes and interfaces

In this section, we are going to define the fundamental classes and interfaces that both client and server must im-
plement in order to allow communication. Since we are using SOAP, which is based on XML, the first requirement of
all classes and interfaces involved in the client/server communication is XML-Serializability. Every class must be en-
coded into XML and then transmitted; the receiver then must use the XML code to rebuild the full object. In .NET,
XML-Serializability requires the class to implement the System.Xml.Serialization.IXmlSerializable interface
4.2.1. IDictionary
A dictionary is a name-value collection in which every item is accessed through an alphanumerical key. Dictionaries
are basically different from arrays. In arrays and matrixes, a single item is accessed by using its physical position in
the ordered list of items (this includes multi-dimensional arrays, which are basically arrays in arrays).
The following example shows a dictionary implementing a Person class:
[name] => John

[surname] => Doe
[gender] => {Male}44
[age] => 36
Dictionaries are more flexible than regular classes: this because dictionaries are random-access. The key, unlike the
property of a class, may be the value of a string variable, and such subject to runtime change. When trying to access
an unknown key, the programming language deals with the error situation either by returning a null value or by
throwing an exceptions.
Dictionaries are also known as Associative Arrays. VB.NET, C# and AS3 implement dictionaries and the IDictionary
interface. The XML-Serializability is granted since XML syntax is basically a dictionary. Programming languages have
internal serialization/deserialization functions that transform the key into the tag’s name and then encode the value
in XML (if the value is an atomic type, like Integer or String, it’s included in the markup, else the serialization is recur-
sive).
In the example above, the XML markup of the Person dictionary is
<name>John</name>
44
In this example, we assume that the gender value is an enumerative data type. As we will see below, enumerative types may
be serialized at programming language’s discretion
<surname>Doe</surname>
<gender>0</gender>
<age>36</age>45
4.2.2. IUser
The IUser interface is used to represent a registered user in FlashNuke. It is composed by the following properties:
Username (String): the username

Email (String): the email address of the user
Password (String): the MD5 hash of user password
PublicKey (ByteArray): the public key for Digital Signature46
Avatar (String): path to the avatar file, relative to Avatars/ directory. If null,
points to the default avatar
About (String): a self-written description
Bio (String): a self-written biography for the user
LastVisit (DateAndTime): time of last visit
RegistrationDate (DateAndTime): time of user sign up
IPAddress (Integer): the current or last used IPv4 Address for the user, encoded as 32-
bit Integer
Hostname (String): the current or last hostname
administrator (Boolean): if true, the user is an Administrator
otherinfo (IDictionary): other information about the user, added by components under
the component‟s name key
[component‟s name] (IDictionary): each key points to the information addedby the
component (i.e. under Forum key: list of forums the user is moderator of, number of
messages, last message…)
For privacy reasons, some fields must be left null except in rare cases. For example, the IPAddress and Hostname
fields must be visible only to Administrators.
When the username is set to null, the object represent the Anonymous user.
4.2.3. AccessPolicy
4.3. List of procedures

4.3.1. GetNewSID():String
This function is called by the GUI client to obtain a new Session ID. The server generates a unique random string of
40 alphanumeric characters, stores it into the DB Sessions table and sends it back to the client. The client will then
use it in further communications. This function is called when the client is loaded or when another method throws a
SessionExpired exception.
After logging in, the client interface must be rebuilt in order to show the components for the user’s level of privi-
leges. All active components must be informed of the log in.
4.3.1.1. Parameters
None
45
An alternate syntax to <name>val</name> is <name value=”val”>
46
Password and public key must always be null, except in the SignUp method for registering a new user. In this case only one
must be set. Having these parameters in the class helps simplifying the SignUp method
4.3.1.2. Exceptions
4.3.1.2.1. BannedUserException
This exception is thrown when the IP Address is banned. The client shows the error message, and it will be pre-
vented to perform any action.
4.3.2. SignUp(sid: String, newUser: IUser)

This method is used to let the user sign up. This method can be executed only by an Anonymous User. The user is
prompted to input personal information and choose the authentication method by typing a password or exporting a
public key. All the information are stored in the newUser object.
4.3.2.1. Parameters
4.3.2.1.1. sid: String
This parameter represents the session ID for the current session. As we have defined it, the SID is a 40-characters al-
phanumerical case sensitive code. The session must be active (timeout not expired).
4.3.2.1.2. newUser: IUser

This parameter includes the data of the new user to register. It is used to group function arguments.
Here is the list of information required to sign up:
 Username: must be unique47

 Email: must be unique
 Password: set to the MD5 hash of the real password, in mutual exclusion with PublicKey
 PublicKey: in mutual exclusion with Password
 Avatar: it’s always transmitted but can be set to null if the user didn’t choose a picture
 Bio: optional
 About: optional
4.3.2.2. Exceptions
4.3.2.2.1. SessionExpiredException
The SessionExpiredException is thrown if the session is expired. The session is not found within the database and it
must be renewed. The exception is handled by calling the GetewSID method and trying the login again (if the user
used the private key, signing must be performed again with the new SID).
4.3.2.2.2. InvalidArgumentException
This exception is thrown when either the username or email address are registered, or when one or more parame-
ters are incorrect. It depends on the exception code:
 00000F24: one or more invalid arguments (check error message for details). For example, both password
and public key set
 00000F25: User already registered
 00000F26: Email already registered
4.3.2.2.3. PermissionDeniedException
This exception is thrown if the current user is not Anonymous.
47
The client may invoke the GetUserInfo method and check if it returns a null value
This exception is thrown when the IP address of the current user is banned. The client shows the error message, and
the server logs the attempted operation.
4.3.3. Login(sid: String; username: String; code: String): IUser

This function is used to log a user in. Login is performed after the client is fully connected, or every time a new SID is
requested. When login is performed, the system evaluates user’s credentials and eventually associates the SID to a
registered user’s account, elevating the privileges automatically.
The login method, other than the SID, also requires the username and the authentication code to perform the op-
eration. If it succeeds, the system updates the database with the new data about the current session, and returns a
IUser object containing the data of the currently logged in user. If the authentication fails, a LoginException is thrown
4.3.3.1. Parameters
4.3.3.1.2. username: String

Represents the username in string format. User names are generally case sensitive: this depends on the DBMS case
convention. The user must be already registered.
4.3.3.1.3. code: String

The code is the authentication string that validates the identity of the user. We already said that there are two au-
thentication methods: password and digital signature. For privacy reasons, there is no method that tells the client
which authentication method is chosen by the user. So the user must perform the authentication by either typing
the password or using his private key.
In order to prevent eavesdropping attack, the password must never be transmitted in clear. Using SSL, as we said
many times, is the best option. But we also said that SSL is CPU-intensive and is not generally available within cheap
or free hosting services. The best option is to transmit the MD5 hash of the password (the encoding is done by the
client itself). The hash is then compared to the hashed password stored on the server, and login succeeds only if they
coincide. However, security analysts will highlight the weakness of this method to man-in-the-middle attacks, since
the MD5 hash doesn’t change with sessions. We won’t show another option that uses changing codes but is weak at
registration time. In future versions of FlashNuke, when not using SSL, we will consider encrypting the password with
a server key.
When using digital signature (which is the best login method), the code is set to the base64-encoded signed SID and
transmitted to the server. Signing the SID means using the private key to decrypt the SID itself. The result is encoded
in base64 format. The server decodes the base64 code and decrypts it using the stored public key. If the result coin-
cides with the SID the login succeeds.
Of course, the SID must be active and associated to the user’s IP Address. This grants the security of the authentica-
tion process.

4.3.3.2. Exceptions
must be renewed. The exception is handled by calling the GetewSID method and trying the login again (if the user
used the private key, signing must be performed again with the new SID).
4.3.3.2.2. LoginException
The LoginException is thrown when the login fails. Usually, login fails when username or password/signature are in-
correct. However, this exception can still be thrown in case of inconsistency: if the session corresponds to a logged in
user, he must first log out before logging in with other credentials. In this case, the exception code reveals the cause
of the error. Here are the codes:
 00000F00: Wrong username or password/signature

 00000FAC: User already logged in
This exception can’t actually be handled. An error message must be displayed and the user must try to log in again.
However, the presence of the AC code means there is a bug in the system. In this case, when the exception is thrown
the event must be logged in the Error Log.
This exception is thrown when the user that tried logging in is banned. This usually happens when a banned user
tries to log in from a different computer. The client shows the error message, and the server logs the login attempt
while the IP Address is added to the banlist.
Actually, this exception should be thrown only after verifying user credentials in order to avoid problems with mis-
typing the username.
4.3.4. LogOut(sid: String)

This method logs the user out. While the session remains active, the user is unlinked from the work session. The user
may still operate on the system, but with limited privileges. After logging out, the interface must be rebuilt according
to the privileges, and all components must be informed of the log out.
4.3.4.1. Parameters
4.3.4.2. Exceptions
must be renewed. The exception is handled by calling the GetewSID method. There is no need to log out again.

4.3.5. EditUserProfile(sid: String, newprofile: IDictionary, [uid: Integer])
This method allows a user to edit his own profile or an Administrator to edit another user’s profile. This method is
used in combination with the GetUserInfo method. The edit profile panel first loads all the user information, then
lets the user/admin edit the information. Finally the new profile is sent to the server through this method and the
information are saved.
This method works in Admin mode when the uid parameter is set. In this case, the modifications will be applied to
the target user. Else, the user is editing his own profile.
4.3.5.1. Parameters
4.3.5.1.2. newprofile: IDictionary

This parameter includes the new profile for the user in the form of dictionary. Each field matches the IUser fields, in-
cluding the otherinfo field with its special structure48. If the new email address is different from the old one, every-
thing can be saved except the new email address, which requires a confirmed opt in with a verification message.
4.3.5.1.3. uid: Integer

This is an optional parameter. If not set, it means that the user is trying to edit his own account. Else it means that
the program is in Admin mode and is trying to edit someone else’s profile. The value of uid should never be the one
of the current user (abnormal situation)
4.3.5.2. Exceptions
must be renewed. The exception is handled by calling the GetewSID method and logging in before running the
method again.
4.3.5.2.3. InvalidArgumentException
This exception is thrown when one or more parameters are invalid and can’t be saved. Parameter validity, such as
email address format username@provider.xxx should be always verified client-side. However, in order to prevent at-
tacks by hacked clients, the server must re-check the validity of all the values inserted by the user.
This exception is thrown when a non-admin user tries to edit someone else’s profile (uid parameter set), or when the
current user is anonymous.
4.3.6. DeleteAccount(sid: String, code: String, [target: Integer])

This method allows a user to delete his own account from the system. Such an option is required by certain privacy
laws. The user must confirm his will to delete the account by performing a new authentication with his pass-
48
The user profile editing panel will also deal with profile/preferences of components using runtime-loaded panels. Then the re-
sults are encapsulated into the payload object. The server will use component call-backs to store new information
word/signature. This method can be also used by an Administrator to delete someone else’s account. In this case,
the authentication is required for confirmation. The method deletes all the traces of the user from the system except
logs, and the action itself is logged in the System log.
4.3.6.1. Parameters
4.3.6.1.2. code: String

As for the login, the code is either the MD5 hash of the password or the decrypted SID of the current user. The sys-
tem automatically recognizes the authentication method and validates the credentials.
4.3.6.1.3. target: Integer

This parameter, if set, represents the UID of the user to delete. The presence of this parameter means that an Ad-
ministrator requested the deletion of a user’s account.
4.3.6.2. Exceptions
method again.
This exception is thrown when the current user or IP address is banned. The client shows the error message, and the
server logs the attempted operation.
This exception is thrown when the confirmation fails because of wrong password/signature.
This exception is thrown when a non-admin user tries to delete someone else’s account (uid parameter set), or when
the current user is anonymous.
4.3.7. ShowSavedSessions(sid: String): IDictionary

This method is used to load a previously saved session state. As we said earlier, a session state doesn’t have anything
to do with the SID, which basically identifies the client uniquely. When called by a Registered User, this parameter
returns a list of currently saved sessions for that user. The sessions are returned in a special dictionary where the key
is the session code and the value is a DateTime value that represents when the session was saved.
4.3.7.1. Parameters

4.3.7.2. Exceptions
method again.
This exception is thrown when the method is executed by an anonymous user.
4.3.8. LoadSession(sid: String, sessionCode: String): IDictionary

This method loads a session. The session has been previously selected and now is ready to be loaded. The system
sends the data of the saved session to the client which uses it to restore the previous state by propagating the in-
formation to the loaded components.
The return value is a dictionary where each key under the components key is a component and the value is the pay-
load to give that component. Other root keys for the object will be described in Client design, but we can enumerate
the theme and language keys, which obviously represent the current theme and language.
4.3.8.1. Parameters
4.3.8.1.2. sessionCode: String

This parameter represents the unique code of the session that the user chose in the menu.
4.3.8.2. Exceptions
method again.
4.3.8.2.4. NukeException
This generic exception, with code 00000FC3, reports that an error occurred during the process of loading the session
data. The exception should carry other information that can be useful to developers. This includes the case of a
wrong session code.

4.3.9. SaveSession(sid: String, payload: IDictionary)
The client calls this method when saving a session state into server’s storage. The client first gathers the local current
state from all components, then packs it in the payload object and sends all the data to the server. The server then
saves the session assigning it a session code.
4.3.9.1. Parameters
4.3.9.1.2. payload: IDictionary

The payload object is the same object that will be returned by the LoadSession method and that we described
above.
4.3.9.2. Exceptions
method again.
This generic exception, with code 00000FC4, reports that an error occurred during the process of saving the session
data. The exception should carry other information that can be useful to developers.
4.3.10. DeleteSession(sid: String, sessionCode: String)

This method deletes a session from the server. It is useful that the user deletes useless sessions frequently.
4.3.10.1. Parameters
4.3.10.1.1. sid: String
4.3.10.1.2. sessionCode: String

This parameter represents the unique code of the session that the user chose in the menu.
4.3.10.2. Exceptions
method again.

This generic exception, with code 00000FC5, reports that an error occurred during the process of deleting the ses-
sion data. The exception should carry other information that can be useful to developers. This includes the case of a
wrong session code.
4.3.11. ChangePassword(sid: String, oldCode: String, newPassword:

String)
This method is used to change the authentication method of a user to a new password. The user confirms the opera-
tion either by retyping his password or using his signature, and then the server saves the new password.
4.3.11.1.1. sid: String
4.3.11.1.2. oldCode: String

As usual, this code is either the MD5 hash of the password or the signed SID.
4.3.11.1.3. newPassword: String

This parameter is required to be the MD5 hash of the new password to store.
method again.

4.3.12. ChangeSignature(sid: String, oldCode: String, newPubKey:
Byte[])
4.3.12.1.1. sid: String
4.3.12.1.2. oldCode: String

As usual, this code is either the MD5 hash of the password or the signed SID.
4.3.12.1.3. newPubKey: Byte[]

This is the new public key in byte array format.
method again.
4.3.13. ChangeLostPassword(sid: String, username: String, newPass:

String)
This method is used by a user that can’t login because he lost his password/private key. This method sets a new
password for the user and requires an email confirmation before completing the process.
4.3.13.1.1. sid: String

This parameter represents the username to change the password of.
4.3.13.1.3. newPass: String

The MD5 hash of the new password.

method again.
4.3.13.2.2. UserNotFoundException
This exception is thrown when the username is not found in the database.
This exception is thrown when the current session is actively logged in.
4.3.14. ChangeLostSignature(sid: String, username: String, newKey:

Byte[])
This method is used by a user that can’t login because he lost his password/private key. This method sets a new sig-
nature for the user and requires an email confirmation before completing the process.
4.3.14.1.1. sid: String

This parameter represents the username to change the signature of.
4.3.14.1.3. newKey: Byte[]

Contains the new key in byte array format.
method again.
4.3.14.2.2. UserNotFoundException
This exception is thrown when the username is not found in the database.
This exception is thrown when the current session is actively logged in.

4.3.15. CreateGroup(sid: String, gname: String): Integer
This method allows a Registered User to create a new group. We have already explained the concept of user group
and some of its applications.
This method returns the Group-ID (GID) of the newly created group.
4.3.15.1.1. sid: String
4.3.15.1.2. gname: String

This parameter represents the group name. It must be alphanumerical.
method again.
4.3.15.2.2. GroupException
This exception is thrown in case of an error creating the group. The reason depends on the code:
 00000F2A: Group name exists
4.3.16. Overloads GetGroupMembers(sid: String, gname: String):

String[]
This method returns the list of the members of a group. The returned parameter is only the username for each
member of the group, in order to not overload the payload in case of large groups (info about the users may be get
using the GetUserInfo method). No order criteria is required for the user names (which can be easily be ordered al-
phabetically), except for the group leader which is always the first in the list
4.3.16.1.1. sid: String

This parameter represents the group name.

method again.
 00000F2B: Group does not exist
4.3.17. Overloads GetGroupMembers(sid: String, gid: Integer49):

String[]
This method returns the list of the members of a group. The returned parameter is only the username for each
member of the group, in order to not overload the payload in case of large groups (info about the users may be get
using the GetUserInfo method). No order criteria is required for the user names (which can be easily be ordered al-
phabetically), except for the group leader which is always the first in the list
4.3.17.1.1. sid: String
4.3.17.1.2. gid: Integer

This parameter represents the group ID.
method again.
49
We are already assuming that a group will be identified by an integer inside the database
4.3.18. DeleteGroup(sid: String, gname: String)
4.3.18.1.1. sid: String

This parameter represents the group name.
method again.

 00000F2C: Operation not permitted. Only the group leader can delete the group50
4.3.19. ProcessRequest(sid: String, payload: IDictionary): IDictionary

This is the core method of FlashNuke. Each request to the system, which doesn’t belong to the ones that can be
server with other Web Service methods is routed and encapsulated through this method, which is also the only way
to allow multi-component runtime. The details about the return parameter are quite simple to understand, but we
need first to re-explain how FlashNuke handles component requests.
As we have said when describing the system architecture, the system is based on the multi-level three-tier paradigm.
Each tier is multi-level. This method represents the lower level of communication. We have also required that multi-
ple requests from multiple components have to be handled within the same payload and in parallel. Both require-
ments are achieved with this routing method.
In order to better understand the power of this method, we will make an example.
The user is browsing the Forums and is writing a message to post. Before submitting, the user sees a fantastic-
looking image on the Lastest upload pictures block, and votes it with 5 stars. The development team of the block un-
derstood that voting a picture is not a real-time activity and programmed the block to queue rating requests. The
block calls FlashNuke Client’s methods to queue a server request (which won’t have a response message in this ex-
ample). Meanwhile, the Private Messages block wakes up and requests the server, still asynchronously, information
50
This exception is not thrown to User Administrators or higher
about new private messages. FlashNuke queues the new request and waits for the 10 seconds needed to send asyn-
chronous requests.
Finally, and before that 10 seconds deadline, the user submits the new forum topic. That’s of course an event that
must be processed real-time. FlashNuke then packs all the pending requests into a single one, like the following:
[Forum Module] {
[Action] => Post new topic
[Forum] => “Off Topic” (ID 45)
[Subject] => Hey Dude!
[Body] => What‟s up guys? LOOOOOOOOOOOOOOOOL
}
[Pictures Block] {
[Action] => Rate picture
[Picture] => Maschio Angioino (ID 001647526)
[Rating] => 5
}
[PrivateMessages Block] {
[Action] Refresh
}
The server receives the payload and then forks the thread execution in multiple threads, one for each component.
Each component is executed with the part of the payload that belongs to it. For example, the PrivateMessages
server logic, running in a separate thread, will return something like the following:
[TotalMessages] 5
[Unread] 2
This, and the return parameters of other components, are packed in a new payload and returned to the client, which
was waiting for the server response with HTTP connection open. The response may look like the following:
[Forum Module] {
[Result] => OK
}
[Pictures Block] {
}
[PrivateMessages Block] {
[TotalMessages] 5
[Unread] 2
}
We may still spend some words about the final results of this transaction. The Forum module may display a pop-up
message saying that the new topic is being displayed on the board. Supposing that before the transaction the user
received a private message (there were 4 messages and 1 unread), the PM block may now highlight the number of
messages and show a flashing icon requesting user’s attention. When the user decides to read the new message, a
new request will be made using this technique to read the full message body.
Now that we have described the working of this method with a text example, it’s time to describe the structure of
the return parameter.
The return parameter is a dictionary. Each key represents a component. Values are considered as Object, and are
passed directly to the component indicated in the key, which will be responsible of decoding the data. Of course, the
real parameters must be XML-Serializable or XML-Serialized. It has no importance if the returning parameters has
the same dictionaries as the payload input parameter. The return parameter may carry components’ internal excep-
tions by simply having the exception as value (it is possible because every class, including Exception, inherits Object).

4.3.19.1.1. sid: String
4.3.19.1.2. payload: IDictionary

The payload object is dual to the return parameter. It is a dictionary where keys are components, and values (as Ob-
ject) are the input parameters for components, that will be decoded by them.
It is interesting to notice that this technique supports protocol obfuscation and/or cryptography techniques, by sim-
ply adding an encoding layer between the business logic and the raw data.
method again.
This exception is thrown when a critical error makes processing impossible. Possible codes include most common
situations:
 00000F01: Component not found/not installed51

 00000F02: Unable to execute component code
 00000F03: Unable to fork multiple threads
 00000F04: File system error52
4.3.20. ProcessAdminRequest(sid: String, compName: String, pay-

load:Object): Object
This method is similar to the previous one. Actually, it’s the same method, but it’s intended to be a separate channel
for Admin components53. The basic idea behind the splitting into the regular and special channel is the ability to eas-
ily implement cryptography over sensitive data. Usually, Admin info have to be kept secret. FlashNuke is designed to
not run over SSL, and the usage of SSL during normal exercise is not recommended for performance reasons.
However, Web Services teach us that special encoding techniques may be applied to SOAP messages, including en-
cryption/decryption functions. However, neither this documentation nor the first release of FlashNuke will actually
protect the payload against sniffing.
The basic difference between these two methods is multi-component processing. The Admin components, which
may need higher levels of isolation, are not designed to run in multithread mode. Each request to Admin panel must
51
This exception is thrown even when the component is installed but requires higher privileges. Admin components are included
in this case
52
An appropriate value must be given to the InnerException property to help debuggers find the cause of the error
53
An Admin Component is a component made for the Administration panel, which is visible to Administrators only
be served by a single component at once. Obviously, due to the UI design of the Admin panel, the user is supposed
to interact with a single component at once. Instead, in normal user exercise, multiple components (Blocks and
Modules54) may dispatch requests at the same time.
This basically changes one aspect of I/O parameters: they refer to a single object and not to a collection.
The return parameter, in fact, is a payload in Object format that has to be delivered as it is to the component that
requested processing. On server side, the component that dispatched the request and has to serve it is identified by
its canonical name, which is not part of the payload anymore.
Developers should be aware that the payload itself could be a dictionary. We do actually enforce the usage of dic-
tionaries because they are the most similar data type to XML markup.
4.3.20.1.1. sid: String
4.3.20.1.2. compName: String

This parameter represents the Admin component’s name. It cannot refer to user components.
4.3.20.1.3. payload: Object

This object represents the payload for the server-side logic of the component. It’s in Object format, and, as we al-
ready said many times, the real class must be XML-Serializable or XML-Serialized55.
method again.
This exception is thrown the user is not logged in or is not an Administrator. This has nothing to do with user’s privi-
leges (see next exception, code 0xF05).
The meaning of this exception depends on the code:
 00000F01: Component not found/not installed
This exception is thrown even if the component is not an Admin component. The error message specifies the situa-
tion.

 00000F05: Insufficient privileges for Administrator
54
We are considering the opportunity to allow the execution of multiple Modules in tabbed view for next releases of FlashNuke
55
String and Byte[] are typical XML-Serialized classes
56
This exception is thrown when the Admin tries to use a component which he’s not Admin of. We will deal with
Admin responsibilities when designing the database.
4.3.21. GetInitData(): IDictionary

This method is used by the client to initialize itself when entering the website. This is the only method, with the ob-
vious exception of the GetNewSID method, that does not require the client to obtain a SID.
It has no input parameters and is not supposed to throw any exception. Its job is to read the configuration parame-
ters and website layout and send the data to the client in the form of a dictionary. Actually, not all configuration pa-
rameters should be available over a public protocol: some of them are internal to the server and it could be incon-
venient (not to say risky) to transmit them. We will deal with this when designing the server and optimizing the
processes.
The actual structure of the output parameter is the following:
[config]: a dictionary with configuration parameters, i.e.

[theme]: name of theme
[language]: name of default language
[layout]
[module]: name of module to load
[left]: list of blocks to load on the left
[right]: list of blocks to load on the right
None
This exception is thrown when the current IP address is banned. The client shows the error message, and the server
logs the attempted operation.
4.3.22. SearchUser(sid: String, name: String): String[]

This method implements a user search. It searches for users that are similar to the provided pattern. The return
value is an array containing the user names of the accounts that are most similar to the pattern. For example, the
user enters goofy as pattern. Some results may be the following (assuming they are all registered users):
goofy
djgoofy
goofy78
Since the returning parameter is an array of String, detailed information must be retrieved using the GetUserInfo
method.
4.3.22.1.1. sid: String

4.3.22.1.2. name: String
This is the search pattern for the user. The system has the responsibility of using an optimized search algorithm that
orders result from the most to the least similar.
method again.
4.3.23. Overloads GetUserInfo(sid: String, username: String, [OnEr-

rorThrowException: Boolean = true]): IUser
This method provides detailed information on a user which name is known. The user must exist. The return value is a
IUser object with sensitive properties57 set to null if not running as administrator.
It throws a NotFoundException exception if the specified user does not exist and the third parameter is set to true or
not specified. Else it returns a null value.
4.3.23.1.1. sid: String

This parameter represents the username the client is interested to.
4.3.23.1.3. Optional OnErrorThrowException: Boolean = True

This optional parameter determines the behaviour of the method in case the user is not found. If this parameter is
set to true, it throws a NotFoundException Exception if the user is not found, else it returns a null value.
This parameter is useful during sign up: since exception throwing is CPU intensive, because the runtime needs to
save the stack and the debug information, and we don’t need the exception to know if a username is already taken,
the client may set the parameter to false and check if a null value is returned before allowing the user to complete
the sign up process.
method again.
57
Like email address. Password and public key are always null
4.3.23.2.2. NotFoundException
This exception is thrown when no user with the specified username exists and the OnErrorThrowException parame-
ter is set to false.
4.3.24. Overloads GetUserInfo(sid: String, uid: Integer): IUser

This method is dual to the previous. The only difference is that the search is done using the user ID. If no user is
found matching the ID, an exception is always thrown.
4.3.24.1.1. sid: String
4.3.24.1.2. uid: Integer

This parameter represents the user ID in Integer format.
method again.
4.3.24.2.2. NotFoundException
This exception is thrown when no user with the specified ID exists.
4.3.25. ReportClientException(sid: String, ex: Exception)

This method is part of the Error Logging and Reporting feature. When the client or a component throws an exception
that cannot be handled, it must be reported to the server of current website. The Administrators will be able to see
the error and all the details attached to it, and maybe decide to send a report to the Development Team.
It must be noticed that, in order to let the error reporting work, exceptions must not propagate to Flash Player run-
time. This can be achieved by properly setting the onError event of Flex objects.
4.3.25.1.1. sid: String

4.3.25.1.2. ex: Exception
This parameter is the exception itself. It is important to understand that the Exception class (called Error class in Flex)
is basically not XML-Serializable, and the fact that exceptions may be propagated through SOAP doesn’t mean excep-
tions can be passed as SOAP parameters.
In order to make this method work, the error object must be of a class that, more than inheriting from Exception,
implements the IXmlSerializable interface.
method again.
4.3.26. UploadFile(sid: String, filename: String, payload: Byte[], policy:

AccessPolicy, [mime: String], [ownerModule: String]): GUID
This method allows the upload of a file. The client directly sends the payload through SOAP by properly encoding the
file in binary format. The return parameter is the GUID of the file that has been uploaded.
File upload through SOAP is proven to be feasible thanks to two Flex and Visual Studio tutorials.
The file size must not exceed server limits: file size should be checked client side.
4.3.26.1.1. sid: String
4.3.26.1.2. filename: String

This parameter represents the name of the file. There are limitations on the allowed characters for a filename: these
consider the worst case in file systems (Windows). It must simply match the following Regular Expression:
^[^/:*?"<>|\r\n]*$
The name of the file isn’t required to be unique.
4.3.26.1.3. payload: Byte[]

This is the actual content of the file, encoded in byte array format.
4.3.26.1.4. policy: AccessPolicy

This parameter defines the access policy for the file, as we have defined the AccessPolicy class.
4.3.26.1.5. Optional mime: String

If set, this parameter determines the MIME type of the file to upload. This is useful when the file type cannot be de-
termined by its extension. If set, this overrides the server Content-type header when downloading.

4.3.26.1.6. Optional ownerModule: String
This parameter is usually set by modules that use the file storage feature of FlashNuke to mark files as theirs. This
parameter is actually supposed to be always set when uploading.
method again.
The exact meaning of this exception depends on the code:
 00000F01: Component not found/not installed

 00000F04: File system error
4.4. WSDL
Not available (yet)
4.5. Example of client/server interaction

The following is a clarifying example of client/server activity during a common FlashNuke session. We suppose the
user enters the website, then browses the Picture Gallery and finally tries to upload a picture after leaving the client
inactive too much time (timeout event).
The following is the UML Sequence Diagram for the example:

Engine.asmx PicGallery SQLConnection File System
Client
GetInitData
IDictionary Obj
GetNewSID
SID: String Insert new SID
ProcessRequest
Load PicGallery GetGalleries
SELECT galleries
GalleryList GalleryList Recordset Object
ProcessRequest
Show gallery #14 GetPics
SELECT pictures
Recordset Object
ReadFiles
Pictures Pictures Pictures
Login
CheckCredentials
Credentials OK: User
IUser
Timeout
ProcessRequest
Upload Pic
SessionExpired
GetNewSID
SID: String Insert new SID
Login
CheckCredentials
Credentials OK: User
IUser
ProcessRequest
Upload Pic UploadPic
INSERT INTO pictures
WriteFile
Status: OK Status: OK

In this example, we will consider one actor and four objects as part of the scenario. The actor is the client, which is
directly controlled by the user, and the three objects are the following: the Engine.asmx Web Service, the PicGallery
module, an instance of the SQLConnection class which represents the DB connection, and the FileSystem Object.
It is important to understand that this is a high-level description of the software dynamics. We chose to not fall in
implementation details and generalized the DB and file system operations with these two objects. In .NET Frame-
work, running an SQL command is a complex procedure that involves more classes, and it gets even more compli-
cated when running in transactional environment.
The user first enters the website: this requires the client to be initialized –as we mentioned, this includes the default
language and theme settings- and so the client runs the GetInitData() method to obtain information.
Using those information, the client initializes itself and the default components to display. We won’t go into the de-
tails, since the client development has been made independent from the rest of the system.
The client then starts a new session by running the GetNewSID() method. This makes the server generate a new
unique58 SID and transmit it to the client while registering it into the database (we have supposed asynchronously).
The client is finally ready to accept user interactions. In this example, the user tries to load the PicGallery module.
This makes the client run the ProcessRequest() method with appropriate arguments to require the initialization of
the module. In this example, the module first shows a list of available picture galleries. Remind that the user is not
yet logged in, so we must suppose that this and the following operations are permitted to Anonymous Users.
The component queries59 the database for existing galleries and returns the list to the client.
The client then requires to browse the gallery ID 14. This, as expected, causes the execution of ProcessRequest()
method, which carries a “Browse gallery 14” command for the PicGallery component. This causes the component to
query the database for pictures inside that gallery, then read the files from the file system60.
The user, while looking at the fantastic image shown, decides to log in. This causes the client to execute the Login()
method (in this example, with success): the server returns an IUser object containing user data.
At this time, the user is amazed by the high-resolution images and stays hypnotized for a dozen of minutes looking at
the screen. This causes a session timeout. When the user finally realizes what happened to his mind, he finally tries
to upload a picture from his computer showing other people his ability as photographer. Unfortunately, when trying
to process the request, the server refuses the SID provided by the client and returns an exception.
Now the client has to re-establish the virtual connection with the server that was represented by the SID. First, it in-
vokes the GetNewSID() method again, then requires the user to log in again and invokes the Login() method once
more, and finally retries the execution of the ProcessRequest() method. Please notice that in this case we supposed
the picture gallery does not use the Upload method of the web service but uses it own one to manage uploads (i.e.
allowing to determine special information such as resolution, camera manufacturer, etc, or to generate a thumb-
nail).
58
Actually, in order to be sure that the SID is unique, a loop cycle must be implemented to search inside the database for exist-
ing SIDs. However, we didn’t highlight this in the example
59
Even if we required the execution of PL/SQL procedures for security reasons, it’s obvious that such procedures will result in a
combination of common SQL commands: SELECT, INSERT, UPDATE, DELETE
60
Remember that this is an example! There are a thousand of technical reasons that suggest the server to give the client only
the URL of pictures in a production environment, leaving the client itself the responsibility to load the pictures via HTTP
The ProcessRequest() method gives the data to the component, which registers the new image into the database
and writes the file into the file system, returning an OK message to the client.
End of the example.
5. FlashNuke Core Client

Not available (yet)
6. FlashNuke Core Server

Not available (yet)
7. SQL Data Base Project

The purpose of this document is to define the internal layout and interface of the SQL database for FlashNuke. By in-
ternal layout, we mean the tables that constitute the database, and by interface we mean the PL/SQL functions that
will be used by the client61 to read and manipulate stored data.
This document is made by three parts: in the first one, we will deal with the entities that compose the domain model
and the relationships between them in order to build an Entity-Relationship Diagram (E-R Diagram), which is the
theory at the base of any relational database; after building the E-R diagram, we will apply engineering techniques to
translate the E-R model into an optimal62 relational model; in the last part, which will be built together with the
server (since the requirements are not yet clear), we will define and then code the PL/SQL functions that will ma-
nipulate data.
We already defined as a requirement that FlashNuke must not access the data source directly except in Admin
mode. This requirement works as a firewall against SQL-Injection exploits. By strictly limiting the entry points of the
data source, we accomplish an important objective: we give breath to developers, who will be able to reduce the
impact of security tests in project budget.
However, the most important part of this document is the logic analysis and design. We will try to translate the E-R
model into a relational model, and we will deal with the problem of performance optimization by using caching
mechanisms. Web applications, in fact, need to be designed for maximum performance because largest websites
have thousands of visitors in a minute. In many cases, websites need to be distributed over more redundant servers.
Distributing the three tiers of FlashNuke is the first way to obtain additional performance, but the real work is done
on the server and on the database. Another important problem of large website is disk space: servers do not have
unlimited resources, and, most important, hosting services offer limited amounts of space. Using the minimum
quantity of disk space is another important objective to achieve.
Software engineering teaches us that the best way to achieve disk space objectives is using compression; and that
the best way to achieve performance objectives is using redundancy of data. Computer science teaches us that com-
pression reduces performance and redundancy reduces free disk space. It’s a problem of compromise.
61
In this case, as for all the three-tier systems, the client is what we called server. Literature explains this naming: we won’t
62
In software engineering, optimal refers to the best compromise between performance and size
7.2. The importance of preventing SQL-Injections
Before continuing, let’s focus on the importance of preventing one of the most common attacks in three-tier sys-
tems, and particularly in web environment: SQL-Injections. SQL is the standard language for relational databases,
and has not been replaced by any other language yet. We will see how easy can be breaking the security of an SQL-
based website’s database. It is important to understand that SQL-Injection is not the only hacking technique that can
be applied against a website. A complete security analysis must be performed by expert analysts both on the docu-
mentation and on the code; however, the Injection vulnerability affects the majority of web application that are not
written with appropriate coding tricks.
SQL-Injections use the basic vulnerability of SQL language: being source. A source code may always be altered by ap-
propriate misuse of parameters, creating a brand new SQL statement that is executed with unpredictable results.
This affects test cases domain, and can be explained by an example.
Consider the following SQL statement and pseudo-code:
SQL = “SELECT * FROM Admins WHERE username = „*username*‟ AND password = „*pass*‟;”;
replace(“*username*”, username, SQL);

replace(“*password*”, password, SQL);
if (sql.rows == 0) alert_login_error;
else perform_admin_operation;
The execution of the code depends on the number of resulting rows after the execution of the statement. In the
statement, the fields surrounded by stars (*) are replaced by local variables. A tester usually builds three domains for
testing:
 Username does not exist in the database (fails)

 Username exists, but password does not match (fails)
 Username exists, and the password for that username matches (succeeds)
This because the SQL interpreter is suppose to do the following: search for the matching username; if found, check
that the password matches for that username.63
As we said, the operations done by the SQL DBMS fully depend on the final SQL statement it will receive by the cli-
ent. Following the above example, if the username is goofy and the password is donald, the client will build the fol-
lowing statement:
SELECT * FROM Admins WHERE username = „goofy‟ AND password = „donald‟;
We don’t care which domain this test is part of. We can observe that the static sequence of the compiled SQL code
follows what the DBMS is expected to do during a login.
However, what happens if the password is set to the following value…?
„ OR 1 OR username = „
In order to understand what happens now, we need to build the final statement.
SELECT * FROM Admins WHERE username = „goofy‟ AND password = „„ OR 1 OR username = „‟;
This statement is a valid SQL statement (notice that we used quotes in the right place). The difference is in what the
interpreter does while evaluating the condition statement for each row: it checks for username matching goofy, then
63
Real working of a DBMS differs, but we don’t care in this example
password matching donald for those who passed first check; it checks for the true condition for each row, which is
always verified, and then it checks for the empty username, which we assume is not verified. The result is the com-
bination of the three condition in OR, which is the full table! Since the code just checks if there is no result or more
results are returned, the login succeeds.
It is important to understand that the unwanted result is due to the complete change of the SQL statement’s static
sequence: instead of evaluating the AND of two conditions, the DBMS will evaluate true!
Compiled code and byte-code are not vulnerable to such attacks, because operations are not given by input but pre-
viously declared within the data source.

7.3. Identifying Entities and Relationships
Component
+Name : String
+Version : String
+Visibility : AccessLevel
+Logo : Image
+Load()
+Unload()
+Install()
+Uninstall()
1..* #CheckDigitalSignature() : DigitalSignature
#Administer()
Block +Founder Module

File
+Name
0..1
+Type
0..1 *
+Size : Long
+Downloaded : Integer
* +TimeOfUpload : Timestamp
+SetProperties()
* * +Download()
UserGroup 0..1 +Founder #Uploader 0..1

+Name
*
+AddUser(in User : User) User
*
+RemoveUser(in User : User) +Username : String
#Password : String
* #Signature : DigitalSignature
#Email : String
+Avatar : Image
+LastLogin : Timestamp
#LastHost : Host
+About : String
+Biography : String
+Member +DateOfBirth : Date
+Authenticate(in username : String, in password : String)
+Authenticate(in username : String, in SignedCode : String)
* +LogOut()
#UpdateProfile()
+ViewProfile()
#ConfirmEmail()
#ChangeEmailAddress(in newMail : String) Session
#ChangePassword(in newPassword : String) +Started : Timestamp
#ChangeSignature(in newSignature : DigitalSignature) +InactivityTime : Integer
1 *
-RevokeKey() +ViewState
+AddToGroup(in group : UserGroup) * +Save()
+RemoveFromGroup(in group : UserGroup) +Load()
+EditAvatar(in NewImage : Image) 1 +Login()
1..* +RecoverLostPassword(in username : String) +Logout()
«struct»Host
+Hostname 1
+IPAddress
PartialAdministrator
*
#AdministerComponent(in Component : Component)
SystemEvent
-Time : Timestamp
SupremeAdministrator
#ChangeConfiguration()
#ViewLog() : SystemLog
#ManageComponents()
SystemError
-Component : Component
-TechnicalInfo
+Report()
The above picture is a simplified version of the class diagram, from which we will build the E-R Diagram. Basically,
singleton classes have been removed: we will implement them during logic DB design.

7.4. Building the E-R Diagram
File
Uploaded Session
Owns
Download
Allowed
Running
User
Partial Admin
Creates
Administers Administrator
Belongs
Component
Module
Group
Creates

7.5. Logic Database Design
Let’s begin with the User class and its subclasses. We decided to merge the three hierarchical entities into one table.
The User may specialize into a Partial Administrator if a relationship with at least one Admin component is set, or
into a Super Administrator if a Boolean flag is set. For performance reasons, the information about the partial admin
is made redundant with another flag inside the user table.
Since users have to be activated when they sign up, and we didn’t show the difference between an active and an in-
active user in the diagram, we are going to implement part of the email confirmation system in the user table. Each
user is associated a Boolean flag that allows logging in if true, and an activation key, which is a 40-characters string,
which must be provided to the system in order to confirm the validity of the email address.
Now let’s go to the sessions. As we mentioned, the session may be temporary or persistent. We are using sessions to
basically provide user tracking64 and identification, but we also want Registered Users to save a work session: for ex-
ample, a user may start writing a message in the Forums, but needs to leave and wants to resume later. The exact
view state, complete with the message draft, is saved into system’s permanent memory and loaded later. However,
we now notice that saving and loading sessions is quite different from using a SID to track and identify a client. So we
are going to separate the two kinds of sessions. More, since the payload of the saved sessions, which is basically raw
data that components use to save and restore their view state, is something that isn’t interesting for database pur-
poses. So we are going to write the payload into files stored in server’s file system and keep only basic information in
the database.
Because of this, we are going to create two separate tables: one for active sessions, and one for saved sessions. The
saved sessions table contains just the session ID, a reference to the user that saved it, and a timestamp indicating
when the session was saved. The server will have to properly save payload into files.
As an example of the analysis technique, we will show only three tables in this release of the document. All others
will come later
7.5.1. fnuke_users table

7.5.1.1. Columns
 uid: UNSIGNED
 username: VARCHAR(20)
 pubkey: BLOB
 password: CHAR(40)
 email: VARCHAR(255)
 avatar: VARCHAR(255)
 lastlogin: TIMESTAMP
 lasthost: VARCHAR(255)
 lastip: UNSIGNED
 about: TEXT
 bio: TEXT
 birthdate: DATE
 active: BOOLEAN
 actkey: CHAR(40)
 admin: BOOLEAN
64
Tracking activities should always be noticed in a privacy statement
 partialadmin: BOOLEAN
7.5.1.2. Primary Key

 uid
7.5.1.3. Foreign Keys

None
7.5.1.4. Triggers
None
7.5.1.5. Constraints
 pubkey and password must not be NULL together
 pubkey and password must not be NOT NULL together
 If admin is TRUE, then partialadmin must be TRUE
 username is UNIQUE and NOT NULL
 email is UNIQUE and NOT NULL
 lastip and lasthost must refer to the same remote host
7.5.2. fnuke_sessions table

7.5.2.1. Columns
 sid: CHAR(40)
 uid: REF(fnuke_users)
 started: TIMESTAMP
 last_action: TIMESTAMP
 ip: INTEGER
 hostname: VARCHAR(255)

 sid

 uid => fnuke_users.id; On delete and update, cascade
7.5.2.4. Triggers
 Delete rows where last_action is early than X minutes ago, where X is a parameter set by the webmaster
 ip and hostname must refer to the same remote host
7.5.3. fnuke_saved_sessions table

7.5.3.1. Columns
 sid: CHAR(40)
 uid: REF(fnuke_users)
 saved: TIMESTAMP

 sid
 uid
 uid => fnuke_users.id; On delete and update, cascade
7.5.3.4. Triggers
None
None
8. Accessible Version
Exception ex = new NotYetImplementedException() extending NotImplementedException;
ex.message = “This feature has not been implemented YET. Work in progress”;
throw ex;
9. Error Reporting service Protocol

throw ex;
10. An example module: News
11. FlashNuke Software Development Kit (SDK)

throw ex;
12. Attachments, code snippets and prototypes
12.1. GUI model

This prototype contains a template for FlashNuke GUI. Compiling it in Adobe Flex will result in an SWF file that
shows, statically, how should the interface look like. At this time, absolute sizes of elements is only for demo pur-
poses and a final layout has not been decided yet.
Files:
 Default.mxml: contains the source code for the layout demo. Import it in a new or existing Flex project, or
compile it with the stand-alone compiler
12.2. Use Case and Class Diagrams

Files:
 UML Use Case.vsd

 UML Class Diagram.vsd
12.3. Client-side dynamic load and interaction: Parent and Child

This prototype demonstrates the client-side feasibility of RN002. It is made by a Flex project with two applications:
one called Parent, and another called Child. They are written in MXML language, but we suppose they can be rewrit-
ten in ActionScript 3.0 too. The objective of this prototype is dual: first of all, it demonstrates that external SWF files
can be loaded at run-time without recompiling, then it demonstrates that the loaded component may become part
of the whole application by interacting with it as it wasn’t an external component.
The working of the prototype is simple: the user has to load Parent.html from the bin directory using a browser that
supports Adobe Flash Player, or Parent.swf from the stand-alone version of Adobe Flash Player. After the parent has
completed loading, the user has to hit the First load the child button. The parent control will load the child as an ex-
ternal control and display it below the horizontal line. When the child is loaded, the application is ready to work.
There is a text box and two buttons for each control. The user may write on any text box and perform the following
four actions:
 Tell child or Ask parent: the child will display the text written in the parent’s textbox in its one
 Ask child or Tell parent: the parent will display the text written in the child’s textbox in its one
For example, let’s write “Hello World” in the parent’s textbox, and then hit Ask Parent. “Hello World” will be dis-
played in child’s textbox.
The name of the control to load is defined within a function. This makes us think that the name can be really be set
at runtime and be totally unknown when compiling.
This prototype has been developed using Adobe Flex 2.0 under Windows Vista x64, and tested using Internet Ex-
plorer 7.0 and Mozilla Firefox 2.0.0.3 with Adobe Flash Player 9.
12.3.1. Technical documentation

Both parent and child are developed within the same Flex project, making the Parent and Child classes be visible
each other. However, we don’t think this affected the result of the experiment due to the nature of SWFLoader, that,
even during trace, used Flash Player runtime to load the external movie.
We used the mx.core.SWFLoader class to load the child control: SWFLoader documentation is poor, so we had to re-
verse-engineer its dynamics analyzing the source code from SWFLoader.as, included in Flex SDK. Loading a movie is
completely asynchronous. SWFLoader uses FlexLoader, a class inheriting from Loader, to load a movie. The Loader
class is the key to understand the working of the SWFLoader, but it’s internal to Flash runtime and there’s no code
for it. By reverse-engineering SWFLoader, we reached to generate a working procedure to obtain the pointer to the
object that is loaded (the SWFLoader itself is not useful).
 First we invoke the SWFLoader.load(string) method to start loading the movie

 We wait for SWFLoader to raise a complete event. The movie is loaded, but not initialized
 We get the pointer to the manager of the loaded movie, SWFLoader.content property, which is an instance
of mx.managers.SystemManager
 We wait for the manager to raise an applicationComplete event, telling that the loaded movie is completely
initialized
 Finally, the SWFLoader.content.application property will contain the pointer to the movie. Its type will be the
one of the class, but movies inherit from mx.controls.UIControl
It is important to understand that the above procedure must be respected. Running the load method and then trying
to extract the application property won’t work. Even waiting for the complete event and then trying to get the
pointer won’t work. Both events must be raised by the SWFLoader. Also, the content property must be converted to
SystemManager, or nothing will work.
The two classes implement the Observer pattern. The parent loads the child and stores its pointer in an internal
property. After loading, the parent invokes a RegisterParent method on the child passing the pointer to itself: this

will make the child store the pointer to its parent. Pointers will be used to dispatch events each other. There are two
basic kinds of event: REQUEST_FROM and GIVE_TO. The GIVE_TO event is used to send the string to the other con-
trol. The REQUEST_FROM event is used to ask the other control the content of the textbox: this makes the target
control dispatch a GIVE_TO event to the sender. In this case, there is no need to handle requests from multiple con-
trols. Each control knows who to deal with.
12.3.2. Conclusions
This prototype proves the feasibility of RN002. However, the user will notice that displaying of the child control is not
optimal (it goes off screen). We’ll have to work solve this problem, that may have been caused by the SWFLoader.
More, in this example we have been unable to implement the IChild interface due to MXML limitations. Using inter-
faces is crucial when developing FlashNuke.
We should try to make a new prototype, written in ActionScript 3.0, maybe adding some other interesting technical
features. For example, we could avoid to display the SWFLoader on the GUI (it’s transparent, but the control in-
stanced on the UI is not the target movie itself), or even trying to manage multiple components.
13. About Digital Signature

We decided to write this chapter to teach the basics of digital signatures to inexperienced users and developers. We
won’t deal with all the mathematical theories behind digital signing of data and documents, but just with the practi-
cal aspects of this technology, applied to authentication systems.
The classic method used to prove one’s identity to a software system is the password. The password is usually a
string that may contain only numbers, numbers and letters or all the characters that can be displayed on-screen.
Some password are case sensitive (AqUA is different from aQUA) and other are case insensitive (no matter how you
write it, just type the letters A, Q, U and A). Passwords can be user-chosen or system-generated. In almost 90% of
cases, a user-chosen password is something so easy to remember that anyone that knows the person enough may
try to guess the password (for example, the name of the mother), or else it’s enough easy to guess it by carefully
watching at the keys pressed by the user during typing. A system-generated password is so hard to remember that
almost every user writes it down onto a post-it that is left attached to a prominent place like the computer’s screen
so what was thought to be kept secret becomes public and everyone can get access to the system.
Another problem with password is eavesdropping over the Internet. A password is a string that is generally transmit-
ted clearly over the network. Anyone having appropriate tools (such as the Wireshark (31) network analyzer) can
sniff over the connection and grab anyone’s password with some luck. A good way to implement a secure authenti-
cation protocol is using cryptography, but it’s not an everyday possibility in web environment, since it requires a high
server load even to process non-critical data.
During the last years, research has put all its efforts in finding an authentication method that cannot be sniffed or in-
tercepted. Researchers quickly understood that the only way was to find a way to make the string that is transmitted
over the network valid only for a single login session without changing the password at every login. All the protocols
based on this technique can be called Challenge Handshake (avoid confusion with the CHAP protocol, that is based
on the same principles). The server challenges the client to prove the user identity using a handshake protocol that
works like the following:
1. The server sends a security code that is valid only for one session
2. The client uses the password and the security code to obtain a verification code and then sends it to the
server

3. The server verifies if the verification code is compatible with both the password and the security code sent
before
The password is never transmitted, and neither encrypted (because cryptography needs the negotiation of a key,
which is not always possible in public environments).
In order to merge the complexity of a very long password and the security of a challenge handshake protocol, digital
signature can be used to authenticate users65.
A digital signature is based on three components
 A private key, that is owned only by the legitimate owner of the signature, and is used to sign documents
 A public key, that everyone can use to verify that a certain document has been signed by the person that
claims to have signed it
 A certificate, that may be used to prove the real identity of a person or determine his trust level
FlashNuke doesn’t care about certificates. However, it must be noticed that if a user owns a certified digital signa-
ture associated to his email address, there may be no need to perform the address verification. However, this re-
quires more complexity in FlashNuke design, so we won’t consider this opportunity, even because too few people
have a certified digital signature: this makes the effort not proportioned to the effective gain.
It has no importance if somebody sniffs a public key over a connection. The public key, in fact, is meant to be publicly
distributed. It has no sense to place sniffing sensors on a megaphone.
A web authentication system, such as FlashNuke, can store the public key and ask the user that wants to authenti-
cate to use his private key to prove his identity.
When the user registers, he can generate a new private key or use an existing one as signature. He then generates
the public key and transmits it to the server, which will store it in its database.
When the user wants to log in, the server generates a random and long number (digital signature is a numerical algo-
rithm) and transmits it to the client. The client then uses the private key to generate another number, for example
using the RSA decryption formula, which is the signature of the security code received before. The server then ap-
plies the inverse function, for example the RSA encryption formula, to the signature using the public key and verifies
that the result matches the security code.
The codes that are transmitted over the network are valid only within a single login session. The complexity of the
codes and the length of the signature do only enforce the system, but don’t make it invulnerable to long-term at-
tacks.
Recent web browsers do have support for generating a digital signature and signing data. However, it must be no-
ticed that a signature must always be protected by a password or a PIN. That password, obviously, doesn’t exit from
the device where it’s used in.
More information can be found on Wikipedia (32) or googling for digital signature.
65
In many countries, digital signature is legally recognized as a proof of identity for the user that signs a document. There’s no
reason to doubt of its efficiency in network authentication environments
14. Exception reference
14.1. Client
14.2. Accessible
14.3. Server
 00000F00: Wrong username or password/signature

 00000F01: Component not found/not installed66
 00000F03: Unable to fork multiple threads
 00000F05: Insufficient privileges for Administrator
 00000F24: One or more invalid arguments (check error message for details)
 00000F25: User already registered
 00000F26: Email already registered
 00000F2A: Group name exists
 00000F2C: Operation not permitted. Only the group leader can delete the group
 00000FAC: User already logged in
 00000FC3: Cannot load session
 00000FC3: Cannot save session
 00000FC3: Cannot delete session
15. ToDos
15.1. Make prototype for RI002, maybe fetching the PopUpManager example
15.2. Research for a standard skinning format
66
This exception is thrown even when the component is installed but requires higher privileges. Admin components are included
in this case
67

FlashNuke Doc v070724

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

FlashNuke Doc v070724

Caricato da

Copyright:

Formati disponibili

FlashNuke

The Flash CMS

STATUS OF THIS DOCUMENT ...................................................................................................................................................... 9

VERSION CHANGE LOG ............................................................................................................................................................... 9

RELEASE NOTES .......................................................................................................................................................................... 9

1. INTRODUCTION AND HISTORY OF THE PROJECT .............................................................................................................. 10

1.1. PURPOSE OF THIS DOCUMENT ..................................................................................................................................... 10

1.2. REFERENCES ................................................................................................................................................................. 11

2. REQUIREMENTS ANALYSIS DOCUMENT (RAD) ................................................................................................................. 12

2.1. USER REQUIREMENTS .................................................................................................................................................. 12

2.2. SYSTEM REQUIREMENTS.............................................................................................................................................. 14

2.3. QFD ANALYSIS.............................................................................................................................................................. 15

2.3.1. NORMAL REQUIREMENTS........................................................................................................................................ 15

2.3.1.1. RN001: GRAPHICAL USER INTERFACE STRUCTURE ................................................................................................................. 15

2.3.2. EXPECTED REQUIREMENTS ...................................................................................................................................... 19

2.3.2.1. RE001: COMPONENT SDK................................................................................................................................................ 19

2.3.3. INTERESTING REQUIREMENTS ................................................................................................................................. 21

2.3.3.1. RI001: PORTABILITY OF DATA SOURCE ................................................................................................................................. 21

2.4. USE CASES ANALYSIS.................................................................................................................................................... 22

Distributed under Creative Commons 2.5 BY-SA IT Page 2

2.6.1.1. GENERIC USER................................................................................................................................................................. 24

2.4.2. USE CASES................................................................................................................................................................ 24

2.4.2.0. TEMPLATE (COPY & PASTE) ..................................................................................................................................................... 24

2.5. CLASS DIAGRAM .......................................................................................................................................................... 37

2.5.1. VIRTUAL CLASS COMPONENT ............................................................................................................................................. 39

Distributed under Creative Commons 2.5 BY-SA IT Page 3

Distributed under Creative Commons 2.5 BY-SA IT Page 4

3. SYSTEM DESIGN DOCUMENT (SSD) .................................................................................................................................. 59

3.1. PURPOSE OF THIS DOCUMENT ..................................................................................................................................... 59

3.2. DECOMPOSITION AND DISTRIBUTION ......................................................................................................................... 59

3.3. PLATFORM CHOICE ...................................................................................................................................................... 59

3.4. ANALYSIS OF REQUIREMENTS AND FEASIBILITY ........................................................................................................... 60

3.4.1. RN001: INTERFACE MODEL .............................................................................................................................................. 61

3.5. RESPONSIBILITIES ........................................................................................................................................................ 73

3.6. IDENTIFYING CONVENTIONS ........................................................................................................................................ 73

3.6.1. COMPONENTS: STORAGE, IDENTIFICATION AND ADMINISTRATION ............................................................................................. 74

4. CLIENT/SERVER INTERFACE .............................................................................................................................................. 79

4.1. PURPOSE OF THIS DOCUMENT ..................................................................................................................................... 79

Distributed under Creative Commons 2.5 BY-SA IT Page 5

4.2.1. IDICTIONARY ................................................................................................................................................................... 79

4.3. LIST OF PROCEDURES ................................................................................................................................................... 80

4.3.1. GETNEWSID():STRING ..................................................................................................................................................... 80

Distributed under Creative Commons 2.5 BY-SA IT Page 6

4.4. WSDL ......................................................................................................................................................................... 101

4.5. EXAMPLE OF CLIENT/SERVER INTERACTION .............................................................................................................. 101

5. FLASHNUKE CORE CLIENT ............................................................................................................................................... 104

6. FLASHNUKE CORE SERVER .............................................................................................................................................. 104

7. SQL DATA BASE PROJECT ............................................................................................................................................... 104

7.1. PURPOSE OF THIS DOCUMENT ................................................................................................................................... 104

7.2. THE IMPORTANCE OF PREVENTING SQL-INJECTIONS ................................................................................................. 105

7.3. IDENTIFYING ENTITIES AND RELATIONSHIPS .............................................................................................................. 107

7.4. BUILDING THE E-R DIAGRAM ..................................................................................................................................... 108

7.5. LOGIC DATABASE DESIGN .......................................................................................................................................... 109

7.5.1. FNUKE_USERS TABLE ....................................................................................................................................................... 109

Distributed under Creative Commons 2.5 BY-SA IT Page 7

9. ERROR REPORTING SERVICE PROTOCOL......................................................................................................................... 111

10. AN EXAMPLE MODULE: NEWS ................................................................................................................................... 111

11. FLASHNUKE SOFTWARE DEVELOPMENT KIT (SDK) ..................................................................................................... 111

12. ATTACHMENTS, CODE SNIPPETS AND PROTOTYPES .................................................................................................. 111

12.1. GUI MODEL ...................................................................................................................................................................... 111

13. ABOUT DIGITAL SIGNATURE ...................................................................................................................................... 113

14. EXCEPTION REFERENCE .............................................................................................................................................. 115

14.1. CLIENT ............................................................................................................................................................................. 115

15. TODOS ....................................................................................................................................................................... 115