Azure Mobile Services HTML Client - This Changes Everything

I started building a web app for tracking my budget. It stores data in a SQL database, so I thought I'd try running it in Microsoft's Azure cloud system. Azure has a web hosting system that is very easy to use and a SQL database system (among many, many other things). The architecture looked like this:

Website and database

My first build of the site didn't use authorization and the data in the database couldn't be associated with a particular user. Before .NET 4.0 the out-of-the-box web authentication system was web forms. This meant storing user IDs and passwords in a database and forcing users to create yet another set of credentials on your site.

However, the ASP.NET MVC 4 template leveraged the use of claims-based authentication in .NET 4 and gave you an easy way to let users log in with third party IDs. The included ones are Google, Facebook, Twitter and Microsoft IDs (aka Live IDs). This sounded good to me, so I started down the path of moving my app to the new MVC 4 template. I could log in with my Google ID and received a unique identifier with which to associate my data.  The architecture was now:

Website, database and authorization systems

Shortly after that, I learned about Azure Mobile Services. This is a very handy system that can handle authentication with the same systems as the MVC 4 template, but for smart phones and Windows 8 Store apps. It also integrates with an Azure SQL database. My intention was to use it to create Windows 8 and Windows Phone 7 and 8 clients for my app.

I found out that, while it is technically possible to use an existing database with Azure Mobile Services, there are some hoops through which you must jump to make them talk. I wasn't too far along with my development so I thought it easier to allow the Mobile Service creation wizard to create the database. Soon, I had a little dummy Windows 8 app that could authenticate with my Google ID, and again was receiving a unique ID.

Only, it wasn't the same as the ID I received in the web app. This was a problem, because it meant I couldn't look up data for the same person using their Google ID in both apps. My architecture now looked like this:

Website, database, mobile services and 2 authorization systems

The cause of the ID mismatch was that the MVC4 template uses Google's OpenID authentication system, while Mobile Services uses Google's OAuth2 system. I had no reliable way of associating one with the other. A little searching around found other people encountering the same problem, and eventually a NuGet package that lets you use Google's OAuth2 system in an MVC 4 web app.

The NuGet package would let me find people's data no matter which app they used. Hardly ideal, though, because it meant extra code just to do the same thing. I suspected there would be other differences between the MVC 4 template's authentication providers and Mobile Services' providers.

My ideal architecture is:

The idea is that the Mobile Service would handle all authorization, and then access a REST endpoint in the website, rather than going directly to the database. This means that the web app would somehow authenticate against and get data from the Mobile Service, just like the other apps.

Besides the centralization of the authorization mechanism, it would also put all the business logic on the server. The Windows 8 and phone apps would be strictly for displaying data. That way any bug fixes to business logic would be web-based, meaning immediate and global. If the logic lived in the Windows and phone apps then I'd have to update them individually, and wait for them to be approved and delivered to people.

It seemed like a pipe dream, because I couldn't find any easily understandable information about how to authenticate against a Mobile Service. Until a few days ago, when I found out that the Mobile Services group published an example HTML client, along with a JavaScript library that can authenticate and get data.

This changes everything.

This is the final piece of the puzzle that will let me create a web app that gets data through Azure Mobile Services.

Actually, there is one change to the architecture needed to keep the REST interface accessible to only the Mobile Service:

That extra User Auth box is an Azure Access Control Service service ID that the Mobile Service will use to access the web service's REST service.

The First Bank of James

After listening to economics podcasts for the last couple of years, and recent poor customer experiences at several banks, I've decided to open my own Canadian bank.

Well, not really because I'm sure the cost due to red tape would dissuade all but the deepest pockets, and a bunch of my ideas are currently forbidden. I was mostly inspired by one about free banking in Scotland between 1716 and 1845. Free, as in, no regulation and no government to bail you out. So, my fantasy bank would:

