IE POST and redirect errors...

This blog post only exists to prevent expired linking. My blog has moved to: http://pabloaizpiri.com/

--------------------------------------------------------------------------------

UPDATE NOTE: I did find a much simple solution to this; as mentioned in the comments at the bottom,  I found that sending a compressed P3P security header did just fine to address the redirect issue and was much more simple to implement.
The HTTP module is now modified to send the P3P header on redirect. You can do so as follows:

_context.Response.AddHeader("p3p", "[P3P Policy Here]")

You can find more information about P3P here.

Many developers use redirection as a tool to present the user with another page once a process has been completed. One of the most common uses is- for example- a login. A user logs in, and- if he is authenticated he is redirected to another page, if not the same page is displayed with an error message informing the user why the authentication failed. (Such as an incorrect username/password combination)

I don't know if I would consider this the best way to carry out these types of transactions, since in my understanding that isn't exactly what redirects were meant for- however, it is a simple way to address these type of situations and on strictly pragmatic terms- can often be the best approach.

I've been working on a page that does exactly this, when I ran into an error.


The Problem.

Apparently, if you do a POST to a page and that page sends back headers to set a cookie AND redirect in the same response, the cookie does not get set. This seems to be a bug in IE. And the fact that the page was originally called from an iframe seemed to be key to the problem.

How did I run into this? I was working with another system that seamlessly integrated into the web application, and it happened to open the website in an iframe. The process was mostly simple:

1. Client used Web Application A which makes a form post to Web Application B within an iframe. (Web Application A uses iframes)


2. Web Application B processes the post for authentication.


3. If the authentication succeeds, Web Application B redirects the client to a "services" pages also on Web Application B that offer services.


4. The client is now looking at a "services" page on Web Application B which is within an iframe of the Web Application A.

The problem was between steps 3 and 4 - in that the 4th step would never happen. The client was certainly redirected to the "services" page but the "services" page would redirect the client right back to a login page because the client was not authenticated. In step 3 the server would attempt to send back a cookie to identify the session and redirect in the same response, but the cookie would never be set and never sent back.

It was an "intermittent" problem- and I still haven't gotten it to replicate more than twice to figure our the exact conditions under which it does work; the rest of the time it failed.

