December 4, 2013 at 9:10 AM
Over the past couple of weeks, I have been developing real time TCP/IP communication server. The server was implemented as .Net windows service. During the development phase, it was clear that the server will require configuration application, which I decided to implement as separate application. I wanted to avoid “desktop interaction” of my service. In addition, I wanted to experiment with IPC offered by .Net framework. I have considered following IPC mechanisms:
- Windows Communication Foundation;
- .NET Remoting;
- Named Pipes;
After some testing and experimentation, I decided to develop my own IPC mechanism. Below, you will find some reasoning behind the effort.
December 13, 2012 at 9:35 PM
Visual Studio has always been my favorite development tool. From debugging to deployment, Visual Studio provides a developer with various options to produce excellent software. However, just like any other tool, there are some limitations. One of those limitations is Visual Studio Web Server (Cassini), which is included with Visual Studio installation.
Visual Studio Web Server has limitation (for obvious reasons) to serve web pages that are accessed via localhost exclusivly. In the past, that has not been a problem because development and debugging was performed on local machine. However, since the iPhone revolution, developing iPhone/Android applications that require connectivity to a web server requires connectivity from devices, which cannot access VS Web Server. Using single machine for development was not possible.
In order to solve such issue, I had to make sure that all my web requests are initiated from localhost. To achieve that, I decided to write a server that would forward all web traffic to Visual Studio Web Server; sort of a “man-in-the-middle-attack”. Except that in this case, there is no “attack” but rather simple network traffic forwarding in both directions. Following port/address forwarding application was born:
Parameters are self explanatory:
- Listen to – port/IP that server is listening to;
- Forward to – port/IP that server is forwarding requests (this is port/address of Cassini Web Server – the address is always “localhost”);
- Replace “Host” value for all HTTP Requests – IIS Express is checking HTTP header values to determine where the request is coming from, so I implemented simple “host” header replacement to mimic access from local host;
To use it, simply set parameters and click on Start button. You should be able to access you Cassini web application from anywhere within you network.
Installation file includes source code. Source code is written in .NET using Visual Studio 2012, but it can be easily ported to .NET 2.0. I decide to publish source code for 2 reasons:
- The application is not extensively tested and there may be need for corrections. I will correct the code as I find issues, but so far it has been working well and it passed all tests. If you do make corrections, please let me know so that I can make those fixes on my end.
- The application is good example of .NET asynchronous socket programming and it may be modified for other purposes. If you choose to use the source for own purposes, please give credit where credit due i.e. please let me and users know about code reuse.
Download Installation (with Source Code) (1,011.41 kb)
November 28, 2008 at 9:34 AM
Every once in a while, I receive emails stating that some of my libraries were utilized as part of larger project. Besides being very excited (and somewhat proud I must admit), I always felt a need to somehow share the information with the rest of the world. After some thought, I decided to simply write a post and provide author's original work for download (with author's permission).
The latest project that I received was Masters Project by Karlo Martin Zatylny from University of Texas at Austin. Karlo's project was to implement Korat - "a library for creating test structures and data" - in C# language (hence the name Korat#). Korat testing environment was originally implemented and utilized in Java programming language. Karlo enhances original Korat implementation by adding "regular-expression data generation engine to provide valid string-based input for the given methods and libraries" Karlo's paper and implementation can be downloaded below:
Download Karlo's Paper in PDF (473.81 kb)
Download Source Code (683.25 kb)
August 12, 2008 at 11:22 AM
Couple of days ago, my blog application started crushing. At first, I assumed that my ISP provider is to blame. Somewhat irritated I submitted the question to the support crew and couple of emails later, they informed me that the blog application was taking over 100MB in RAM space (which triggers the server to stop the application). In addition I noticed that the number of visitors increased dramatically over the last couple of weeks. Quick look under the hood revealed that during post rendering, source code is rendered "on-fly", which utilizes Wilco.SyntaxHighlighter.dll control. Considering the fact that there are many posts that display the source code and that there are many visitors viewing them, it is possible that memory usage would increase drastically. To eliminate the issue I decided to render the code at the time of post editing (as opposed to rendering during page loading). The only elegant solution (in my case) was to use Windows Live Writer with source code plugin. However, I could not find a plugin that would satisfy my needs, so I decided to write my own.
July 28, 2008 at 10:03 AM
Recently I have been developing numerous applications in ASP.NET and Flex Builder 3. For security I utilized forms authentication as provided by ASP.NET engine. At first, everything worked well until there was a need to manually sign out current user. Quick look into MSDN documentation revealed SignOut() method of FormsAuthentication class. The documentation promised that this method signs out the user and redirects the client to login page. Considering the fact that I did not care about redirect (Flex application was running on the client side, so that redirection did not have any effect), I was hoping that the method would still perform desired effect and "de-authenticate" (I know, I know, that is not even a word) current user. At first, it seemed to work, but debugging revealed that even though this method removed authentication cookie, it did not sign out the user. User's identity was still marked as authenticated and subsequent calls to the Http handler would be considered authenticated. Furthermore, the session object was still valid, so that existing session information was still available. Quick look into MSDN revealed Session.Abandon() method, which would destroy session object upon execution. However, even though the session object was destroyed, client calls to ASP.NET web application were still considered authenticated. It was time to search the web to see if other developers faced the same issue.
After some research I ran into following Microsoft article: http://support.microsoft.com/kb/900111. The article explains that FormsAuthentication.SignOut() method does not prevent cookie reply attack, which essentially means that the cookie, even though it was destroyed, it was considered to be valid and all calls to the application that utilized this particular cookie were considered authenticated. The same article presented some possible workarounds, but it did not satisfy my needs. It bugged me that in order to prevent the access to secure parts of the application (even after log off), I had to track the security on client side (in addition to server side). So I tried following code:
/* Create new session ticket that expires immediately */
FormsAuthenticationTicket ticket =
/* Encrypt the ticket */
string encrypted_ticket = FormsAuthentication.Encrypt(ticket);
/* Create cookie */
HttpCookie cookie = new HttpCookie(
/* Add cookie */
/* Abandon session object to destroy all session variables */
Essentially the code replaces old cookie with new security cookie that expires immediately, which performs user sign out. In addition, all session variables are destroyed and new session is created so that old session cannot be reused. However, it is essential to mention that the technique presented in this post does not prevent Cookie Reply Attack. The old cookie is still valid for the duration specified in FormsAuthenticationTicket constructor.