Google & MVPs

For those who don't know who Jon Skeet is, he is an excellent contributor to the C# community, through his daily answering of questions on Stack Overflow, to his many excellent articles and books. Jon recently posted that his employer has asked him to turn down the MVP reward for this year.

What employer wouldn't want their employees to be recognized as community leaders in Microsoft Technologies? Google for one, as they are Jon's current employer. Jon won't comment on why this is so it leaves us to speculate what the reasons might be. Even if there is a sensible reason for this the silence lets myself feel that this is due to the competition between the two companies. That has definitely soured my opinion about Google and its Management team.

Just trust me!!

Today I was working with my intern, we are using DotNetNuke to run a marketing site so that our product team can go in and tweak some things. We have custom workflow in there, and a requirement that we want to save the results of the workflow into our own table so we can report on it latter.

The workflow component has some facilities to do this, so he creates a table and a stored proc, and gives it a shot. He is instantly greated with a lovely error in the front end Invalid Syntax Near xyz

I tell him that's not good, as it indicates a potential for a Sql injection attack. Fast forward three hours, and he is arguing with me that its safe, that it can't be injected, and demands I prove to him it can be done.

Not wanting to take the time or effort to figure out the magic sequence, as this isn't something I do everyday (Contrary to popular belief, I don't sit around trying to hack). I tell him to trust me, parsing errors are easy to inject into. He doesn't buy it, and I can see he is going to be stubborn until I prove him wrong.

Fast forward ten minutes, and I found that injecting with this forms component was as simple as entering a string like the following for the last field:

injectComing' select * from aspnet_users--

Watching with profiler, we quickly saw three key events. First was a Batch Starting which looked something like this:

exec myProc '','','','injectComing' select*from aspnet_users--';

Second was SQL Stmt Starting Event:

exec myProc '','','','injectComing'

Third was another Sql Stmt Starting Event:

select*from aspnet_users--';

Needless to say now he is working on a costume module so we can execute the Sql as a parameterized query and avoid all this ass ache. Moral of the story? While you shouldn't always trust everyone, you should trust your boss who has 10 more years of experience. And if you don't you try and prove him wrong, don't demand your boss to prove himself.


Gahh Interns!

Responsability of Third Party Control & Blacklists

My intern just sent me a screen shot of a CAPTCHA from a site we are working. The CAPTCHA is generated by a third party control which we have no control over.

If you are a developer of third party controls which are sold to professional companies please take the effort to implement a blacklist of letter sequences that should not be allowed in CAPTCHAs. What are the odds of this happening probally preety small but had we lost a sale because of this....

Telerik Gives Back to the Community

While using StackOverflow a great site for asking questions to problems software developers face, I noticed an advertisment from Telerik. They have decided to give any SO user who has over 10,000 reputation points a free developers license to their control suite.

This is great to see a company see the value a site such as Stackoverflow provides, and to provide some recognition to the people who spend their time helping others by answering questions. Thanks again!

Duration in RPC:Completed is Misleading

I discovered something today while troubleshooting a long running query today. We have a specific dialog in our application which in a specific case takes 60 seconds to open up. I fire up SQL Profiler and click run just to see the standard events and verify if this a DB issue or not.

I find that there is a specific query which does take 60 seconds to run according to the RPC:Completed event (We are using SQL Server 2005). So I pull that query out and run it inside of SSMS, it completes in under a second. These are the issues I hate having to troubleshoot. So the first thing was to rule out our web application, so I create a little .net windows form app and I basically run this:

sqlCmd.Connection.Open();

using (var reader = sqlCmd.ExecuteReader())

{

    int i = 0;

    while (reader.Read())

    {

        i++;

    }

    MessageBox.Show(i.ToString());

}

The query runs fine no issue. Now we are actually using nHibernate so I wanted to simulate us processing the result set. I add a small Thread.Sleep(5) (my result set has 1500 items in it so a small sleep duration is plenty). I run the query and wait about eight seconds.

Then I go and look at SQL Profiler RPC:Completed (And Stmt:Completed events). The duration for the events is 8 seconds. Now I am asking myself if I opened a ticket with Microsoft burned a support incident for an nHibernate issue or not.

The moral of the story? Well don't always trust what you think the tool is measuring. And if your interested, when I ran my queries loading the entities through nHibernate with the windows form, the query again completed extremly fast. So I am still hunting this one down.

Update

I found and resolved the issue. It wasn't an issue with SQL but a configuration issue which caused the system to try and log to an invalid file thousands of times which slowed the system down.

This is very eye-opening as one of my fundamental assumptions about SQL Profiler and how to interpret the results has been crushed.