31. August 2012 00:55 by Cameron in C++, Qt  //  Tags: , , , , , , , , , ,   //   Comments

In the process of writing the IGA desktop application, I've been faced with several design decisions. One of the most challenging decisions I had to make was how I should most effectively interact with a database backend. To help with this decision, I weighed out the pros and cons of using ODBC and a RESTful web API. Each of these methods are very good for certain purposes.



  • Cross platform support through C/C++ libraries
  • Secure using username and password (connection encrypted)


  • Some ISPs/Schools block port 1433 (used with SQL Server) or other database ports (MySQL, Postgre, etc)
  • Slow response time in some instances (running multiple queries can take a fair amount of time)



  • Fast response time
  • Abstracts data backend - i.e. allows for an easy switch of database servers or switch of web server languages
  • Easily allows for multiple desktop and mobile frontends by adhering the web API interface (ODBC isn't usually standard in mobile platforms)


  • Requires tighter security
  • All requests must be encrypted using SSL or  plain text is sent to the server
  • Requires some sort of authentication either by API key or other method to prevent arbitrary access to server

Ultimately, I decided to go with using a RESTful web API for maintaining separation of the database architecture from the IGA desktop application. This will allow me to change the database backend without breaking the application as long as I keep the API interface the same. Another huge factor in choosing a RESTful web API is that my school blocks port 1433 on its campus wireless networks. I want college students to be able to use the IGA desktop application while on campus so this was a necessary choice. Overall, both provide advantages and disadvantages and neither one is "better" than the other. I hope this helps people with the decision between ODBC and a RESTful API.

Installation of Postive SSL wildcard certificate

26. September 2011 01:27 by Cameron in Security, Web  //  Tags: , , , , , , , , ,   //   Comments

The other day, I splurged on getting a wildcard SSL certificate for my website, www.iga-home.net. I felt that it was important to secure content on my site for my users as sensitive data is sent when users login or post content to the site. I bought a wildcard SSL certificate since I wanted to be able to secure all subdomains of iga-home.net and not be restricted to just iga-home.net or www.iga-home.net. 

After I created the request on IIS for the certificate, I copied the output into my web browser on Comodo's website for requesting an SSL certificate. It seemed fairly straight forward. About 10-15 minutes later, I received an email with my SSL certificate attached in a zip file. I opened the zip file and saw my certificate with a .cert extension. I fiddled around for a while with trying to get this certificate installed through mmc and IIS's manager. When I tried to install my certificate through IIS, I kept receiving errors that IIS couldn't find my certificate request. I followed many tutorials and couldn't find a solution. I later found this page that said I should install these certificates first through mmc before I could install my purchased SSL certificate in IIS. After I installed these mentioned certificates, IIS accepted my certificate and I proceeded to adding SSL to my website. It's a shame that these certificates weren't bundled with the original zip file. It would have made life a lot easier.

My next task is to add a rewrite rule for sending all http requests to https requests. I also want to write a resource handler that caches remote resources on my server so that all resources are secure. In Google Chrome it will notify the user if some content displayed on a page is insecure and I want to remedy this problem. 

Month List

Tag cloud