It’s been a while…

I haven’t been on my website for a while now, and I just noticed it is in dire need of an update. Unfortunately, I don’t currently have much time between school and work (and I am unable to classify this website as “work”), so it’ll have to wait. I’ll most likely be able to put more effort into this once the first month of school is over, but for now, I can’t do much except make sure everything barely works. I’m still alive, though.

Force HTTPS Redirection using .htaccess

I have recently added an SSL certificate to my website, and was looking for a way to force HTTPS redirection so everyone ends up on the SSL version of the site. I quickly browsed the Internet to see if there was a ready-made solution to this and found some, but they all had one of two issues: one, they didn’t work at all; or two, they force SSL on both the main domain and all subdomains, which is something I did not want. Therefore, I had to create my own SSL redirection using Apache’s .htaccess file.

Forcing SSL on a domain is actually relatively simple when using the .htaccess file. This is the code I have been using lately, and it works perfectly:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^(www.)yourdomainname.com
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

You can simply copy and paste this code into your root .htaccess file, and it should redirect all incoming traffic of your main domain to HTTPS. Make sure to replace yourdomainname.com with your actual domain name! Also, be careful: make sure to put these four lines before anything already present in your .htaccess file. This is especially important if you are using WordPress like I am, since WordPress has its own rewrite rules that will override these if they are put after WordPress’ code.

How does it work?

This .htaccess code is actually relatively straightforward:

  • The first line simply tells Apache that the next lines will be rewrite conditions and rules.
  • The second one adds a condition where HTTPS must not be enabled for the rule to be applied.
  • The third line adds another condition where the HTTP_HOST, i.e. everything after http:// and before /rest/of/url, must match the Regex string ^(www.)yourdomainname.com.
    • The ^ indicates that the string must start with the following characters;
    • The (www.) indicates that there can be a www before the domain, but it is not required;
    • The yourdomainname.com simply indicates that the domain must be yourdomainname.com (replace this with your own domain name, of course).
    • You can remove the ^(www.) if you want your HTTPS redirection to be applied to all subdomains.
  • The final line tells Apache that if the conditions above are matched, the URL must be rewritten to the value next to RewriteRule.
    • ^(.*)$ indicates that the whole string (^ = beginning of string, (.*) = everything inclusively, $ = end of string) must be replaced;
    • https://%{HTTP_HOST}%{REQUEST_URI} indicates that the string must be replaced by https:// followed by the host and the request uri (the /rest/of/url part of the URL)
    • The [L, R=301] actually means two things: the L part represents last, which means that that if this rule is applied, no other rules directly under it will be applied; and the R=301 part means that the rule will be a 301 redirect (“moved permanently” redirection). These are put into square brackets because they are flags.

There you have it! Now all traffic coming to your site will be redirected to HTTPS, rendering your site more secure for everyone!

Dropbox .NET API

EDIT: My Dropbox API for .NET is now available! Get it over here!

I started working on Dropbox integration for MCBackup earlier this month. I was very happy when I discovered a few C# .NET APIs for Dropbox, but soon realized that there was an issue with each and every one of them that made them impossible to use with MCBackup.

I first tried DropNet, which seemed very promising, until I found out two things: it only supports OAuth 1, which is old and crappy, and it requires you to enter your Dropbox app’s key and secret to give the user a token, which is a bad idea when creating open-source software. I did not want other people to start stealing my Dropbox keys, so it would be ridiculous to include them on public source code, which is why I wanted to create the token externally (using a PHP script instead). Unfortunately, DropNet did not support this. I also tried DropNet’s new “little brother”, DropNetRT, but it only supports the .NET framework 4.5 and up, therefore removing the possibility of Windows XP support (even though it’s pretty useless at this point).

I then tried SharpBox, but it was too complicated for no reason whatsoever, and again, did not support creating a user token externally. It also hasn’t been updated in almost four years, which isn’t really a good sign either.

In the end, after browsing the Internet endlessly trying to find a way to integrate Dropbox into a .NET app, I decided it was time to try to make a .NET API on my own, which is what I’ve been doing for the past two weeks or so. This task, which I thought at first would be quite hard and time consuming, ended up being very simple, since I just had to use the .NET WebClient class to make calls to Dropbox’s REST API. I now have an (almost) fully-fledged (and unofficial) .NET Dropbox API that I will probably end up putting up on GitHub, unless the Dropbox v2 API‘s release is announced. It currently supports most features except the ones that require a Dropbox Enterprise account (which I obviously do not have) or ones related to shared folders and links (I didn’t see the point of including them right now).

I also created a wrapper for DotNetZip (which I called Zipper, because I’m that creative) that has built-in functions to compress and extract directories asynchronously without having to deal with threads hanging everywhere (an issue that is somewhat present in MCBackup, hopefully this will contribute to fixing things), but that’s not as interesting.

Stay tuned for more updates!