The edulogon development blog

Is now the file available for download. It corrects two bugs, one of which was present in all previous versions and one of which was added in 3299.

• All previous versions were making three duplicate and sequential requests to test sites when the test site trigger was an http redirect and the the user was not authenticated. This is fixed, and authentication testing is now much faster.
• Fixed a regression in 3299 which prevented the authentication status from being determined when the expected response from a test site was an http redirect.

A minor update from the original release, which was 1.0.3294.41949. This release primarily fixes a crash, but here is the full list of modifications:

• addresses an unhandled exception when systems resume from hibernate (no actual error was occurring, and the exception could safely be ignored, but it produced an “Application has encountered an error” dialog)
• has different connection timeout and retry settings during authentication status testing, should yield faster results
• suppresses the purchase notification entirely during the first 20 days of the 30 day trial (only appears 1 in 4 times afterwords.)
• no longer hides the system tray icon by default
• reports agent version as part of the user agent http header when authenticating
• reports campuses used at to the activation server (marketing data)

Since my last post, developments have been very fast-paced. The project’s inception was four months ago, and finally everything has come together. Today I am proud to be releasing the first publicly available version of eduLogon.

Google checkout integration is complete. Activation server-side and client-side code is complete. The software has its own logo/color scheme/branding/fancy website/slogan with the help of some graphics and design assets that I purchased rights to. Various minor bugs and improvements were coded. I have reached an agreement with CodeWall technologies, a vendor of a powerful .net code obfuscator/decompilation protector, to secure the distributed binary from cracking/hacking attempts. UMD’s IT department (of which I am also a student employee) got wind of the project, and the department’s director weighed in. They have some non-technical issues related to perception of affiliation etc that I am working with them to address, but it sounds like there won’t be any drastic decrees that the software is not to be used on the UMD network or anything, so for the most part I think I’m good on that front.

One last security feature has been added to the code – it is now not possible to edit the logon service urls in the xml.conf file to coerce eduLogon into sending passwords to unauthorized servers. The urls of authorized university authentication servers are now digitially signed by me, and if the address appearing in the conf file does not match the signature, eduLogon displays a security warning, and will refuse to send any saved passwords to the addess that is listed. The user can elect to manually enter a password if they want, but only after they have been informed of the security concern. This way, hackers cannot make malicous changes to the configuration file, but users at unsupported campuses can still write and test valid configuration files for their campus, a feature I wanted to preserve so that eduLogon can proliferate.

I won’t start the promotions campaign until the 20th, when spring semester classes begin at UMD, so barring the discovery of any issues in 1.0, things probably will be fairly dormant until then. Still, I do feel pretty accomplished to have put it all together, put to real-world use all my programming education and experience, and released my first commercial software application.