FlashNuke Doc v070724

8/6/2019 FlashNuke Doc v070724

1/115

FlashNukeThe Flash CMS

Project Documentation

Questa opera stata rilasciata sotto la licenza Creative Commons Attribuzione-Condividi allo stesso modo 2.5Italia. 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.
http://creativecommons.org/licenses/publicdomain/http://creativecommons.org/licenses/publicdomain/http://creativecommons.org/licenses/publicdomain/http://creativecommons.org/licenses/publicdomain/


2/115

FlashNuke: The Flash CMS

Distributed under Creative Commons 2.5 BY-SA IT Page 2

IndexINDEX ......................................................................................................................................................................................... 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: GRAPHICALUSERINTERFACE 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: ADMINISTRATIONPANEL....................................................................................................................................... 17 2.3.1.7. RN007: URL REWRITING................................................................................................................................................. 17 2.3.1.8. RN008: COMPONENTS INSTALLATION................................................................................................................................. 18 2.3.1.9. RN009: SYNCHRONOUS ANDASYNCHRONOUS 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: DOWNLOADMANAGER.................................................................................................................................... 18

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

2.3.2.1. RE001: COMPONENT SDK ....................................................... ................................................................. ........................ 19 2.3.2.2. RE002: ALTERNATEACCESSIBLE 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: BASICCOMPONENTS............................................................................................................................................. 20 2.3.2.6. RE006: SYSTEM ANDERRORLOG ....................................................................................................................................... 20 2.3.2.7. RE007: USERBAN .......................................................................................................................................................... 20 2.3.2.8. RE008: ERRORREPORTING............................................................................................................................................... 20 2.3.2.9. RE009: SYSTEMRESTOREBACKDOOR................................................................................................................................. 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 OFSENSITIVEDATA.............................................................................................................................. 21 2.3.3.5. RI005: LOGIN FLOODPROTECTION..................................................................................................................................... 21 2.3.3.6. RI006: USERGROUPS...................................................................................................................................................... 21

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


3/115



2.4.1. ACTORS.................................................................................................................................................................... 24

2.6.1.1. GENERICUSER................................................................................................................................................................. 24 2.6.1.2. REGISTEREDUSER............................................................................................................................................................ 24 2.6.1.3. USERADMINISTRATOR...................................................................................................................................................... 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: ENTERWEBSITE.................................................................................................................................................. 24 2.4.2.2. UC002: SWITCH BETWEENFLASH ANDACCESSIBLE VERSION.................................................................................................... 25 2.4.2.3. UC003: CHANGETHEME.................................................................................................................................................. 26 2.4.2.4. UC004: CHANGELANGUAGE............................................................................................................................................. 26 2.4.2.5. UC005: LOADMODULE................................................................................................................................................... 26 2.4.2.6. UC006: REGISTER........................................................................................................................................................... 27 2.4.2.7. UC007: CHECKUSERNAMEAVAILABILITY............................................................................................................................ 27 2.4.2.8. UC008: CONFIRMEMAILADDRESS..................................................................................................................................... 28 2.4.2.9. UC009: RECOVERLOST PASSWORD.................................................................................................................................... 28

2.4.2.10. UC010: LOG IN .......................................................................................................................................................... 29 2.4.2.11. UC011: PASSWORDLOGIN (EXTENDSUC010)................................................................................................................. 29 2.4.2.12. UC012: DIGITALSIGNATURELOGIN (EXTENDSUC010) ..................................................................................................... 29 2.4.2.13. UC013: RESTORESESSIONSTATE................................................................................................................................... 30 2.4.2.14. UC014: CHANGEPASSWORD........................................................................................................................................ 30 2.4.2.15. UC015: CHANGESIGNATURE........................................................................................................................................ 30 2.4.2.16. UC016: REVOKESIGNATURE......................................................................................................................................... 31 2.4.2.17. UC017: LOG OUT....................................................................................................................................................... 31 2.4.2.18. UC018: SAVE SESSIONSTATE........................................................................................................................................ 31 2.4.2.19. UC019: EDITOWN PREFERENCES ANDPROFILE................................................................................................................ 32 2.4.2.20. UC020: EDIT ANOTHERUSERS PROFILE.......................................................................................................................... 32 2.4.2.21. UC021: BAN USER...................................................................................................................................................... 32 2.4.2.22. UC022: UNBANUSER ................................................................................................................................................. 33 2.4.2.23. UC023: CHANGECONFIGURATION................................................................................................................................. 33 2.4.2.24. UC024: MANAGECOMPONENTS................................................................................................................................... 33 2.4.2.25. UC025: VIEW COMPONENTS........................................................................................................................................ 34 2.4.2.26. UC026: INSTALLCOMPONENT ...................................................................................................................................... 34 2.4.2.27. UC027: UNINSTALLCOMPONENT .................................................................................................................................. 34 2.4.2.28. UC028: GRANTADMINISTRATORPRIVILEGES................................................................................................................... 35 2.4.2.29. UC029: REVOKEADMINISTRATORPRIVILEGES.................................................................................................................. 35 2.4.2.30. UC030: DOWNLOAD A FILE........................................................................................................................................... 35

