Web Programs written by Jim

Time Tracking

In early 2002, I fielded a request to provide users at our Contract Research Organization (CRO) with a "spreadsheet" that could summarize time employees spent on projects. At the time, not all workstations had excel, but they all had a browser and my manager had a preference for web applications served from Linux. I also had a strong desire not to deal with summarizing data from literally a couple hundred spreadsheets that users were inserting columns in, etc. All I needed was an app that would simply collect the data from many users and write the facts to a database.

I chose perl as the programming language of choice because my manager had steered me toward that already. With help from him and dozens of Googled perl posts, the product has been in production for well over 2 years.

One of the primary features encourages users to enter their time toward projects, clients and committees on a daily basis by defaulting to the current day. Users advance a day by hitting next, or flip to the Weekly Entry mode to advance by a full week: they never enter a date.

Another technique I employed in the web entry portion of the program is that the current "working date" is maintained in a hidden field as "seconds from the epoch". This makes moving forward and back a day or a week very simple math. The only conversions necessary are consistantly from epoch seconds to Date string, never vice-versa.

A key innovation that I have yet to see elsewhere is that results are downloaded directly into Excel by a macro that taylors a web query of the database from user input. Excel's pivot tables and charts summarize the data with far more flexibility for the end users, and far less programmer time than formatting web reports for both browser and printing. Notable caveats include the need to format time as a decimal (I trim it at thousanths of an hour) and if any cell in the table begins with a minus sign, it must be preceded by a single quote.

To authenticate users I employed LDAP. For purposes of simplicity, I did not use a session ID, but tracked a user's session with their logon name and IP address. If they gave a good username and password pair the program "touches" an empty file on the Linux server that includes the username and ip address. With each submission, it checks to see if the file is too old and the session expired, or it simply touches the file anew. Logoffs delete the file, requiring the user to re-authenticate. Yes, there are some security problems that stem from users with the same apparent IP addresses, but that was seen as a low risk for the time tracking program.

I could say that it was all my work, but I copied a couple lines of syntax from literally dozens of discreet sources. The compilation of this group of techniques is, however, truely unique.

The source code is available on request. Email me at jfieser@gmail.com Back to Home

Remote Access

Another web program I designed and developed was Remote Access. It allows users to log in through an LDAP server with their own account and download files from remote FTP servers. It comes in handy when the users can no longer connect to file shares on a remote server because of a firewall or due to a critical data source being on an obsolete server. In our case, some science apps contiued to run on the old VAX, but users in XP could not access the old version of Pathworks using smb. Using FTP directly didn't work with some of the file protections

The source code is also available on request. Email me at jfieser@gmail.com

Back to Home

New Passphrase Integrity Testing

In order to facilitate the process of changing passphrases, and ensure strong passphrases, we needed to revamp our syncronizing program to trap errors prior to submitting the change form. I added several javascript tests to the password syncronization page that comes with Exchange Server 2003 Outlook Web Access. The following tests are performed by client side javascript:

Username long enough?
Old passphrase entered?
New pass greater than 5 chars?
New pass less than 13 chars?
New pass must contain at least one upper case letter.
New pass must contain at least one lower case letter.
New pass must contain at least one number
New pass must contain no characters that are not letters or numbers.
New pass cannot contain the username.
Old pass and New pass cannot be the same.
New Pass and confirmation must match.

Where applicable, these tests must also run again on the server to catch those who would defeat the client side javascript.

View a working model of the javascript tests here.

So that's what I do: develop useful solutions to real world problems with minimum effort and maximum effect.

Back to Home