Radius 9

Articles

  • Mercurial on Windows Server the easy way

    We've been running Subversion for quite a while. We've seen the progression from manually setting up SVN on Apache to the simple install with a package like VisualSVN. We've been running SVN on a Windows based server, but we've been using git for our Linux development, and have become convinced about the virtues of a distributed version control system. Git seems a little clunky, and I'm personally not a big fan of their IDs, and maintaining a separate Linux server just for the version control wasn't high on my list of things to do. Mercurial seemed like a good option, but I wasn't able to find an easy package that didn't require me to do a bunch of compiling and linking things together with various Apache modules to get working. We weren't going to make our transition overnight, so I wanted something that would co-exist peacefully with our existing Apache install using VisualSVN. In an ideal world, I'd even be able to do my account management in a single place. Luckily, I found that I would be able to configure my existing Apache install through VisualSVN to also support Mercurial. The instructions I found online didn't quite work, so I thought I would post how I did it here. For the purposes of this tutorial, I'm showing the VisualSVN install path as C:\Program Files\VisualSVN Server\. Change the path to where you have VisualSVN installed.

    1. The first step is to install VisualSVN. There's a free version if you don't need web based management. We're going to use VisualSVN for the initial Apache install, as well as for our account management.

    2. The second step is to download wsgi, which is much faster than CGI. You can get it here.

    3. Copy the mod_wsgi.so file to "C:\Program Files\VisualSVN Server\bin".

    4. Install Mercurial on your machine, using which ever version corresponds with your server.

    5. Copy the hgwebdir.wsgi from your Mercurial installation to "C:\Program Files\VisualSVN Server\".

    6. In the C:\Program files\VisualSVN Server\conf directory, you'll find the file httpd-custom.conf. You'll want to add edit this file, and add the following:


    LoadModule wsgi_module bin/mod_wsgi.so WSGIScriptAlias /hg "hgweb.wsgi" <Location /hg/ > AuthName "Mercurial Repositories" AuthType Basic AuthBasicProvider file AuthUserFile "path/to/subversion/repo/htpasswd" AuthzSVNAccessFile "path/to/subversion/repo/authz" AuthnVisualSVNBasic on AuthnVisualSVNIntegrated off AuthnVisualSVNUPN Off SVNParentPath "path/to/subversion/repo" require valid-user </Location>
    In your file, replace the text path/to/subversion/repo/ with the path for where your subversion repositories are stored.

    7. Finally, create a new directory under your subversion repo folder, for example MercurialTest. Change to that directory in a command window and type "hg init ." to create a Mercurial repo. You should now be able to add accounts using your VisualSVN user manager software, and go to your Mercurial repo at the address "http://yourserver.com/hg".

    Tom Ketola - July 18th, 2011

  • Who stole my cookie?

      I've been working on a web application, and ran into an interesting problem (and solution). Our application requires users to login, and so we have a fairly typical setup with a session ID being generated and sent to the user as a cookie. This session cookie is then later used to validate that the user is logged in. Good security practices say you shouldn't store the expiration time for the session in the cookie, and we do not. We had however, put an expiration on the cookie. I had used this is a shortcut on the client side code to check whether the user was logged in, and display a different UI depending on this cookie's existence. It didn't actually use this to check whether the user was logged in, but if the cookie was not there, it would redirect the user to the login page if they had, for example, bookmarked a direct page somewhere in the application, and they were no longer logged in.

      So here's where the interesting bit comes in. We rolled the product out in a limited test to a customer, and one of their remote offices called me and said they were not seeing the interface correctly. After a bit of investigation, it seemed that they were logging in, and all the session cookies were being set correctly except for our SessionID cookie. I quickly realized that this was the only cookie that had an expiration set on it. It ends up that by adding an expiration to the cookie, it immediately gets converted into a persistent cookie. The firewall or proxy at this particular office was stripping any persistent cookies from the web session, which put the user into a state of having successfully logged in, having a valid SessionID, as well as having all the other cookies we expect, but just not returning a sessionID to us. I had done a search for solutions to this when I ran into the problem, and I wasn't able to find any articles describing this particular problem. Most people working on web applications are programming at a higher level, and some of the implementation details of what's going on behind the scenes may be hidden from them, so I thought I would write this article describing our problem (and the solution). So if you have cookies disappearing from sessions, and it doesn't seem to be consistent, take a look at whether its your persistent cookies that are being stripped.
    Tom Ketola - July 15th, 2011