2.4.2.31. UC031: UPLOAD A FILE................................................................................................................................................ 36 2.4.2.32. UC032: MANAGEFILES............................................................................................................................................... 36 2.4.2.33. UC033: DELETE FILE.................................................................................................................................................... 36

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

2.5.1. VIRTUALCLASSCOMPONENT ............................................................................................................................................. 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. CLASSBLOCK................................................................................................................................................................... 41

2.5.3. CLASSMODULE............................................................................................................................................................... 42 2.5.3.1. LINKS AND COMPOSITION................................................................................................................................................... 42


4/115



2.5.4. CLASSFEEDGENERATOR.................................................................................................................................................... 42 2.5.4.1. METHODS...................................................................................................................................................................... 42 2.5.4.2. LINKS AND COMPOSITION................................................................................................................................................... 43 2.5.5. CLASSUSER.................................................................................................................................................................... 43 2.5.5.1. PROPERTIES.................................................................................................................................................................... 43 2.5.5.2. METHODS...................................................................................................................................................................... 44 2.5.5.3. STATE DIAGRAM.............................................................................................................................................................. 46 2.5.5.4. LINKS AND COMPOSITION................................................................................................................................................... 48 2.5.6. CLASSPARTIALADMINISTRATOR(INHERITSUSER) .......................................................... ......................................................... 48 2.5.6.1. METHODS...................................................................................................................................................................... 49 2.5.6.2. LINKS AND COMPOSITION................................................................................................................................................... 49 2.5.7. CLASSSUPREMEADMINISTRATOR(INHERITSPARTIALADMINISTRATOR) .............................................................. ........................ 49 2.5.7.1. METHODS...................................................................................................................................................................... 49 2.5.8. CLASSUSERGROUP .......................................................................................................................................................... 50 2.5.8.1. PROPERTIES.................................................................................................................................................................... 50 2.5.8.2. METHODS...................................................................................................................................................................... 50 2.5.8.3. LINKS AND COMPOSITION................................................................................................................................................... 50

2.5.9. CLASSLANGUAGE............................................................................................................................................................. 50 2.5.9.1. PROPERTIES.................................................................................................................................................................... 51 2.5.9.2. LINKS AND COMPOSITION................................................................................................................................................... 51 2.5.10. CLASSTHEME.................................................................................................................................................................. 51 2.5.10.1. PROPERTIES................................................................................................................................................................ 51 2.5.10.2. METHODS.................................................................................................................................................................. 51 2.5.10.3. LINKS AND COMPOSITION.............................................................................................................................................. 52 2.5.11. CLASSFILE...................................................................................................................................................................... 52 2.5.11.1. PROPERTIES................................................................................................................................................................ 52 2.5.11.2. METHODS.................................................................................................................................................................. 53 2.5.11.3. LINKS AND COMPOSITION.............................................................................................................................................. 53

2.5.12. SINGLETONCLASSFILEMANAGER........................................................................................................................................ 53 2.5.12.1. METHODS.................................................................................................................................................................. 53 2.5.12.2. LINKS AND COMPOSITION.............................................................................................................................................. 54 2.5.13. CLASSSESSION................................................................................................................................................................ 54 2.5.13.1. PROPERTIES................................................................................................................................................................ 54 2.5.13.2. METHODS.................................................................................................................................................................. 54 2.5.13.3. LINKS AND COMPOSITION.............................................................................................................................................. 55 2.5.14. STRUCTUREHOST ............................................................................................................................................................ 55 2.5.14.1. MEMBERS.................................................................................................................................................................. 55 2.5.15. SINGLETONCLASSSYSTEMLOG ........................................................................................................................................... 55 2.5.15.1. METHODS.................................................................................................................................................................. 56 2.5.15.2. LINKS AND COMPOSITION.............................................................................................................................................. 56 2.5.16. SINGLETONCLASSERRORLOG (INHERITSSYSTEMLOG) ............................................................................................................ 56 2.5.16.1. METHODS.................................................................................................................................................................. 56 2.5.16.2. LINKS AND COMPOSITION.............................................................................................................................................. 56 2.5.17. CLASSSYSTEMEVENT........................................................................................................................................................ 56 2.5.17.1. PROPERTIES................................................................................................................................................................ 57 2.5.17.2. METHODS.................................................................................................................................................................. 57 2.5.17.3. LINKS AND COMPOSITION.............................................................................................................................................. 57 2.5.18. CLASSSYSTEMERROR(INHERITSSYSTEMEVENT) .................................................................................................................... 57 2.5.18.1. PROPERTIES................................................................................................................................................................ 57

