A note to self more than anything – next time DotNetOpenAuth’s Channel.Send method doesn’t work (by which I mean cause the current thread to stop, and cause the client browser to redirect to the RP authorisation URL) make sure you’re running against IIS Express or better, as the ASP.NET Development Server seems to swallow the ThreadAbortException and you’ll get redirected nowhere.
I’ve been writing some API wrapper libraries recently – dead simple stuff in Ruby and Python that make calling my company’s OAuth-protected API a bit easier.
With the code on GitHub, and some basic unit tests in place, I wanted to test out Travis CI for continuous integration. Getting things setup on Travis is dead simple, but what I really wanted to do was test the packaged-and-installed library rather than testing it straight from source.
To do this there are a few script lines in the .travis.yml file:
install: - python setup.py sdist --formats=zip -k - find ./dist -iname "*.zip" -print0 | xargs -0 pip install script: - python PACKAGENAME_GOES_HERE/test/__init__.py
This way, every time we check code in to GitHub we can ensure that it:
My PC was recently having some difficulties which were narrowed down to a failing SSD – after 4 years I’d be pretty tired too, so I wasn’t too aggrieved that I’d need to replace it. While I was at it, I upgraded a few other components too:
Problem is – the new system was substantially slower than the old one. Initially I thought that was down to having had the two SSDs RAID-0’d and the chipset not liking it, so I broke the array and reinstalled to find things marginally improved but still slow. In fact, the wheels were coming off the wagon with the Anytime Upgrade to W7 Ultimate, with long pauses on startup and sluggishness in games.
Some Googling later and I found a Stack Overflow post detailing a suggested fix – bizzarely, to turn on the integrated graphics on the motherboard (even though I’ve a PCI-E graphics card) and allocate to it as much RAM as the BIOS will allow (480MB ish).
Proof’s in the pictures:
What the shit?
The RMW Whisky Fringe 2012 starts tomorrow, and the electronic version of the programme’s finally gone out with details of the Tasting Tracker app in it which is all a bit exciting – now to hope that Azure’ll keep it ticking over nicely for the next three days.
The site went live at http://www.wf2012.co.uk to make it a bit quicker to type on a mobile, and already has a few tens of people signed up and making wishlists.
To give myself some deployment options for the Whisky Fringe 2012 Tasting Tracker site I’ve been using my Microsoft Azure 90 day trial account to try setting up cloud-based hosting. This comprises two services:
Given that I might want to scale up the site for the event session state needs to be managed by the SQL Azure database, or an Azure table. Scott Hanselman posted about how to use the System.Web.Providers NuGet package to handle this, and gave sample configuration. For some reason, while the membership, roles and profiles parts of this worked just fine it refused to set up the relevant Sessions table as was expected – firing up the app lead to a yellow screen of death with an error:
Invalid object name ‘dbo.Sessions’.
After wasting a bit of time figuring out why it wasn’t creating the table, I resorted to letting it create the table against my local SQL Express instance (which worked without incident) then scripting directly to the SQL Azure instance:
CREATE TABLE [dbo].[Sessions]( [SessionId] [nvarchar](88) NOT NULL, [Created] [datetime] NOT NULL, [Expires] [datetime] NOT NULL, [LockDate] [datetime] NOT NULL, [LockCookie] [int] NOT NULL, [Locked] [bit] NOT NULL, [SessionItem] [image] NULL, [Flags] [int] NOT NULL, [Timeout] [int] NOT NULL, PRIMARY KEY CLUSTERED ( [SessionId] ASC )) GO
Huzzah! Working sessions. The only caveat was that SQL Azure has limitations on the kinds of DDL operations you can use, so when you script from your local instance you’ll find the CREATE TABLE from above also has:
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
tagged onto the end – omitting that’ll get it scripting into Azure just fine.
I’ve finally deployed a preliminary version of the Tasting Tracker for this year’s Whisky Fringe. While deeply unfinished, and so far only populated with test data, a bunch of stuff’s already implemented:
Yet to go:
What’s deployed is there only for interest, will change without notice and contains only test data (i.e. last year’s whisky list) for now.
I had an MVC4 application (the new Whisky Fringe Tasting Tracker site) for which forms authentication’s persistent cookies worked fine when testing on my local machine but failed when deployed to my shared .NET host.
The symptom was pretty simple – you’d log in ticking the ‘remember me’ checkbox (which generates a persistent cookie on the client’s machine), could use the site normally but would find that the next day you were no longer logged in. In fact, leaving just 20 minutes or so between accesses to the site would be enough to see your login bumped.
That 20 minutes should have been a good clue – it’s about the same amount of time as the shared host’s app pool worker processes were recycling. With a bit of digging, what seemed to be happening was that in recycling the worker processes, my application was getting new validation and encryption keys, as at the machine.config level these were configured to auto-generate. With authentication cookie validation turned on, this meant that the keys used to sign and encrypt the cookie 20 minutes ago ain’t the same ones that were used to try to decrypt and validate it just now, so the provider kicks your login out.
The fix is to specify a machineKey element in your app’s web.config file under the <system.web> element, locking down a validation key and a decryption key to be used and opting you out of automatic key generation in the process. With this applied, logins will persist even over app pool recycles.
One caveat – if you use a tool such as this one to generate the keys for you, make sure that the ‘validation’ attribute that specifies the validation algorithm to use for tamper-proofing the cookies matches the default for the system as it was before if you’re using the System.Web.Providers libraries for authentication. Failure to do so will make it impossible for existing users to login… The default is ‘HMACSHA256’.
With a surname like O’Neill I’m used to breaking systems that need me to enter my name. Apostrophes are used in SQL commands and many programming languages to enclose string or character literals – as such, the appearance of one when not expected can mark the end of a string before the programmer of the system actually intended, leading to faults and security bugs such as SQL injection attacks.
I can’t, for example, use Asda online shopping because attempting to pay with a debit or credit card using my surname results in the site throwing a wobbler on account of the apostrophe – it claims it to be an ‘invalid character’. Small business owners’ websites will frequently bail out in a way suggesting an attack vector when I have to enter my name – they’ll see a premature end-of-string and try to parse Neill as a SQL command. Even Twitter’s not immune – view my Twitter feed and you’ll see the HTML entity code for an apostrophe in the title of the page instead of the character itself.
This week I’ve encountered three more examples that I document purely so that someone else encountering frankly weird behaviour in their systems will feel less alone:
With Unicode ubiquitous and an assumption even down to the level of DNS that the world is small enough for internationalisation to be a fundamental component of an application, how on earth can a lonely apostrophe cause such havoc?
Proving that you are who you say you are can be hard at the best of times – my local GP requires two forms of identification to sign up, signing up for a bank account requires a passport or birth certificate and I’ve even had jobs where I’ve needed to supply my passport for photocopying before they’d take me on.
When you take your interactions online the problem becomes substantially more complicated, as there aren’t many brokers of identity information that’re trusted enough to replace physically viewing a passport or birth certificate. This results in a worst-of-both-worlds situation, where you complete half of your interaction with a third-party online and are then forced offline to supply the relevant credentials before firing things off at the mercy of the postal service.
There are solutions. Providers exist who will – once you’ve proven who you are to them physically in a Post Office or similar (and with associated identity documentation) – verify your identity to third-parties on your request. However, they suffer a number of issues:
miiCard is an Edinburgh-based start-up that’s hoping to change that. Instead of providing physical verification of your identity you instead utilise your existing online trust relationships with people like financial providers – you then share your verified identity with as few or many people as you like. By basing their identity assurance on something that required physical proof of identity in the first place (e.g. a bank account), that level of assurance can then be passed on and consumed. Even better – because the sources of that identity are online, your identity can be validated and re-validated whenever is necessary – it doesn’t become stale over time.
Proving who you are in such a way will allow you to complete split online-offline interactions purely online. It’ll also let you rest assured that the person who just contacted you on LinkedIn, who you’re buying from an auction site or who you just received a sales inquiry from is both a real-life person (and not a sock-puppet) and that they are who they claim to be.
It’s so compelling an idea that I’ve signed up for one and validated my identity. And then I’ve gone one step further and joined them as a software developer. I’m delighted to be part of the team, and know that there are some exciting ways to both validate and consume identity as part of a very pacy roadmap.
Last year I put together a quick web app to let me keep track of which whiskies I’d liked and disliked at the Royal Mile Whiskies Whisky Fringe 2011. A few friends used it, some found it more useful than others and that was that.
That was hacked together in PHP against a MySQL database, neither of which are my bread-and-butter. While flexible, I’m a .NET developer so when it started heading towards the time to build it again this year I went with a different stack:
I’ve loftier goals this year in the hope that others will find it useful. Last year it was to be little more than an aide memoire for the tipsy sampler though I managed to extract some fun statistics from it. This year I want to:
Functionally it’ll be broadly the same as last year – navigable dram lists and big finger-friendly buttons to hit when you try something out, nice and simple. Hopefully there’ll be a demonstrator site up soon enough, so suggestions as to what it should include would be welcomed at whisky@pablissimo.com.
Over the next few weeks as things start coming together I’ll hopefully have time to document some of the development work.