September 2006 - Posts

I have recently published an article describing a WS-I18N implementation for WCF in "The Code Project" web site.

You can find the article and the source code here,

Enjoy it :)

Posted by cibrax | 3 comment(s)
Filed under: , , ,

In my opinion, the parameterized queries approach is always better than the traditional approach of joining string to build a dynamic SQL string.

This last one is susceptible to SQL injections attacks, and usually leads to data format problems, you have to worry about how to encode the parameter according to its type. (For instance, the string parameters must be enclosed with a single quote).

Unfortunately, each database vendor implements parameterized queries in different ways, and it took me sometime today to figure out how to use them in Oracle.

SQL server uses a named parameter approach, it does not matter the parameters order, but each parameter name requires a "@" prefix.

string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";

SqlCommand command = new SqlCommand(sql);

command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int));

command.Parameters["@CustomerId"].Value = 1;

Oracle uses a similar approach, but a different prefix, since it expects a ":" prefix.

string sql = "SELECT * FROM Customers WHERE CustomerId = :CustomerId";

OracleCommand command = new OracleCommand(sql);

command.Parameters.Add(new OracleParameter(":CustomerId", OracleType.Int32));

command.Parameters[":CustomerId"].Value = 1;

OleDB uses a sequential approach, in this case, the parameters order really matters. A parameter is identified by a character "?" in the SQL query.

string sql = "SELECT * FROM Customers WHERE CustomerId = ?";

OleDbCommand command = new OleDbCommand(sql);

command.Parameters.Add(new OleDbParameter("CustomerId", OleDbType.Integer));

command.Parameters["CustomerId"].Value = 1;


Any comment is welcome.


Posted by cibrax | 7 comment(s)
Filed under:

I updated the WS-Compression code to make it work with the latest WCF release.

You can download it from this location

Posted by cibrax | 6 comment(s)
Filed under: ,

I finally decided to publish a STS implementation for WCF.  (It is based on one of my previous posts, "Implementing a Secure token service with WCF")

I received a lot of mails from people asking me for a official version of that code, so here it is. I implemented this STS using latest WCF release (September CTP).

All the classes previously provided by WCF to parse the RST and RSTR messages have gone (They are now private). I am not sure about the reason to take that decision, but it certainly complicates everything.

Therefore, a person developing a STS (me) has only two options:

  1. Create different classes to parse those messages. In other words, duplicate all the code previously provided by WCF
  2. Copy that code from the Martin Gudgin's implementation (Same as 1, but it makes your life easier).  

The code also includes the following features:

  • A custom Security Token Manager to reuse the same SAML token instance in different WCF channels. You can find more information about this solution in this post. This token manager is quite simple, and it only shows how this task can be performed. 
  • Two configuration files showing different binding settings between the client, the service and the STS. The first one uses the standar wsFederationHttpBinding, and the last one uses customBindings.

Download the code from this location

Update, feedback received from the WCF team regarding the RST/RSTR classes:

"We made those classes internal during our RC1 milestone because this will enable us to align the product better for future version of the WS-Trust protocol without exposing user to the necessary changes. When doing this we have actually changed our samples that show our Federation feature so that those samples now contain source code of RST/RSTR library that you can use to parse RST and RSTR messages in your application. For example the FederationHttp binding sample in the Windows SDK in WCF samples collection contains source code for parsing RST/RSTR messages. It can be found in TechnologySamples\Basic\Binding\WS\FederationHttp directory. I hope this answers your concern. Thanks, --Jan" 


Posted by cibrax | 30 comment(s)
Filed under: ,
More Posts