Feeds:
Posts
Comments

A pain to write, and my google-fu was not strong enough to find someone who’d done it for me.

The class allows you to encode / decode 4, 9 or 17 bit (for example) integers to and from a byte[]. I needed it to store some binary keys in a database that are made up of multiple keys, in my case the difference between a byte[] storing 9 bit integers and one storing 16/32 bit integers would be very costly. If you are doing something similar in MSSQL watch out for 0 byte right truncation (reserve the value of 0 perhaps). This version of the code supports 1 though 31 bit unsigned integers, it could easily be extended beyond this if needed.

Code available here on code project (click on tips).

Glad to see it moving along, hopefully the browser support for it will continue to solidify. These standards were a key part of delivering some json web services and making them securely available in the cloud. Very diligent of them to mention me for a meager contribution to the specification.

http://www.w3.org/TR/cors/ (W3C Candidate Recommendation 29 January 2013)

Your password managers are all good products, but suffer from one key flaw, if my PC is compromised, I’m better off without them.

In some cases I’d be lucky, and the thieves would only manage to capture a “master password” as I enter it to access one of my passwords. In the worst case the thieves make off with my entire password database and destroy my digital life.

There is potentially a simple solution to this problem though. Simply put I can trust my phone more than I can trust any of my PCs. When I need a password on my PC, my phone is normally sitting next to me. I would like my password manager (on my PC) not to actually have access to the passwords, unless I authorise that access on my phone, and even then it would only have access to one particular password for a short period of time.

It may sound clumsy, but sliding a push notification on my iPhone home screen and entering my phone PIN would be a whole lot easier than typing in a 30 character master password!

Yours in anticipation ;-/

Useful if your application needs to limit access based on IP address.

The key to solving the problem is the BigInteger class (System.Numerics.BigInteger), an integer of unbounded size. Once you convert your IP addresses (IPv6 or IPv4) to BigIntegers they can be quickly compared (don’t forget about endianess). The .net class IPAddress (System.Net.IPAddress) does the heavy lifting of parsing the addresses from a string for you. One thing to make note of is that you should compare like for like, don’t test an IPv4 address against an IPv6 address range.

There is a growing trend in applications being built in HTML5 where the screens are built in HTML5/CSS3 and hooked up to data via services with JavaScript. From Bing to Amazon Kindle Cloud Reader and Angry Birds, the big boys are moving steadily in this direction for more than just their websites. Let’s not forget the much hypothesised pending PDC announcement regarding Windows8 and HTML5 (see buildwindows.com).

For a small inkling of what HTML5 can mean, I strongly recommend you check-out slides.html5rocks.com (in google chrome or safari).

The days of screens in HTML applications being pages generated by servers containing screen layout mark-up and data are nearly over, whether it’s your google/bing search results or social networking news feed, all this is happening over JSON web services.

While the UI control industry is still some way away from having polished products to support building these applications cheaply, there have been some interesting recent developments.

The move to HTML5 based UI brings with it some great new opportunities, and of course, just as many risks and challenges.

SOA UI Controls from ComponentArt and Telerik

Recently two of the biggest control vendors for asp.net web app controls have added some interesting client side service/data-binding. While neither of these quite gets to the full vision or potential of HTML5 UI, they certainly make some very positive steps in the right direction.

1) ComponentArt have released a suite of Silverlight and ASP.net “AJAX” (JSON) controls that data bind on the client side. You build and publish your service interfaces once, then connect Silverlight and HTML based controls to them. The ComponentArt implementation is somewhat limited in the services it can bind to, services need to be defined in specific ways for them to be useable without some custom client side code.

DEMO: http://soaui.componentart.com/ajax/datagridmessagebrowser/