2.5.18.2. METHODS.................................................................................................................................................................. 57 2.5.18.3. LINKS AND COMPOSITION.............................................................................................................................................. 57


5/115



2.5.19. SINGLETONCLASSBANNEDUSERLIST................................................................................................................................... 57 2.5.19.1. METHODS.................................................................................................................................................................. 58 2.5.19.2. LINKS AND COMPOSITION.............................................................................................................................................. 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: INTERFACEMODEL.............................................................................................................................................. 61 3.4.2. RN002: PLUG-IN COMPONENTS ........................................................................................................................................ 61 3.4.3. RN003: PLUG-IN SKINS.................................................................................................................................................... 61 3.4.4. RN004: MULTILANGUAGEINTERFACE................................................................................................................................. 62 3.4.5. RN005: USER REGISTRATION, AUTHENTICATION AND PRIVILEGES.............................................................................................. 62 3.4.6. RN006: ADMINISTRATIONPANEL....................................................................................................................................... 63 3.4.7. RN007: URL REWRITING................................................................................................................................................. 63 3.4.8. RN008: COMPONENTS INSTALLATION................................................................................................................................ 64 3.4.9. RN009: SYNCHRONOUS ANDASYNCHRONOUSREQUESTS...................................................................................................... 65 3.4.10. RN010: RDF/RSSFEEDS................................................................................................................................................. 65 3.4.11. RN011: SESSION STATEBACKUP........................................................................................................................................ 65 3.4.12. RN012: DOWNLOAD MANAGER........................................................................................................................................ 65 3.4.13. RE001: COMPONENTS SDK .............................................................................................................................................. 66 3.4.14. RE002: ALTERNATEACCESSIBLE VERSION OF WEBSITE............................................................................................................ 67 3.4.15. RE003: PRIVACYSAFETY................................................................................................................................................... 68 3.4.16. RE004: INSTALLATIONSCRIPT............................................................................................................................................ 68 3.4.17. RE005: BASICCOMPONENTS............................................................................................................................................. 69

3.4.18. RE006: SYSTEM ANDERRORLOG ....................................................................................................................................... 70 3.4.19. RE007: USERBAN .......................................................................................................................................................... 70 3.4.20. RE008: ERRORREPORTING............................................................................................................................................... 70 3.4.21. RE009: SYSTEMRESTOREBACKDOOR................................................................................................................................. 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 OFSENSITIVEDATA............................................................................................................................. 72 3.4.26. RI005: LOGIN FLOODPROTECTION..................................................................................................................................... 72 3.4.27. RI006: USERGROUPS...................................................................................................................................................... 73

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

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

3.6.1. COMPONENTS: STORAGE, IDENTIFICATION ANDADMINISTRATION............................................................................................. 74 3.6.2. AVATARS........................................................................................................................................................................ 75 3.6.3. USER ANDSESSIONIDENTIFIERS.......................................................................................................................................... 75 3.6.4. DIRECTORYLAYOUT.......................................................................................................................................................... 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



6/115



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


7/115