However, a suspicion tells me it was not an intermittent error, but rather that it always happens. (After all, there are no intermittent errors. It's all a matter of finding out the exact conditions under which these anomalies occur)
I noticed that when the browser did successfully set the cookie and return it, it was most likely because I had previously signed on the site before, effectively forcing the browser to send back my old authentication cookie- "seemingly" making it work.

Anyway, I found a blog by Brian Donahue where it seems like he ran into the same bug, or at least a related bug:
http://www.persistall.com/archive/2008/01/25/cookies--redirects--nightmares.aspx

It was the closest thing I could find to the problem I was having. After attempting the solutions provided with no success, it seems to me like there is a little more to it, and in this case, the only thing I can think different is the fact that in my case it involves an iframe. However, something tells me that this can't be it. For one, it doesn't make sense, but I'm also not completely ruling it out- there just may be something about the way cookies are handled within an iframe that I don't know about, but basically I'm still wondering why the solutions Brian Donahue wrote about did nothing for me. I would be more than appreciative to anyone who could educate me better on why this happens- for now I will continue to attempt to find the exact reason for this bug!


The Consequences.

Anyway, this cookie not being set was a rather large problem, because this would mean the user would not be authenticated. This would destroy the communication between both systems so I had to think of some way to fix the problem.

I started looking into the session object in ASP.NET and how that is handled, as well as just all the HTTP Pipeline in general.

I thought about enabling cookie-less sessions, and it might have worked out if I could use them on a per-page basis, but that was quite a port-over and not as secure. I hated the idea of an ID being displayed on the address bar, (especially for each pages) both for security and just aesthetic reasons, really. All in all, I finally decided against enabling cookie-less sessions.


Addressing The Problem.

How was this problem solved?

I wrote an HTTP Module. The module essentially "interrupts" the response, checks if the response is a redirect and sets a cookie- and if it does- it changes the URL direction by appending to the url a session ID, (like the cookie-less session feature) and a key that quickly expires.

The receiving page "interrupts" the request, checks for this session ID, generates a cookie with the ID value from the query string, and feeds this artificial cookie into the HTTP the pipeline. The session is then loaded normally by ASP.NET.
There is also some logic to check the key that was passed in for validity, as well to check if it was expired- if so, the session is destroyed effectively logging the user out before any of the code in the page object is executed.

I felt this solution was great for a few reasons:

• The URL will virtually never display a session ID.
  For 98% for the application usage, the URL will never contain a session ID. When it does, it will be more secure on account of the expiring key. It will only show on those specific URLs that redirect and attempt setting a cookie at the same time.
  Currently the only page that redirect this way is linked from an iframe, which means the user will never see the page address; now I can lean towards 99.99%


• More Secure than the enabling session-less cookies.
  The security is much tighter than cookie less sessions because an expiring key must also be authenticated when the session data is passed on.


• It only affects redirects that set cookies.
  This was great in that I didn't want to add complexity to the website and overhead that was unnecessary.


• It is completely transparent to other developers.

The last point was one of the greatest benefits. This means any other developer can come after me, and write his pages like he normally does, without ever even being aware of the IE Redirect bug. Because the code works on a lower level in the HTTP Pipeline chain, this is all done transparently.

This drives the cost of ownership of the application down because future developers will not have to be versed on the changes or develop specifically to accommodate for the change, or even run into the error in the first place and attempt to address it. This drives development time down which translates to more time in other projects and no money wasted.

Until next time,
- Jheatt

XML, Web Services, SOAP, and transmission protocols

Intro

In the pursuit of integration, I've found myself needing to integrate with clients with different integration needs/capabilities. In doing so I found some interesting things about .NET as well as just web services in general.

Communication Protocols

Although most web services are consumed over HTTP as the transmission protocol, not all communicate through SOAP. While generally the standard is communication through SOAP, some communicate over HTTP.

I recently found .NET does have the ability to use HTTP POST and GET as communication protocols as well, which seems expected. However, as of .NET 1.1 SOAP is the primary communication protocols and while HTTP and GET are supported, they are disabled by default. It turns out that it is very simple to enable them, only requiring the following change in your application's "web.config" file:

<webservices>
  <protocols>
    <add name="HttpPost">
    <add name="HttpGet">
  </protocols>
</webservices>

This makes integration with many legacy systems much more possible- and especially other systems that are not on the .NET platform.

A page built to make a request to a web service using HTTP as both the transmission and communication protocol may look as such:

<form action="mywebservice.asmx/WebServiceMethod" method="post">
  <input name="parameterName" value="param1" />
  <input name="parameterName2" value="param2" />
  
  <input type="submit" value="Submit!" />
</form>

If you were developing your web service on .NET all you'd have to do is develop as normal and modify your web.config as described. You may also consume a web service using GET and query parameters.

One of the scenarios I've found myself in is a client desiring to consume the web service using HTTP as both the transmission and communication protocols, however passing XML as a "parameter" effectively using XML as a communication protocol as well. I found this is relatively simple and easy to work with as long as the XML is url-encoded as one of the form's fields, and is decoded once loaded. (In .NET you would simply use HttpUtility.UrlDecode()).

You can then load this string in an XmlDocument and manage it easily using the object structure in .NET. When returning a response- if the client is able to accept an XML response- using .NET you can simply return the XmlDocument object. The XmlDocument Object can be found in the System.Xml namespace. do not return an XML-formatted string if you have an XmlDocuments.


XML and SQL Server 2005

In the midst of all this, I found myself storing XML. I realized there was an XML data type in SQL Server, and so I did a bit of research on it. I decided to use it and I was pretty amazed.

By storing data as XML in SQL Server 2005 using the XML data type, you can actually use XQuery to write queries that take advantage of the XML data structure. It's almost like running your main query and s asubquery to filter the XML data. It make it very practical and simple to retrieve and store XML data.

A SQL Query using XQuery might look like:

SELECT OrigXmlRequest.query('/Notes//child::*')
FROM YardiRequest

This would return all the XML child nodes and their descendants of 'Notes'.

XML Data in SQL Server 2005 is stored in the same was a varchar(MAX) is, and has a max size limit of 2 gigs. (Which if you're hitting anywhere close to that 2 GIG limit when storing an XML file, you should probably store the data normalized in tables)

One thing I ran into that I would like to point out when storing the XML data from .NET into SQL was the encoding format used. I kept receiving an encoding exception, until I realized the encoding needed to be changed from UTF-8 to UTF-16 in order to be stored in the database. If you have an XmlDocument object, an easy way to do this would be to just edit the first child and the you will be able to store the data. e.g.:

xmlDcRequest.LoadXml(myXmlString);
// Change encoding to UTF-16 for storage in SQL Server
xmlDcRequest.FirstChild.InnerText = xmlDcRequest.FirstChild.InnerText.ToLower().Replace("utf-8", "UTF-16");

...

// Adding the XML to a stored procedure parameter to store the XML data:
sqlCmd.Parameters.Add("@XMLRequest", SqlDbType.Xml).Value = xmlDcRequest.InnerXml.ToString();

Final Notes on Web Service Development

I think one of the biggest lessons I am learning from putting together web services to service other clients is the cruciality of writing code as bulletproof as possible. Of course, you should always be doing this anyways. Make sure your web service is returning clear error codes and descriptions when errors do occur to make development for the client straightforward. Clear communication and a detailed scope of work are essential. Even though these are simple things, it seems many times these things are missed.

- Jheatt

SQL Server Reporting Services and Headers requiring dataset fields.

Any search for "fields in headers SSRS" in Google will come up with many search results with pages addressing workarounds for one of Microsoft SQL Server Reporting Service's biggest weakness: the inability to add fields to the header or footer from a dataset.

This limitation makes some sense in that a dataset returns rows of fields and so the problem might lie in identifying which row should be displayed, however one should be able to define exactly what to display- the first or last row or maybe an aggregate of the rows.

All that to say, this is yet another workaround I haven't seen elsewhere. It addresses the problem of maintaining data in the header regardless of what page the report is being viewed on.

Why another work around? I tend to avoid storing fields in internal parameters because I've had problems with it before, and shared variables are a horrible solution in a production enviroment because of the possibility of concurrently running reports. It seems like these are always the solutions given to this issue.

So here goes: the way I've solved it is by making a group within the table displaying my dataset, and then using the footer of the group to store a list box, (if you are needing to use the footer, simply extend it to add another footer row right below it). In that list box you can place another table or fields and you can even have this list box pull from another datasource. When done, set the group footer's "Hidden" property to "True" so that it doesn't show on the rendered report, and you're set. You can now reference these fields from the header or footer like so:

=First(ReportItems!NameOfTextboxInListItem.Value,"datasourceORgroupName")

And since it's an expression, you can do whatever you want. You can also use aggregates and such- just make sure you modify the expression on the field/table pulling directly from the dataset, and not the field in the header/footer that will actually be displaying the data.

The only major problem I've run into with this approach (that I am still working on) is that the fields in the header will export as blank if I export the report as a PDF. It will do fine in HTML, or even Excel. (Which is funny since most rendering errors seem to be tied to Excel instead of the other way around).

If any solution is found to this issue, or if someone can explain to me the PDF rendering process and why these fields show up as blank, it would be greatly appreciated!

Hopefully this post was of some use to those that do not need to export in PDF...

- Jheatt

HTTPS, HTTP, and form posting.

So this is really more of a quick blog post for my own benefit of recording a solution. HTTPS and form posting.

I haven't really done a whole lot with HTTPS and I'm still sort of new to it. I was trying to do a form post cross-domain between a beta server and my computer and it wouldn't work. It would run fine locally, but not with the BETA server. The funny thing is it ran fine when I tried running it locally on the BETA server or on my development machine, but I couldn't post from my development machine to the BETA server- so it seemed like it was a cross-domain security issue.

All the POST fields would come up blank- actually they wouldn't even be set, query parameters would be fine of course.

Another fellow developer I work with pointed out I should be posting back with HTTPS. The form was posting to a HTTP address, but once it loaded it showed HTTPS. That was the only problem. I couldn't believe it- so simple! I guess I needed to be humbled.

So I still don't understand HTTPS completely, but I will definitnely be researching. My guess is that the POST didn't go through since the HTTPS server was addressed as HTTP in the original form POST and so the POST didn't go through all the SSL encryption action and hence it turned up empty on the server side... any one care to give me the technical explenation? I guess I'll find out more when I research.

- Jheatt

New Job; New Obstacles

So I switched jobs, and this new place is totally a Microsoft Shop. It's different than what I'm used to, but in a good way. I like how we are working with the latest tech for the most part, including MS Visual Studio 2008- love it.

Doing nothing but .NET (Both VB and C#) with the exception of a few third-party controls (Telerik) this will was sort of a new field for me with new obstacles. I'm excited. I was looking forward to working with a .NET development team and loving it so far.

So I know I haven't written a tech blog forever but I'm starting to realize the importance of this blog to more than just giving back to the community- more like a way to remember all the problems and solutions I've come accross. Sometimes I'll run into the same problem I've ran in the past but will forget the solution, so it's easy to see how a blog would be a great way to retrieve this information while helping others as well.

Anyway, just preparing the way for my first post as a software engineer here at Trak-1. Happy coding...

- Jheatt