Make your Windows 7 a little bit safer

Virus scanners and firewalls are like vitamins, they help you stay healthier but they don’t prevent you from getting sick. This other day I found the Antivirus virus rampaging on my laptop. Vulnerabilities in browser add-ins is the most common reason for viruses to get on your computer.  In my case there where suspicious files both in the Java and browser cache.

After removing the troublemaker with the scanner I had and running some online scanners just to make sure, I did what I should have done a long time ago to make my Windows a little bit safer:

  • First a made a separate admin account and removed the rights from my standard account. Windows will now prompt me for the admin password when necessary. Experts claim 80% of the know viruses will be stopped just by doing this. I had done it on my XP (never had a virus scanner on that old computer) but forgot about it when I upgraded.
  • I updated my Java to the latest version and then I disabled Java both from the Java console and the browsers. I also disabled the Java cache just to be sure. Best option would of course be to just remove the whole thing but I was not sure if I would need it later.
  • Then I installed Chrome as it’s claimed to be the safest browser and set it as default.
  • As a final touch I disabled the JavaScript support from my PDF viewer and disabled the Chrome internal one has I could not find any option to do the same there. I then used some safe PDF scripting examples available on the internet to test my configuration.
Advertisements

JDBC: SQL Server and Named Instances

It’s been a while since I worked with Java and especially JDBC. Today I spent  a while trying to get the Oracle BI Publisher to connect to a SQL Server 2005 instance.

I found various examples of different ways to define the instance name in the connection string. After trying them all I could only conclude that defining the instance specific port number is the only way to get a connection established.

jdbc:hyperion:sqlserver://<server>:<port>;DatabaseName=<database>...

Reading the MSDN documentation a bit closer also revealed that it is the recommended way.

How do I know what the instance specific port number is? Easy!

  1. Fire Up the SQL Server Configuration Manager
  2. Expand the the SQL Server 2005 Network Configuration node
  3. Click on the instance you want
  4. Double click on the TCP/IP item
  5. Switch to the IP Addresses tab

The port number needed is the item named TCP Dynamic Ports.

Working Web Services

Working with web services in .NET (starting from 2.0) should be as easy as 1-2-3. Tools are provided for auto-generating code based on a WSDL. With .NET 3 Microsoft tries to direct every developer to use WCF for handling web services. Trying to get a Axis based Java web service to work proved to require some tricks.

I first generated a web service client (proxy) using the Add Service Reference tool in Visual Studio. This got a me a WCF based class to interact with the web service. All this was easy, but when I tried to call one of the remote methods, I was literally left with nothing (null).

As the diagnostic features (message tracking and tracing) of WCF really didn’t reveal anything usefull, I had to implement my own custom behavior with a message inspector to see what was really happening behind the secenes. This revealed that messages where sent and received, but the data did not get processed by the client. In the end, there wasn’t much else to do than to fall back and to make use of the older .NET web service handling technology (System.Web.Services).

Once again generating a client based on the WSDL was easy. And when I now tried calling the remote function I was returned with the data I expected. So, once again legacy technology prevailed when the newer failed.

As authentication (basic HTTP) is required by most we services I needed my client to support this. Normally this should only require to supply some valid credentials:

MatrixWebServicesServiceproxy = new MatrixWebServicesService();
proxy.PreAuthenticate =
true;
proxy.Credentials =
new NetworkCredential("user", "password");

But this did not do the trick. Using a TCP sniffer I was able to see that the “Authorized” HTTP header did not get sent to the server. After some research I came to the following conclution: The .NET client (this also applies to WCF) is designed to expect a “Unauthorized” HTTP error (401) from the server to respond to, without that the credentials are not sent. Also setting the PreAuthenticate property to true will only force the client to send the credentials with every message after this has first been required by the server. The problem with the Java web service was that is sent a “Internal Server Error” HTTP error (501) and a valid SOAP error when the authentication failed. So the credentials where never sent.

The only solution I found for this was to modify the generated client code and force it to send the credentials with every message. This can be done by overriding the clients GetWebRequest method. As the client is based on a bunch of partial classes, you only need to add your own with the following code to get things running:

public partial class SomeJavaWebServices : System.Web.Services.Protocols.SoapHttpClientProtocol {

protected override WebRequest GetWebRequest(Uri uri)
{
    HttpWebRequest request = (HttpWebRequest)base.GetWebRequest(uri);

    if (PreAuthenticate)
   
{

        NetworkCredential networkCredentials = Credentials.GetCredential(uri, “Basic”);
        if (networkCredentials != null)
        {

            byte[] credentialBuffer = new System.Text.UTF8Encoding().GetBytes(networkCredentials.UserName + “:” + networkCredentials.Password);

            request.Headers[“Authorization”] = “Basic “ + Convert.ToBase64String(credentialBuffer);
        }
        else
        {
            throw new ApplicationException(“No network credentials”);
        }
    }    return request;
}

 

}