4.3.16. OVERLOADSGETGROUPMEMBERS(SID: STRING, GNAME: STRING): STRING[].............................................................................. 91 4.3.16.1. PARAMETERS.............................................................................................................................................................. 91 4.3.16.2. EXCEPTIONS................................................................................................................................................................ 92 4.3.17. OVERLOADSGETGROUPMEMBERS(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. OVERLOADSGETUSERINFO(SID: STRING, USERNAME: STRING, [ONERRORTHROWEXCEPTION: BOOLEAN= TRUE]): IUSER .................. 98 4.3.23.1. PARAMETERS.............................................................................................................................................................. 98 4.3.23.2. EXCEPTIONS................................................................................................................................................................ 98 4.3.24. OVERLOADSGETUSERINFO(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/115



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. GUIMODEL ...................................................................................................................................................................... 111 12.2. USE CASE ANDCLASSDIAGRAMS........................................................................................................................................... 111 12.3. CLIENT-SIDE DYNAMIC LOAD AND INTERACTION: PARENT ANDCHILD............................................................................................ 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


9/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 , designingthe global architecture and, separately, its main components. At this time, only the WSDL client/server interface hasbeen completed. We have spent some time designing the database layout, but its missing the PL/SQL proceduresrequired 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 NotesNone, yet


10/115




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 aboutare transfer load, user-friendship and graphical appeal. When a user 1 navigates a standard HTML site, every actionconsists 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 thepage will, at every click, load the external RSS feed and parse it using XML. Some advanced scripts cache the RSS filesinto the database, but when the feed is not often updated this still causes a overhead to the database. The serverhas 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 tomove 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 theprogram 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 requirementsanalysis, 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 neededto develop and release the Open Source CMS FlashNuke. These will be the basis of the project, and will be used tobuild the final documents: Requirements Analysis Document (RAD), that describes the systems features , the SystemDesign Document (SDD), that decomposes the projects in more sub-projects, for which the Object Design Documentwill not be written at this time. This project also requires the production of a Software Development Kit (SDK) due toits plug-in nature. The SDK is intended to be distributed to the developers that want to build new components forFlashNuke and have to follow its coding model.

Due to the differences between standard software development models and Open Source software developmentmodel, we are not planning to examine costs and resources for development. Open Source software usually followsthe release early, release often philosophy, meaning that during the development phase many alpha or beta versionwill be released at developers discretion. Also, when the development team is not large and the project is not yetpopular, 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


11/115



1.2. References1. 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.


12/115



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 theanalysis phase at analysts discretion, usual ly if they do not complicate excessively the program.

After listing the requirements, the main problem will be decomposed in sub-problems, the technical feasibility willbe evaluated by code-prototyping some features, and a development plan for all the subprojects will be done

2.1. User RequirementsBy 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 referencemodel is the Open Source PHP-based CMS PHP-Nuke (5) by Francisco Burzi.


13/115



FlashNuke has to allow the webmaster 2 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 newskins have to be installed easily without recompiling.

The interface, like PHP- Nukes, is built -up by blocks and modules . A block is a small component displayed on the sideof the interface, that provides useless information or access to site services to the user. Some examples of commonblocks: last topics on Forums, login, summary of private messages, etc. A module is an application component that isdisplayed 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 begenerated 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 behttp://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 emailaddress to the system, but its a choice of the Administrator 4 to require the confirmation of the email address. Eachuser has a profile that stores some basic information, like displayed name, avatar , biography, date of birth, etc. Theuser must have the ability to delete his profile and all information related to him (except logs) from the website database, in order to fit the requirements of most strict privacy laws, like Italian law 196/2003 that explicitly requires thisfeature.

Users may choose to let the system back their session state up. This means that, when the user closes the browserwindows and enters the site again, after login he may be offered to restore the status of the website as it was leftthe first time.

The website Administrator may nominate other Administrators among the registered users, and may decide accesspolicies 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 websitemain Administration Panel . Each control panel has responsibility over its components 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 synonyms4 With the word administrator , we mean the user that is authorized to make changes to the website. Often the webmaster is anadministrator too, but he may elect other administrator without electing them webmasters


14/115



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 userwho 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 onsending 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 bythe Administrator) by the first request or when a synchronous request is made. Here is an example: at a certain timethe user is writing a message for the Forums, and a block showing last Forum topics is displayed on the side. Theblock just repeatedly requests for the last 10 topics posted, and it will reasonably use the asynchronous requestmethod. 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 tothe 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 aread-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 mustuse 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 thedevelopers and the analysts. Everyone in the community may recommend us new features and components to in-clude in the official release.

2.2. System RequirementsA Rich Internet Application is a program that needs a Webserver and a data storage to run. The server stores all thefiles of the application and all data required to run it. A piece of software runs on the client and the rest is executedon 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 forwebsites is stateless . It means that every communication between the client and the server does not consider thepast history of the transaction. This also implies that the program needs to make use of the concept of session . Usu-


15/115



ally, web applications use special marks to identify a session, which is associated to a specific user and/or programstate by the server, which keeps session data. Giving the client the responsibility of reporting its state to the servermay lead to a security risk, becau se clients 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 andthe server side, unlike classic scripting languages such PHP or ASP.NET that generate client code dynamically. TheAdobe 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 s ide of the program can bedeveloped using any scripting language that runs over HTTP or even, thanks to Flex capabilities, with a dedicatedTCP/IP application. Whatever the choice is, a common protocol must be defined before implementing the client andthe 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 abrand new program for storing data. More, PL/SQL stored procedures fit the requirement that if the user has noadmin 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 systemmust 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 RequirementsThe following requirements have been explicitly requested among the user requirements.

2.3.1.1. RN001: Graphical User Interface structureThe user interface must be bades on the following model (code snippet #1)


16/115



Picture 1 An example of FlashNuke user interface

2.3.1.2. RN002: Plug-in ComponentsAs 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 core 5 or a component must not affect the other one. This means that the components must be stored infiles 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 SkinsLike components, visual skins must also follow the plug-in model. Artists can create and distribute skins over thenetwork. 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 likethe kernel in an operating system. Both client and server have a core.


17/115



2.3.1.4. RN004: Multilanguage interfaceThe 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, andmust provide a valid email address, though email verification can be enabled or disabled by Administrators. The username is chosen by the user himself, but, of course, it must have not been taken by someone else yet. When loggingin, a user must provide his user name and either an alphanumerical password or a digital signature. The passwordand the signature can be changed to improve security. However, if the user loses his password/signature, he must beable 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 differenceswill be mentioned when needed

In order to change a users 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 PanelFlashNuke 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 installedmay carry a specific Administration 6 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 RewritingThe web portal must allow the user to bookmark and share direct URL addresses that load FlashNuke in a specificdesired state. This requirement is better explained by an example:

6 Sometimes we will refer to is as Control Panel


18/115



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 browsers address bar to paste it into a chat windowor email client. Or he can just bookmark it using web browsers Favourites feature for personal reference. WithFlash-based websites, the URL never changes since a single SWF file (inside an HTML container) is loaded and thebrowser 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 likehttp://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 InstallationNew modules to be installed may require actions to be able to execute. Such actions may include preparing the datasource to host the data the component uses. Everything required to run the component must be included in anautomated 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 requestsEvery 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 donewhen 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 FeedsFlashNuke 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 properURL/URIs.

2.3.1.11. RN011: Session state backupThis is a special feature for registered users. When the user leaves the portal by closing the web browser (or after asystem hardware or software failure like power loss), the view state of the interface is saved, and the user will beprompted, after his next login, to restore the previous session.

2.3.1.12. RN012: Download ManagerFlashNuke is required to manage the files available for download with a mechanism that prevents direct linking 7 of files available for download 8.

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 servers bandwidth and often causing ec onomic damage. Webmasters, even if dis-tributing their files publicly, prefer that the user first displays a page containing the effective download link andmaybe 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 its stored on the server. It causes immediate download of the file8 They can be the attachments of a forum topic, or pictures in a gallery


19/115



FlashNuke download manager must be configurable to optionally check that the user is not coming from an externalwebsite.

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 thatwill work within the web portal. FlashNuke must be extensible with no limit to satisfy every webmasters needs.

In order to allow other developers to code for the FlashNuke platform, a comprehensive documentation on how tocreate 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 filesneeded to compile new components.

2.3.2.2. RE002: Alternate Accessible version of websiteThe 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 handicapthat 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 safetyThis 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 itsstructure, must be designed to protect every users privacy, ac cording to the principle the of informed consent 9, in-

cluding the following rules:

The website must require a minimum set of personal data in order to work properly. Other information mustbe optional

The user must be informed a priori 10 about what data is collected by the system and how its used. Examplesinclude 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 users email address may not be shared with marketing partners unless he gave explicit consent toreceive 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 hes 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 whos being provided a service is informed about whats being done with his personal dataand the traces left by himself before accepting the service provision10 Before the data is collected


20/115



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 its not often possible (particularly under Windows) to directly a ccessthe servers command shell

2.3.2.5. RE005: Basic ComponentsSince 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 independentlyfrom the FlashNuke architectural project, and then included in the final package that will be freely available fordownload.

2.3.2.6. RE006: System and Error LogFor security reasons, a website must have a System Log, browsable by the Administrators, that keeps track of useractions in order to prevent dangerous or illegal actions such as attacks, finding the user that made an attack or tryingto find the vulnerability that has been used to attack the website. The System Log, however, should not be designedas 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 outthe cause of the error (often a bug in the system).

2.3.2.7. RE007: User BanEvery 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 triesto share illegal data (i.e. warez, child pornography) on a Forum, more than be reported to local authorities, shouldalways be kept away from those Forums.

2.3.2.8. RE008: Error ReportingWhen the system, or one of its components, goes into an error state that prevents regular processing, the error islogged as stated by RE006. However, the development team may be interesting in finding and fixing the problemthat 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

FlashNuke Doc v070724

Documents

Transcript of FlashNuke Doc v070724