• Not trade its stock publicly, unless additional conditions could be placed upon the board beyond maximizing shareholder value (I don't know if this is possible under Canadian law). Such conditions would include not buying or selling any securities outside stocks and bonds, and being able to say no to investments that don't fit our social conscience. And no selling of the bank to another bank in part or whole.
• Require all board members and insiders to hold at least 75% of each of their deposit (e.g chequing, savings), credit and investment values in the bank.
• Opt out of the Canadian Deposit Insurance Commission (is this possible?). If the bank fails, people may lose money, including board members. We will be motivated to not lose our and your money because there will be no backup plan. (CIDC guarantees that if a bank fails every deposit account will be paid out up to $100000. Want us risking the whole bank knowing customers will be bailed out?)
• Offer only index mutual funds. Canadian index, US index, international index, a couple of bond index funds, maybe a gold one. No one can beat the market consistently, so no one in my bank will try.
• Sell only our mutual funds through fee-only financial planners. That is, you'll pay our people a one time, hourly fee for financial advice. The reason you don't pay the planner at your current bank anything to set you up in mutual funds is because he or she gets paid by the funds your buy themselves. Also known as commission sales. This means that the cost of running the mutual finds will be greatly reduced. Those commission sales are paid for by the x% taken out of funds every year. Canada has the highest average fees of all industrial countries.
• Not be a member of the Mutual Fund Dealers Association (MFDA) (not possible under current laws). We'd go to real lengths to build you a portfolio appropriate to your needs and risk tolerance without being able to hide behind the protections of this group. No doing the MFDA minimum needed to survive a court case, because we'd be vulnerable to all legal action. This would also make buying mutual funds as easy as any internet purchase because we wouldn't be beholden to the MFDA's documentation rules. You'd need to jump through our hoops, which would align with your actual needs, but these would not involve filling out pages of generic forms. You
• Not be regulated by the provincial securities exchanges. Completely impossible, I know, but it would also make buying stocks, bonds and mutual funds as easy as a couch. Far less paperwork. The bank would be forced to perform its own due diligence on transactions, rather than the minimum requirements currently needed.
• Keep the external technological systems up to date in terms of technology and features. Phone apps, third party integration, a slick web interface, analysis tools inspired by the latest financial sites will all be standard. A modern look and feel replicated across the whole site, not just the "marketing", or non-personalized, site. We know you you are - no need to fill in blank paper forms. No PDFs allowed. No emails saying "if you are registered for web banking... if you have an investment account..." because we know whether you are/do or not. The goal is to gather any given bit of info once and only once.
• Maintain one, and only one, copy of your personal information, guarded by the leading edge in encryption, processes, ninjas, balrogs, whatever it takes. No physical copies allowed that could wander into the wilderness, like tapes. Backups would be handled over the internet, encrypted at the source. Business continuity would be a priority because of point 2 above.
• Be very conservative in its lending. Mortgages would require the traditional minimum 20% down. No Canadian Mortgage and Housing Commission (CMHC) insurance allowed for high ratio mortgages. Other lending would require very solid documentation and low risk levels. The board is risking most of its money on your loan, so will allow only the most solid investments.
• Not have call centers. You'd talk to people at the local branch on the phone who know you and your significant other and kids. This would be partly for the personal touch and a security measure.
• Structure all technological and business systems around the customer. No isolated stovepipe departments to make internal interactions harder.

One can dream.

Want First World Problems? Buy a New SSD

Buy a new solid state drive (SSD). In my case, a 128GB OCZ Vertex 4, which is well reviewed.

And then learn that it supports SATA 3 (the interface between the drive and the rest of the computer).

And then learn that your motherboard only supports SATA 2.

And then learn from Wikipedia that this should be backwards compatible, but with the SATA 2 speed. Accept this limitation.

And then, after an evening of experimenting, that your Gigabyte MA785GMT-UD2H motherboard won't see the new drive unless it's in IDE mode, which is the oldest, slowest mode available.

And then spend another evening googling, finding that:

• AMD (chip manufacturer) decided to rely on motherboard makers to do things right with the 785G chipset, rather than taking defensive steps themselves
• other people have had the same problem with similar Gigabyte 785G boards, and had to request BIOS updates through their support site

And then submit a support ticket for your 2 year old Gigabyte board about this issue.

And then visit a Tiger Direct store to get a SATA 3 controller add-on card, but find they are all out.

And then visit a Best Buy for the same thing, but find they have no clue what the hell you're talking about. Give them the part number from their website. Find out they don't have it in their stores.

And then wait a couple of business days with no action from Gigabyte.

And then decide that this is the first, last and only Gigabyte/AMD motherboard that you will ever buy. The next full system overhaul will involve an ASUS board and Intel everything else. In the meantime, order an ASUS M5A97 LE R2.0 motherboard that supports your current memory, CPU and SATA 3. This order is non-refundable, but is exchangeable for store credit from the very excellent TigerDirect.ca.

And then the next day find Gigabyte has responded to your support ticket with a new BIOS that makes the board see the new drive in SATA 2 mode.

And then wait a week for your new motherboard. Notice that Gigabyte hasn't posted the new BIOS on their website, implying the update is available only to those opening support tickets.

And then get most of the way swapping boards before realizing the new board doesn't have an old-style IDE connector for your DVD drive. Luckily you have your parents-in-law's old computer that has a DVD drive with a SATA connector that you can use. (The board also has no floppy drive connector, which is fine.)

Also order 2 different kits for mounting 2.5" SSDs in a 3.5" drive bay, both of which aren't drilled for the "old" style 3.5" drive screws. Realize that the mounting kit currently in the PC, which is drilled properly, can hold a second SSD.

Finally get everything connected and working. Feel no great satisfaction.

First world problems, to be sure. No one died, no one got sick or injured, no massive loss of property. But, does it have to be this hard?