While this document does not cover the use of our version control software extensively, Omnis Studio VCS does have a list of common tasks a developer should know how to do.
The development platform will be primarily Mac OSX using Omnis Studio and Python.
Compatibility testing for Windows will occur on the Mac under a Parallels Virtual Machine on Vista, Windows 7, Windows 8, Win 10, Win 2008 and Win 2012 server
Primary Development is done using:
There are a number of other tools that are used by developers for specific tasks. If you have doubt about using a tool consult your supervisor or one of the architects. Most source text editing is done with BBedit (eg for web pages and plist files)
All code and key are stored in as VCS, specifically the Omnis Studio VCS or the Git Repository.
There are documented coding guidelines that Arts Management Systems developers should follow.
Arts Management Systems developers are expected to stay current on issues and potential security vulnerabilities in the technology used in the Arts Management Systems product. Arts Management Systems architects will be responsible for monitoring these areas and escalating to management when an issue arises that needs to be addressed in a future product release.
In-code documentation is required for all new code as described in the coding practices.
There are a few areas of the application that are critical for the stability of the product. As such they are the responsibility of the senior developers and architects to maintain. These are called protected classes and you need to contact the architect if you need to work with them and have a mandatory code review after you change them.
With step through testing, you can quickly throw a lot of small tests at a bit of code. An example might be converting a number to text. Adjusting the input parameters and stepping over code to see the results can quickly test many different parameters.
NB: Make sure any testing uses only test cards and never use real credit cards in a non-production environment.
When altering any code that deals with credit card information, it is important that key tests are performed to ensure the software remains in PCI compliance. All security patches and system and software changes need to be tested before being deployed, including but not limited to testing for the following.
| PA-DSS | Requirement | Testing Procedure | What we do in Theatre Manager |
| 5.1.1.1 | Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.) | Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.) | When using the Theatre Manager application, input validation for almost all fields is done through the specialzed protected class called oEditCheck which does specialized validation on inputs. Every text input field in the system will invoke a method from this class. Test your code in the 'evAfter' clauses to make sure that it does for all entry fields.
Since the Theatre Manager 'fat' client is a compliled application and not web based, much of this PCI requirement does not apply. The Theatre Manager commerce web server uses the same edit routines as the 'fat' client but has cleansing routines for parsing data prior to it hitting the edit routines. Refer to OWASP below. |
| 5.1.1.2 | Validation of proper error handling | Validation of proper error handling | particularly for credit card information, make sure that data is not diplayed back to an operator or customer that shows the entire PAN when errors occur. Refer to 5.1.1.5 for routines to display protected information appropriately. |
| 5.1.1.3 | Validation of secure cryptographic storage | Validation of secure cryptographic storage | all card information is updated in the database using a single protected classes called tfCreditCard.$reviseCreditCard. All access to cards is through that protected class and any use will ensure that cards are encrypted properly. However, after a test using credit cards, do an sql query on CD_CARD_NO to make sure nothing exists in clear text. |
| 5.1.1.4 | Validation of secure communications | Validation of secure communications | Card authorization occurs in via https and the merchant providerl. The protected classes oCCAuthorize handle all https communication and will not respond unless the merchant provider supports TLS 1.2 or later (high encryption) |
| 5.1.1.5 | Validation of proper role-based access control (RBAC) | Validation of proper role-based access control (RBAC) | Access to card information is managed in Theatre Manager through a protected class called oSecurity. All display of credit card information is done through another protected class called oEditCheck.$fetchCreditCard which converts all items for display using RBAC. |
For web based components (i.e oWebComxxx), ensure that OWASP vulnerabilities are also tested and verified per PA-DSS standards 5.2.1-5.2.10. This section in the PA-DSS document repeats the current top 10 OWASP vulnerabilities (circa 2010) and are repeated below. Make sure to test those as well as review OWASP to keep this section of the test requirements evergreen.
Above all, read the OWASP top 10 when developing a Web API because they explain clearly what things mean and strategies how to avoid.
| PA-DSS | Requirement | Testing Procedure | What we do in Theatre Manager |
| 5.2.1 | Cross-site scripting (XSS). | Cross-site scripting (XSS) (Validate all parameters before inclusion.) | Look at any incoming parameters for javascript and other characters and simply removes them. We have determined that there is no valid need to have words like <script> in a enterable fields like name or address. Refer to rtWebSales.cleanUpParameters |
5.2.2 |
Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws, as well as other injection flaws. | Injection flaws, particularly SQL injection (Validate input to verify user data cannot modify meaning of commands and queries.) | none of the API's in any oWebComXXX accept SQL for input. Make sure each parameter is checked for existance and validity using oWebComBase.$getWebParameters. |
| 5.2.3 | Malicious file execution | Malicious file execution (Validate input to verify application does not accept filenames or files from users.) | ensure that oWebComXXXX does not accept file names and does not read the file system. All input is sanitized and merged into variables of fixed length (the nature of Omnis Studio) so buffer overflows are not possible. |
| 5.2.4 | Insecure direct object references. | Insecure direct object references (Do not expose internal object references to users.) | OWASP recommends use of API's to address this issue. Build a new oWebComXXX for each web function. |
| 5.2.5 | Cross-site request forgery (CSRF). | Cross-site request forgery (CSRF) (Do not rely on authorization credentials and tokens automatically submitted by browsers.) | TM puts tokens in the cookie that are unique per session and per request. |
| 5.2.6 | Information leakage and improper error handling | Information leakage and improper error handling (Do not leak information via error messages or other means.) | ensure all messages are read from a table (tmError.txt) and only provide user direction, not system state. |
| 5.2.7 | Broken authentication and session management | Broken authentication and session management (Properly authenticate users and protect account credentials and session tokens.) | use the build in tCookie function to read and write cookies. Cookies are 3DES encrypted and contain time information to know if the patron is going back or forward. Requests that cannot be decrypted and have stale information are discared before they get to the oWebComXXX |
| 5.2.8 | Insecure cryptographic storage | Insecure cryptographic storage (Prevent cryptographic flaws). | make sure all internal keys and pw are never clear text in variables. Always store encrypted and use decryption to get the true value. |
| 5.2.9 | Insecure communications | Insecure communications (Properly encrypt all authenticated and sensitive communications.) | Implemented using TLS for the entire web site. Specific tokens like cookies and CC data are AES256 encrypted within the TLS layer. Always test for this. |
| 5.2.10 | Failure to restrict URL access. | Failure to restrict URL access (Consistently enforce access control in presentation layer and business logic for all URLs.) | All access to the web components are throught an API call. These are routed through a single apache module that adds some tokens of its own and redirects the URL to a specific machine, changes the IP and crosses a firewall from the DMZ using NAT. There is never direct access to any oWebComXXX |
After you have checked in all your changes you should perform a clean build test. This is accomplished by renaming your local copy of the source, and getting the latest source from the branch you were working on. Then performing a build to ensure that the code still works.
The size and scope of the peer review process is dictated by the scope of code changes. Altering a line of code to fix an issue does not necessarily merit a code review. Introducing new functionality or altering the user experience of the product on the other hand should require a code review.
At a minimum your code needs to be reviewed by one of the senior developers. If your code changes impact more than a single area then an architect needs to review it. If your code impacts the database schema then an architect needs to review it. Any time there is a change to code that handles track data or credit card numbers; it needs to be reviewed by a senior developer.
Any time your code changes involve the use credit card data, encryption or decryption and/or any of the protected classes, these changes should be discussed with an architect before, and reviewed by an architect afterwards to ensure the highest level of adherence to coding best practices. The TM coding practices specifically addresses how sensitive data is to be dealt with in the Studio Code. OWASP practices specifically address tests for web objects.
A peer review can take many forms. For particularly important code, a 'hand inspection' of the code may be required. Normal code walkthroughs involve explaining the purpose of code segments and object classes. A hand inspection is when a second party actually steps through the new code to verify assumptions, parameters, values, comments and alter boundary conditions to simulate odd or unpredictable cases and attempt to identify unforseen defects.
The approval of a code review results in a the development build and forwarding to QA for testing. This also generates entries in the upcoming release notes which are build as each development release is built. An entry in the release notes constitutes approval of the development build.
As part of passing an issue to SQA for testing you should consider what you have done, and what impacts that will have on the environment and user interface of the application. As developers we often will do things like stopping and restarting a service, or registering a COM control, or installing 3rd party drivers, that the SQA testers will not just know to do. Document these steps that they will need to perform to ensure that development and testing cycles are not wasted. Make sure to attach the FogBugz case numbers for the issue being sent to SQA for testing.
In the defect tracking tool you can forward an issue and mark it ready to test. This will allow SQA to pick it up and begin testing.
While not a requirement it is recommended with any significant change that you follow up in person with the SQA testers that are testing your code. Answer any questions they have, address any concerns. We are all part of the same team and it is all of our jobs to release the best software we can.
The build for QA testing (i.e. any candidate for production release) will include building from the VCS. The option Build without Comments will be used to remove comments from any documentation in the applications.
Because of the way Omnis Studio is tokenized and structured and how the VCS operates, this will also have a supplementary effect of removing any commented test PAN’s and or other text based security information that may be present in the code.
The Studio VCS is used to help control and separate the Development, Test and Release functions.