I think it would be really cool if the map providers would support a nicer REST addressing scheme for things like countries, states, counties, cities, etc… all of that data is already hierarchical in nature anyway and maps well to a RESTful addressing scheme.

I tried out Google Maps, MapQuest and MapPoint and got very polite error messages.

Instead of dealing with a specific endpoint and a huge querystring+parameters like this:
http://www.mapquest.com/maps/map.adp?formtype=address&country=US&popflag=0&latitude=&longitude=&name=&phone=&level=&addtohistory=&cat=&address=&city=minneapoilis&state=mn&zipcode=

We could have:
http://www.mapquest.com/USA/Minnesota/Minneapolis

It sure would make their APIs more flexible/interchangeable…

Weather.com gets close with this effort: http://www.weather.com/weather/local/USMN0503?from=search_city J

cheers

jk

JSON is goodness for the browser, but I find it harder to read than XML (maybe I'm just used to the angle brackets??). I constantly find myself grabbing my JSON string out of the Firebug Console, pasting it into Visual Notepad ++ 9000 .NET™ (a.k.a. notepad.exe) and trying to visually parse it.

With the help of "The Google", I ran across a nice tool called JSON Viewer on CodePlex which does a great job of formatting JSON into something more readable. JSON Viewer comes in 3 flavors; standalone exe, vs.net visualizer and a plugin for Fiddler.

Now I can save my brain cycles for solving problems instead of parsing JSON J

jk

I've been catching up on some of the old DotNetRocks shows that I missed.  Yesterday I was listening to show #167 - Security Update with Patrick Hynds and heard Mr. Hynds explain a security policy they have in place regarding usernames/passwords.

"But we’ve added to that policy that any password user name combination that they use in the office belongs to the company and they can't use it anywhere else under penalty of being terminated." and "...I don’t want my corner hardware store for you to login and win a new hammer by giving them your user name your password from the network and then your company email address because now they have a recipe for logging in."

It got me to thinking about how many logins we all have and if you can hack one site and get a username/password combination for one user, how many other sites will it work on?  MSN, Amazon, Ebay, banks, corporate network....the list goes on.  One additional quote from Mr. Hynds is "the enemy of security is convenience".  Sure, it is very convenient to have only set of credentials to remember, but that is not a secure solution.

A couple of risk-mitigation strategies for this are:
1.  Come up with some kind of heuristic to append, prepend or insert into the middle of your password on a per site basis.  e.g. maybe for amazon use a password that takes the 1st and 4th letters and puts them in your password someplace.

2.  Use a password manager program and have a cryptographically significant (strong) password per site.  I personally use PasswordSafe (Bruce Schneier) and have friends who use PasswordMinder (Keith Brown).  The downside of this is that I don't know any of my passwords, so if i don't have my password manager program with me (thumbdrives work well for this), I'm out of luck, but at least it is secure!

3.  Wait for the internet to embrace CardSpace :)

I would personally like to see the concept that companies own the credentials to their systems make its way into every corporate employee handbook.  It is a sound security principle IMHO.  It will change the way I use passwords!

be safe!

jk

The other day I was helping one of the new developers on our project get the code up and running (ASP.NET 2.0 project). When she brought up the web site in the browser, IIS kept returning the terse error message:

"The system cannot find the file specified"

I checked the IIS log and saw it was returning HTTP 404 (File not found), tried all the common tricks of clearning the download cache, deleting the temporary ASP.NET files, run aspnet_regiis.exe, checked folder ACLs…you get the idea! While poking around the %windir%\system32\inetsrv folder structure, I noticed that URLScan had been installed. This is of course a good security practice, but it gave the hint necessary to fix the problem. If you go to http://www.microsoft.com/technet/security/tools/urlscan.mspx and look at the urlscan.ini settings, the AllowDotInPath option was set to 0 (false). Per the documentation:

AllowDotInPath to 0 will cause UrlScan to reject any request where the file extension is ambiguous due to a dot-in-path condition.

Of course, our virtual directory had dots in it! Changing this setting to 1, and running IISRESET made everything right again.

Thankfully URLScan has a log file as well which I was able to see this request getting rejected on. I was surprised that there were few posts on this, so hopefully someone else finds this post useful and it saves another developer some valuable time!

jk