CSBG Web Application General Documentation Encryption Since

advertisement
CSBG Web Application General Documentation
Encryption
Since Social Security Numbers are very sensitive data, it was decided to encrypt the numbers as
they were saved and retrieved to and from the database. The chosen encryption method was Triple DES
algorithm. At the beginning of every .cs file contains the initialization vector and key used to accomplish
this. The actual encryption is done by a class called “DESClass,” which is contained inside the app code
folder.
In the event that Rijndael encryption is desired, there is also a class in the app code folder for
that. There is also commented code at the beginning of every page that encryption/decryption is
needed that contains the necessary information for that encryption algorithm to be used.
The command “aspnet_regiis.exe –pe “connectionStrings” –app “/CSBG” was used to encrypt
the connection string in the web.config. In order to allow the encryption key to be used to decrypt it, the
command “-pa “NetFrameworkConfigurationKey “Everyone” was used to allow the ASPNET user to have
access to it. In order to encrypt this on the EWEB server, you must open a MSDOS command prompt.
Then navigate to the directory the exe is location by using:
cd C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727. Then type the above command to encrypt the
connection string. Then type the second command to allow the user to decrypt it.
Ajax Control Toolkit
Ajax Control Toolkit was used in this application for much of the functionality and appearance.
In order to use the toolkit, Ajax Extensions needed to be installed and an “AjaxEnabled” template site
was created. This means that the web.config contains many extra lines of code so the toolkit can
function properly within the application. TabContainer and its sub-panels, TabPanels, are used heavily in
the dataentry and viewdata pages. UpdatePanels are used in every page to utilize the capabilities of
partial postbacks. A few of the Update Progress’s have been used along with the panels to let users
know that the application is performing some action since it doesn’t redraw the page. Crystal Reports
Viewers had issues with using the Update Panels when it came to exporting and printing. To make sure
the viewers can perform the actions on the toolbars, a PostBackTrigger must be added to the trigger
collection of an UpdatePanel.
AutoCompleteExtender and ConfirmButtonExtender were also used within the application. The
AutoCompleteExtender runs off of the sidelistservice.cs, which is contained in the app code folder. The
ConfirmButtonExtender is used to make decisions based off an alert box answer or button pressed. The
final toolkit item used was the CalendarExtender, which is much like the default web server control but
just has added functionality.
Reports
There are four reports that have been created for this application. Two of them are slightly
different than the others due to the passing of an encrypted parameter into the stored procedures that
generates them. This is done in GoalsReport1_6 and GoalsReport1_6 Short. SSN is the parameter that
causes the change in passing parameters to the stored procedure that generates them. Because the
encryption of SSN is done within the application using Triple DES and SQL does not offer the same way
to encrypt and decrypt, the parameter must be decrypted and then passed manually to the stored
procedure. By default, blank values are passed to the store procedure and are interpretted as all results.
Deploying Crystal Reports
In order for crystal reports to function correctly, it must be installed on the server or all the ddl’s
must be in the bin folder associated with it. To make the process easier, I have created a project that
contains the MSI file to install the crystal files on the web server. It is located in
E:\Inetpub\ftproot\WebSetup3\WebSetup3\Debug\CrystalReports on the web server. Double click the
CRRedist2005_x86.msi file and it will automatically install the necessary files to run crystal reports on
the site.
CompStats Tab
Due to the request of adding household members to the client characteristics report, the
CompStats tab was added. This tab is only used if the household members of a customer is to be
included in a report. These values are added to the family count in the stored procedure that generates
the client charactertistics report.
Customers with No Characteristics
A special case was needed for customers who did not have characteristics collected on them.
The “No Characteristics” checkbox takes care of that. When the checkbox is checked, the validation of
the characteristics is bypassed and only the necessary information for the client is required.
Programmatic decisions to identify whether a customer falls in this category is based on the
“NoCharacteristics” field in the “General” table of the database.
Income Level and Eligibility
Income level and eligiblity is calculated based on the 200% Federal Poverty Guidelines.
Whenever an income inclusion is added to a customer, their CSBG income and income level is
recalculated. The algorithm to calculate the income level is based on 100% of the FPG. Currently, at the
time of creation, 10380 is 100% FPG and the incrementer for each family member added is $3740. In the
statement that inserts an income exclusion, there are guideline and incrementer variables that hold
these values. If the FPG were to change these two variables would need to be changed to reflect that.
Eligiblity is solely based on the income level. If they are over 200%, then they are not eligible.
Permissions Levels
In order to prevent users from doing things they shouldn’t be, permission levels were created.
The list of user permissions are as follows:
adm – Admin account which has access to all pages and can add, edit, delete.
mgr – At this current time, this permission level has the same privledges of the admin accounts. But it
was created so in the future, permissions can be added/modified for them.
den – This is the data entry account level. This permission level does not have access to the history page
and cannot delete records.
von – This is the view only account level. This permission level cannot access the data entry, create
users, and history pages. This is the lowest level of permission in the system.
Pages
Main Pages
createusers – This page is used to add, edit , and delete users from the system . Only adm and
mgr permission levels may access this page.
dataentry – This page is where most of the work will be done within the application. Users can
add, edit, and delete customers from the system. The tabs contain each specific section of
information that may be collected on any given customer
Default – This is the default page that the user sees when logging in to the systeml.
enablejavascript – This is the page the user is redirected to if they do not have javascript
installed on their system.
GoalsReport1_2_6 – This is the page that contains the report for goals 1 and 6 short. For
information on how to export and print, refer to the ExportingAndPrintingReports document.
GoalsReport1_6 – This is the page that contains the report that Mary Lou uses. For information
on how to export and print, refer to the ExportingAndPrintingReports document.
GoalsReport1_6Full – This page contains the report that includes all goals and their
subcategories for goal s 1 and 6. For information on how to expor and print, refer to the
ExportingAndPrintingReports document
History – This page contains the history log of add, edit, and deletes that have been performed
on the system. Only mgr and adm levels may access this page to view the activity that has been
performed on the system
Logout – This is the page where users will be able to log out. Once the logout button is clicked,
all session variables and unsaved work is lost.
Search – This page is only accessible from the dataentry page. This is so users can search for
particuliar customers to see whether they exist in the system or not. The results table has
selectable rows that if clicked on will select the corresponding row in the dataentry page.
Viewdata – The viewdata page is simply for viewing data on certain customers. Some permission
levels do not have access to the dataentry page. So the viewdata page satisfies the need to look
up data for those who don’t have the permissions.
Goals Popups - each one of the popup windows below contains a list of goals and
corresponding checkboxes so customer’s goals can be reported on.
Education
EmergencyServices
Employment
Health
Housing
IncomeManagement
Linkages
Nutrition
Self Sufficiency
Supported Browsers
This application has been tested thoroughly with Internet Explorer 6.0 and later and Firefox 3.x.
There is slightly different formatting between these two browsers but the overall appearance and
functionality remains the same. The application also works with Google Chrome and Safari, but has not
been fully tested with those browsers. Opera seems to have many problems with the application
therefore it is not accessible with that browser.
JavaScript
Due to the nature of this application, JavaScript must be installed and enabled within the
browser to log in and view any of the pages. Without JavaScript, the content will not be available and
much of the functionality will be non-existent.
Validation
Validation of all data entry is done first on the client side and then on the server side. All
required fields are checked to see if they are empty. All dates are checked to see if they match
mm/dd/yyyy formatting. All numerical values are checked to make sure they are numeric as well.
Deployment/Testing
A copy of the application is stored on Laptop 08 that can be used for adding, editing, and
testing. That copy will not load the reports correctly though because they are pointing towards where
the live site is. In order to get those reports working correctly you must edit the crystal report sources
and the .cs pages so they are pointing to the local directory. It is recommended that you also change the
connectionString in the web.config to use the local SQL server so the live data on the hosting server will
not be modified during test. Of course, this process must be reversed upon deployment back to the
hosting server. The application on the host server is pre-compiled for security and optimization reasons.
A backup copy that is not precompiled and can be modified on the EWEB server is in the same directory
as the main site called CSBG NonCompiled. If you want to make changes, load the non-compiled copy,
make the changes, and recompile and then overwrite the existing copy of CSBG. You may have to re-run
aspnet_regiis –pe “connectionStrings” –app “/csbg” to make sure the connection string gets encrypted
when overwriting.
Download