December 2003 - Posts
Jeannine Gailey has a book on WSE2 to be released in January. Now that I have “touched” WSE (ummm - no, not mastered or conquered) I probably won't waste any more effort on WSE1.0 and move straight to the soon to be released WSE2.
The book: Understanding Web Services Specifications and WSE
Jeannine's MSDN article, Encrypting SOAP Messages Using Web Services Enhancements, was a big help to me.
I had to revisit this functionality today. I am pretty certain that I tested decrypting back to a dataset with the previous method I was using, but today it just wouldn't work at all. After a lot of reading, googling and research, I learned a lot about various methods of cryptography, yet I was still unable to solve my problem on my own. Finally I came upon a code sample (not in the first 4 searches, mind you!) and thought I better persist THAT here!! Here is the link. If for some reason that link goes away here's my particular (VB.Net) treatment of the code:
|
Public Sub encryptDS(ByVal ds As DataSet, ByVal filename As String)
Dim aCryptoStream As CryptoStream
Try
Dim aXmlTextWriter As XmlTextWriter
aXmlTextWriter = New XmlTextWriter(filename, Text.Encoding.UTF8)
Dim aUE As New Text.UnicodeEncoding
Dim keyBytes() As Byte = {......} 'your secret bytes go here
Dim RMCrypto As RijndaelManaged = New RijndaelManaged
aCryptoStream = New CryptoStream(aXmlTextWriter.BaseStream, RMCrypto.CreateEncryptor(keyBytes, keyBytes), CryptoStreamMode.Write)
ds.WriteXml(aCryptoStream)
Catch ex As Exception
...
Finally
aCryptoStream.Close()
End Try
End Sub
Public Sub DecryptDS(ByRef ds As DataSet, ByVal filename As String)
Dim aFileStream As New FileStream(filename, FileMode.Open)
Dim aStreamReader As StreamReader
Try
aStreamReader = New StreamReader(aFileStream)
Dim aUE As New Text.UnicodeEncoding
Dim keyBytes() As Byte = {....} ' your secret bytes go here
Dim RMCrypto As RijndaelManaged = New RijndaelManaged
Dim aCryptoStream As New CryptoStream(aFileStream, RMCrypto.CreateDecryptor(keyBytes, keyBytes), CryptoStreamMode.Read)
'Restore the data set
ds.ReadXml(aCryptoStream)
Catch exS As IOException
...
Catch ex As Exception
...
Finally
aStreamReader.Close()
aFileStream.Close()
End Try
End Sub |
Here are two things that I noticed about the blogger and metaweblog api's that were of interest that I have to look further into. First, the metaweblog passes up a combination of strings and structures. I want to experiment with passing structs to a webservice. In both blogger and metaweblog, one of the strings that are passed up is a password. I have to dig further into how these are working on the client end and on the server end because there must be something else happening on the client end to encrypt or do something to the password before just sending it up as a string, right?
Cool! I have given the dry run of BLInk! to two people. One of them is Peter Rysavy from Tabula PC. Here is his first post.
Holy moly! That was hard work. I have never spent any time with the blogging APIs (blogger and metaweblog) and needed to at least push a post out from BLInk!. I wanted to make sure I could do this against dasBlog and dotText (from which so many blog sites are now derived). With help from :
I was able to scrap together some functioning code (in C# no less!!!!!) to successfully post test posts to both my dasBlog blog and my dotText blog.
Now I have to take those tests, tighten them up (eg: passwords, urls, etc are currently hardcoded) and wrap them into BLInk!.
My intention is not to build a full-fledged blogging tool (get posts, edit posts, etc) because the real purpose was to work out some concepts for blogging with ink. But I think pushing up a post that is created in ink is pretty necessary. From there, the user can go into there regular interface to edit, etc.
Just got word that I will be speaking at DevTeach again in 2004 (Montreal, June 19-22). This is a great conference and Rob Howard and Scott Guthrie will be doing the keynote. It is only a 2 hour drive from home, so I like that a lot too. Montreal is beautiful. The conference is very inexpensive even before you convert to US$ and it is partially over the weekend so that it doesn't conflict with work. Definitely check this one out!
I will be doing the “What's new in Whidbey Base Class Library” talk that I am slated to do in February in Boston at EdgeEast 2004 as well as a talk on tablet pc development. The tablet talk will not be about how to manipulate ink, but about the many design and implementation considerations that need to be taken into account that are very different than anything we have done before. I have been through this process in working with a corporate data entry application that will be used on Tablets. YOu can find a lot of posts about that here as well as a really nice summary of them by Peter Rysavy (TabulaPC) here.
I must pass along this post by Don Kiely on a new book that Kathleen Dollard has just completed for APress! - Code Generation in Microsoft .NET.
Don says, “I guarantee that this will be the hardest book you read in 2004, but also that it will be the single most important book for making you as productive as you can be as a .NET or SQL Server programmer.”
Don and Kathleen are both people who I absolutely listen to when it comes to programming. Read more here...
I also want to share Kathleen's bio for those of you who may not be familiar wtih her - which means you don't read Visual Studio Magazine - where she has a gazillion articles! Kathleen is also speaking at Visual Studio Connections in April. I am always astonished when people say “Kathleen Who?“
Kathleen Dollard has been involved in the computer industry for a long time. She started (she claims) by experimenting with programming in junior high. After graduate work, she worked with the computer group at Texaco Research writing Fortran, and helped usher in the age of PCs doing Lotus 123 macros. After working with 4GLs and Clipper, Dollard became an Independent Consultant, ultimately moving to Visual Basic when it became clear that Computer Associates would not release the Windows version of Clipper.
Dollard is well-known for her participation over the last 15 years with on-line communities, including BBSs, Compuserve, Fawcette, DevX, and Microsoft public newsgroups. She has been recognized in some form for her online work since 1994 and a Microsoft MVP since 1998. Dollard is also active in the real world communities of user groups – most recently with the Denver Visual Studio User Group and the Northern Colorado .NET SIG startup. A well-known writer and speaker, she is currently doing pioneering work in code generation using .NET and XSLT.
I just had a thought about what I was working on yesterday with encrypting data that is passed back to a client in a SOAP response. I was using examples from two sources. In those samples, there was a key created in the webservice for encrypting. That same key was added into the client app in order to unlock the encrypted data. I used the sample “to a T”, including the example key. If I didn't change it, that means that anyone who read the article could create a client that uses the same key and have access to my data. Not really, because the web service also requires authentication... but you get the point, right? It's kind of like the www.tempuri.com problem. Many people don't change that “placeholder” URI and leave the possibility (very slight as it may be) that someone accessing two separate web services with functions of the same name and the same namespace (”www.tempuri.com”) will have a definite conflict.
Anyway, time to go change my keys!
I just spent all day working with SOAP and encryption and xmldocuments. Don Box just wrote a post that addresses a misconception that I had when working on my solution today. “What caught my attention was the implication that there are somehow two classes of XML - documents and something else.” Because I was dealing with SOAP I thought I had to send a “real” xmldocument, not whatever xml is created magically when you send a dataset from a webservice. So I converted my dataset to an xmldocument object, sent that back to my client then took the resulting xmlNode, converted back to an xmldoc and then back to a dataset.
Another thing I wanted to point out about his post was that it addressed my little nit with the fact that the xmldoc is transformed into an xmlNode somewhere in the pipe. In his post, Don says that “it's exceedingly tricky for a SOAP envelope to contain an XML Document due to the problems of embedding XML inside of XML (embedded DOCTYPE, ID collisions, non-nesting CDATA sections, etc.).” OK, I can live with the transformation!
So, if you have missed his post, definitely read it if you are not 100% solid on SOAP and would like some clarity.
Well! That was educational!
I now have a web service that grabs a dataset of super-secret information from sql server, converts it to an xmldocument and returns it to my client as the body of an encypted Soap message. It's possible to encrypt different pieces of the soap message. And I had to deal with that p.i.a. transformation of an xmldoc to an xmlnode on it's way through the pipe. But at least I remembered that from the last time I encountered it!
My smart client retrieves this encrypted message (thanks to the last key of remembering to modify the web service proxy by replacing
Inherits System.Web.Services.Protocols.SoapHttpClientProtocol
with
Inherits Microsoft.Web.Services.WebServicesClientProtocol)
I was able to pull this part off with both Bill's book and Jeannine's article (see previous blog for details) close at hand.
Once I had the data safely in my client's clutches I still had another task which was to persist the data for off-line use. Of course, if the data is sensitive enough to need to encrypt it on the way through the pipe, I didn't want to just create a little xml file that could be opened up in notepad! So I used a System.Security.CryptoStream (and a little help from this article) to encrypt the data, yet again, along with WriteXML to persist the data. The application that needs the data offline then got a reverse engineering job to do a dataset readxml and decrypt the data.
Phew! I am whooped. Now on to WSE2 where I have been promised I'll be hitting my head wondering why I wasted all of that time with this WSE solution. Though the true answer is that I needed to use it in production and the WSE2 tech preview is “not licensed for production use“. That's why.
More Posts
Next page »