2) Telerik have added declarative client side data binding support for JSONP / ODATA (http://odata.org), you simply point your controls at ODATA data sources and configure the data-binding. The resulting HTML and javascript produced by Telerik takes care of the rest, pagination, filtering etc. etc. all happen client side.

DEMO: http://demos.telerik.com/aspnet-ajax/grid/examples/clientbinding/defaultcs.aspx

One of the main shortcomings of this service based approach over HTTP is that there is inherently a two connection per client limit. For simply paging through a grid of data, per the examples above, this will not pose a problem, but as your interface becomes more advanced this two connection limit will really start to bite (as many developing in Silverlight have found).

WebSockets

Why should we care about WebSockets? Put simply, it’s all about throughput! Web-sockets authenticate once at the start, are full duplex and support message based communications; this means a significant increase in throughput is possible.

HTML5 SOA MVVM MVP

* Q – Query / Request, P – Processing / Latency, R – Response

Message based services over WebSockets truly have transformational potential for HTML5 UI web application development. The key of this transformational possibility, is that message based transport of client-server communication will support modern UI software design patterns such as MVP and MVVM directly in the browser.

Web sockets do come with hidden dangers for application developers though; there is a risk of turning back the clock, moving away from stateless web services, and bringing in a new era of unnecessarily long running client-server connections. With the right patterns and practices these pitfalls can be avoided of course. Web sockets could be kept open only for short bursts of communication, meaning services can still be stateless, web farms can still manage load on a per connection basis and users wouldn’t be tied to specific hosts for long periods. Hopefully as UI control vendors leverage this technology we will see patterns, practices and frameworks for the architecturally sound use of web sockets.

WebSockets are still somewhat a way off for most desktop targeted browser based applications (due to lack of IE support). Applications targeted at apple/android tablets/phones can certainly make use of this technology today.

Adapting Existing Services

Don’t panic! This does not mean throwing away your current web services, the ramifications of WebSockets on existing JSON web services are not as drastic as you might expect. In fact, the SOA design principles on current services should be maintained and continue to be used for new services.

All your existing services can easily be re-published via simple message bus endpoints. Silverlight and JSON web services are already inherently asynchronous so it is not a big change for your existing client or server side code. The message bus is just another type of transport for calling your existing services.

Your client would simply send its “request” messages to a message bus endpoint with a wrapper containing service destination information. In SOAP, the SOAP headers already contain all the information needed to achieve this. For JSON services, a simple wrapper object containing an endpoint URI and the request message body is all that is needed.

JSON Message Bus – Under the Covers

Looking at the specifics of this in JSON it is easy to see this is not a big leap (this sample is simplified to show a single http connection instead of two which would sometimes be possible, please note protocol details have also been simplified).

Regular JSON Web Service – Standard HTTP Request / Response Web Services

Request Response
POST /app/service1/json/method1

Host: hostname.example.com

Authentication-Headers: Values

Request-Headers: Various-values

{“parameter”:3.45}

HTTP 1.1 200 OK

Response-Headers: Various-values

{“result”:6.78}

POST /app/service1/json/method1

Host: hostname.example.com

Authentication-Headers: Values

Request-Headers: Various-values

{“parameter”:3.45}

HTTP 1.1 200 OK

Response-Headers: Various-values

{“result”:6.78}

POST /app/service1/json/method1

Host: hostname.example.com

Authentication-Headers: Values

Request-Headers: Various-values

{“parameter”:3.45}

HTTP 1.1 200 OK

Response-Headers: Various-values

{“result”:6.78}

JSON Message Bus Service – Full Duplex Two Way Stream of Messages

Request / Client-to-Server Stream Response / Server-to-Client Stream
CONNECT /app/MessageBus/json

Host: hostname.example.com

Authentication-Headers: Values

Request-Headers: Various-values

HTTP 1.1 200 OK

Response-Headers: Various-values

{“service”:”service1/json/method1″,

“body”:{“parameter”:3.45}
}

{“service”:”service1/json/method1″,
“body”: {“parameter”:3.45}
}

{“service”:”service1/json/method1″,

“body”: {“parameter”:3.45}

}

{“service”:”service1/json/method1″,
“body”: {“result”:6.78}
}

{“service”:”service1/json/method1″,

“body”: {“result”:6.78}

}

{“service”:”service1/json/method1″,

“body”: {“result”:6.78}

}

I’ve written some nice flexible standards based implementations of various Base32 and Base64 encoding/decoding methods. These are designed to encode binary data to plain text, and decode the resulting text back to the original binary. Useful when you need to transfer binary data through technologies that only support text (such as including binary security tokens in URLs).

The code is available up on codeproject.com

Base32Url encodes with only the characters A to Z and 2 to 7. No hyphens, underscores, pluses, slashes or equals are used, making it usable as a URL token in almost all circumstances. Base32Url also supports custom alphabets. A custom case sensitive alphabet with only consonant (non vowel) characters can be used to ensure your tokens do not contain accidental profanities. The following is an example that avoids vowels, the letter L and has no numeric characters: BCDFGHKMNPQRSTVWXYZbcdfghkmnpqrs.

Base64Url is more compact than Base32Url and it is almost always usable as a URL token or file-name. The only non alpha-numeric characters Base64Url contains are the hyphen (-) and underscore (_) characters, neither of these need further encoding for use in URLs or file-names.

Base32Url (Encoder / Decoder)

The default mode for the Base32 encoder/decoder is Base32Url. This uses the standard Base32 alphabet encoding but omits padding characters and is case insensitive.
Supports standard Base32 with padding characters (=) per Base32 from RFC 4648.
Supports the Base32 extension / alternate alphabet z-base-32

Base64Url (Encoder / Decoder)

Based on the standard .net Base64 encoder
Uses the URL-Safe alternative Base64 alphabet from RFC 4648
This is not the same as Microsoft’s HttpServerUtility.UrlTokenEncode.

Further Information and Usage

There are other implementations of base32 encoding out there but I feel the code of this base32 implementation is much simpler (far less code involved in the bit shifting calculations).

The base64 implementation I have here is a little hackish, but a far better option than the one you get from Microsoft.

The result you get from HttpServerUtility.UrlTokenEncode is essentially base64url, but instead of truncating the padding, they append a digit (of 0, 1 or 2) indicating the number of padding characters removed.

Usage:

Base32Url.ToBase32String(Encoding.ASCII.GetBytes("Hello World!"));

JBSWY3DPEBLW64TMMQQQ

var b32 = new Base32Url(true); // Base32Url(bool usePadding)
b32.Encode(Encoding.ASCII.GetBytes("Hello World!"));

JBSWY3DPEBLW64TMMQQQ====

For more information about the standards involved please see rfc 4648 http://tools.ietf.org/html/rfc4648

Wikipedia also has good information. Please see http://en.wikipedia.org/wiki/Base32 and or http://en.wikipedia.org/wiki/Base64

// Get a double between 0.0 and 1.0 using a secure random number generator and the maximum fidelity of a double

var rndBytes = new byte[8];
using(var rng = RandomNumberGenerator.Create()) { rng.GetBytes(rndBytes) };
ulong uIntResult = BitConverter.ToUInt64(rndBytes, 0);
double doubleResult = (double)(uIntResult / (decimal)UInt64.MaxValue);

// Get a value between minValue and maxValue exlusive of max (like System.Random.Next(int minValue, int maxValue)

int minValue = x, maxValue = y;
int intresult = (int)Math.Min(Math.Max(Math.Round(minValue + (doubleResult * (maxValue – minValue)) – 0.5, 0, MidpointRounding.AwayFromZero), minValue), maxValue);


// Get a value between minValue and maxValue INCLUSIVE (UNLIKE like System.Random.Next)

int minValue = x, maxValue = y;
int intresult = (int)Math.Min(Math.Max(Math.Round(minValue + (doubleResult * ((maxValue+1) - minValue)) – 0.5, 0, MidpointRounding.AwayFromZero), minValue), maxValue);

Follow

Get every new post delivered to your Inbox.