Monthly Archives: April 2013

What’s In Your Wallet?

authentication, JSON, Windows 8, Windows Phone

UPDATE: Use http://openidtest.uninett.no/jwt instead. The Google link below is okay, but I really get annoyed with all the web traffic that occurs every time you hit any page belonging to Google. And, in this case, every time you test a token. Fiddler just clogs up with a ton of web sessions. Openidtest uses javascript within the page. And it works with any browser I’ve tried.

https://developers.google.com/commerce/wallet/digital/docs/jwtdecoder – for those times when you want to see what’s in your wallet…or…er…just decode a JWT (JSON Web Token)…any JWT…without having to wire up something for testing. For instance, I just threw a brand new blank Windows Phone 8 project into a solution. So far I’d only added a Live Sign In button and wanted to verify that the same UID is being generated from there as is from a Windows 8 app. I have a JWT decoder in my server-side code but still need to wire it up to the WP8 client. The server is expecting more info than just a JWT. You have to appreciate when major competitors – unwittingly or not – work together to help the little guy, yeah?

BTW, if you do sign in with the same Microsoft Account, the UID will be the same. Some more on JWTs related to that subject in an upcoming post.

UPDATE: The decoder doesn’t validate that the JWT is actually signed. This brings up an important point: JWTs are not encrypted. They are signed, but all that means is that the data hasn’t been altered in transit. If you’re going to work with JWTs then SSL is a must…or if you couldn’t (for whatever unfathomable reason) use SSL, some sort of public/private key encryption from client to server.

WinRT Raw Notifications and Suspended State

Visual Studio, WinRT

Something to note if your WinRT app uses raw notifications. They will be received by the device but not by the app if it is suspended. This makes sense but may not be obvious sometimes because swiping the left side of the screen may still show the app on the stack. So it will appear to still be active, even if not in the foreground. The exception, of course, is if your app is registered to use a background service and the user has decided your app is important enough to be one of the “Lucky Seven” (those apps given permission to use the Lock Screen). I wouldn’t count on it.

It took me a bit to spot this behavior. I was noticing an instance of the app on one machine would sometimes receive raw notifications if it wasn’t in the foreground, sometimes not. The “not” occurred after a decent time lapse, which was the first clue. My server notification logs were no help because only client devices that were off or logged out of would return a status other than OK from the notification service. As mentioned, if the device is on and logged into, the notification service will successfully send the message. This makes sense. All it cares about is reaching the client at the specified URI. It’s up to the client to do what it wants with the received message. In this case, it appears the WinRT designers elected not to wake up an inactive app. Not a problem, but something to be aware of.

In my case, raw notifications are used to tell the app to update its data. It just means that the same sort of behavior also has to be triggered by resuming from a suspended state. BTW, for those who don’t know, you can suspend an app from within Visual Studio while debugging. To enable this, select TOOLS > Customize from the Visual Studio menu. Check the box next to “Debug Location”. If you have a solution with multiple projects you may have to select the right WinRT project from the Process pull-down menu.