Errors and Bugs

Upgrading to subtext 2.0-fail

Brendan Kowitz — Fri, 15 Aug 2008 13:55:40 GMT

It's been a long time in between updates for subtext, but, has it actually been worth it? Well, kinda. Compared to the 1.9.5 release this one seems a little rough around the edges.

If you're on a shared host WITHOUT full trust, beware! Things will break in multiple places, including:

~~DTP.aspx (The homepage) (tag "st" undefined, needed to add back 'Register TagPrefix="st" Namespace="Subtext.Web.UI.WebControls"')~~ (My web.config merge error)
/admin/Posts/ (EnclosureMimetypes config section missing requirePermission="false" attribute)
/admin/Feedback/ ("FeedbackStatusFlag" undeclared, needed to prefix with the namespace)
Subtext.Framework.UrlManager.UrlReWriteHandlerFactory.GetHandlerForUrl(string url) also breaks from a security permission when calling UrlAuthorizationModule.CheckUrlAccessForPrincipal(), had to recompile Subtext.Framework to get around this.

EDIT: I don't mean to blast subtext, but I might as well lay a few more issues out there:

The call to "/Admin/Services/Ajax/AjaxServices.ashx?proxy" throws an "Operation could destabilize the runtime" exception, haha I must say this is the first time I've seen that, fixed by generating the AjaxServicesProxy.js file locally.
In the Feedback admin area, when hovering the URL icon the "title" tag shows the email address.
Forgot to add this last night: Had to remove the OpenID stuff from the login page, errors with "Cannot be called from Untrusted assembly".

The problems in this upgrade mostly appear to be stemming from carelessness regarding restrictions in medium trust. I guess the question is - "Is subtext venturing away from medium trust on purpose?"

Looking to the future. From what I recall I don’t think it’s actually possible to run .net 3.5 applications without full trust, features such as anonymous types simply don’t work.

ERROR: 42601: a column definition list is only allowed for functions returning record

Thu, 15 Mar 2007 11:30:35 GMT

Since the postgres forums appear to be a little quite, I'll post my error here as well.

This error is in regards to the postgres .net npgsql driver and seemed to only occur when using stored procs.

The Error
The behavior I experienced happens when using stored procedures started out with me getting the following error:
ERROR: 42601: a column definition list is only allowed for functions returning "record"

After checking and double checking the stored proc and the parameters I was sending in I turned Npgsql's debugging on. The error appears to be coming from a statement that looks like the following:
select * from sitemenus_ins(68::int4,34::int4) as (psitemenuid int4, prowstamp timestamp )
This line of sql fails.

However the following will work:
select * from sitemenus_ins(68::int4,34::int4)
The only difference being that the second one has the 'as(...' clause taken off.

Strange Observation:
The snippet in question is executed automatically by the provider after the NpgsqlCommand.cs class does some other queries to try and match the list of the parameters that are in the stored procedure it is about to execute. However, the 'select' it uses to determine if it should append the 'as(..' clause is queried from the pg_proc table but is matched on the parameter types that are passed in, and not on those of the actual proc.

For example, this means that if I passed in say a 'Text' type (25) as opposed to the defined datatype on a proc (eg. 'Varchar' 1043) The select will fail and the extra 'as (...' on the end of the statement in question will not be appended. So the function call will work

Resolution:
I have no idea what the ideal solution is, I don't have a firm understanding of the ins and outs of the provider, but after downloading the source and removing the check so the 'as (...' never gets appended, all CRUD operations in my unit tests pass.

Another suggestion by Al is that maybe it is a piece of code left in there that was needed from a previous version of postgres (since the code has been around for a few years now). Whatever the reason, it causes errors, I've checked the source for another postgres provider and it doesn't attempt to do the append. The only concern I have if this is an actual bug is that it looks as though the same code has been copied into the branch for the npgsql2 provider, so those wanting to use stored procs on postgres in the future may find the same error I have.

ASP.NET 2.0 Mozilla Browser Detection Hole

Brendan Kowitz — Mon, 11 Dec 2006 02:58:54 GMT

It has recently come to my attention that there is something drastically wrong with the way search engines have been indexing my ASP.NET 2.0 blog.

As I've started to explain previously, this is because of the way the browser detection is set up. To give a brief rundown ASP.NET 2.0 has a default browser definition which seems to assume that the default browser is fairly capable and supports common things such as javascript and cookies. A browser definition can get inherited into other definitions which can then override specific properties to update it for that specific browser or browser version.

Apparently in around March 2006 Google started rolling out updates that changed the Googlebot's useragent string from:

"Googlebot/2.1 (+http://www.googlebot.com/bot.html)" to
"Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Now the reason for this is so the Googlebot could identify itself as being Mozilla/5.0 compliant which should allow it to be accepted by more webservers. However this breaks the detection pattern in ASP.NET. (And was always broken in Yahoo Slurp, I just don't know if anyone ever noticed).

When the useragent was just "Googlebot/2.1" it wasn't able to be matched and used the "default.browser" detection file which defaulted to a browser of reasonable capabilities. After the change it found itself in the "mozilla.browser" file because it was detected on the "Mozilla" word. So all the following sets of instructions in the "mozilla.browser" file try to establish exactly what platform and variant of Mozilla it is, for example, if its Firefox running on OSX, or if it's the older Mozilla Gecko rendering engine. But because there is no definition for a Generic Mozilla/5.0 compatible browser it gets the most relevant match, being the lowest Mozilla/1.0 compatible settings. Bad!

Because of this bad detection the default Mozilla/1.0 settings assume NO COOKIES and insert the session ID into the url then issues a response status 302 (content temporarily moved). What makes this situation even worse is that the default behavior of search engines is to follow these redirects and index the content on the other side. So basically everytime some random User-agent that claims to be Mozilla/5.0 compliant hits the site it gets Mozilla/1.0 capabilities. What is needed is something to bridge this gap.

Fortunately there is something that can be done that won't even require a recompile of your ASP.NET 2.0 application. Simply create a "genericmozilla5.browser" file in your "/App_Browsers" folder in the root of your application with the following in contents:

<browsers>
<browser id="GenericMozilla5" parentID="Mozilla">
<identification>
<userAgent match="Mozilla/5\.(?'minor'\d+).*[C|c]ompatible; ?(?'browser'.+); ?\+?(http://.+)\)" />
</identification>
<capabilities>
<capability name="majorversion" value="5" />
<capability name="minorversion" value="${minor}" />
<capability name="browser" value="${browser}" />
<capability name="Version" value="5.${minor}" />
<capability name="activexcontrols" value="true" />
<capability name="backgroundsounds" value="true" />
<capability name="cookies" value="true" />
<capability name="css1" value="true" />
<capability name="css2" value="true" />
<capability name="ecmascriptversion" value="1.2" />
<capability name="frames" value="true" />
<capability name="javaapplets" value="true" />
<capability name="javascript" value="true" />
<capability name="jscriptversion" value="5.0" />
<capability name="supportsCallback" value="true" />
<capability name="supportsFileUpload" value="true" />
<capability name="supportsMultilineTextBoxDisplay" value="true" />
<capability name="supportsMaintainScrollPositionOnPostback" value="true" />
<capability name="supportsVCard" value="true" />
<capability name="supportsXmlHttp" value="true" />
<capability name="tables" value="true" />
<capability name="vbscript" value="true" />
<capability name="w3cdomversion" value="1.0" />
<capability name="xml" value="true" />
<capability name="tagwriter" value="System.Web.UI.HtmlTextWriter" />
</capabilities>
</browser>
</browsers>

This will match generic Mozilla compatible browsers and spiders with user-agents strings such as:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)
Mozilla/5.0 (compatible; AbiLogicBot/1.0; +http://www.abilogic.com/bot.html)
Mozilla/5.0 (compatible; AnyApexBot/1.0; +http://www.anyapex.com/bot.html)
Mozilla/5.0 (compatible; BecomeBot/3.0; MSIE 6.0 compatible; +http://www.become.com/site_owners.html)
Mozilla/5.0 (compatible; MojeekBot/2.0; http://www.mojeek.com/bot.html)
Mozilla/5.0 (compatible; Scrubby/2.2; +http://www.scrubtheweb.com/)

Other Notes

The MSNBOT also never had this problem because it like the original Googlebot string was never detected and thus received the "default.browser" file settings which support the cookies.

My solution is not a complete fix, I think Microsoft could have done one thing better here. Because the browser string goes into the "mozilla.browser" file, they need another level where when it knows its Mozilla/5.0 compliant it gets the appropriate defaults before it starts to figure out exactly what browser it is. Even though with this approach the exact browsing useragent wouldn't be established, it would at least support future browsers claiming to be compliant at a higher level then just "Mozilla".

Downloads

genericmozilla5.browser

Cleaning Up ASP.NET Sessions in Google

Brendan Kowitz — Wed, 06 Dec 2006 13:49:27 GMT

ASP.NET and Dirty Urls

There are two things that have been bothering me about pages that are getting indexed in Google from an ASP.NET application. The first is somehow there are ASP.NET Session Urls ending up in the Google index. This is bad because searchers that actually do click these links are likely to get a 500 error (internal server error) because they will be trying to access a page of an expired session.

How is Google finding all these 'bad' urls?

Well apparently there is no browser definition in ASP.NET 2.0 for the Googlebot's useragent string, so when the spider hits your ASP.NET page it's browser capabilities are not defined.

Edit: The default browser capabilities are defined to use cookies, the issue occurs because the base Mozilla definition is defined to NOT use cookies. If the browser is not able to accept cookeis .NET gets around this by inserting the session information into the Url and issues a 302 (content temporarily moved) in the response header.

This default behaviour is a good and a bad thing. It's good in the fact that if I'm browsing an asp.net site on a pda that doesn't support cookies I still can. However just about every search engine spider ever created has it's own UserAgent string making it a tough task to issue the standard non-crufted url. One solution to fixing the session urls being indexed in Google is to tell your asp.net application that Googlebot supports cookies and the problem is solved.

To read more about the solution please see my next post.

Dynamic Captcha build-up

Another dynamic aspect that is used on this site are Captcha images, and yes Google's image spider finds those too. Upon trying a Google image search on my domain, it's littered with Captcha images! I've also added an exclude to the robots.txt file for this.

Solution for Captcha images build-up and stop-gap solution for Session Urls

Here is my "robots.txt" file so far for my SingleUserBlog install. *Note the last two lines, "Disallow: /(A(*" should exclude any ASP.NET session urls, (this is not recommended unless you have fixed the Mozilla detection hole). The last line should exclude any captcha images from being indexed.

User-agent: *
Disallow: /LoginPage.aspx
Disallow: /Administration/
Disallow: /(A(*
Disallow: /Captcha.ashx*$

'TextBox' cannot have children of type 'DataBoundLiteralControl'.

Sun, 12 Mar 2006 19:14:54 GMT

From what I've seen this particular error is already pretty well documented, however it is one of the things that Visual Studio is a little misleading about.

Seems this is a lesson why you can't always rely on intellisense to tell you what to type. In a datagrid, the following code will error:

Error:

<EDITITEMTEMPLATE>
<asp:TextBox id=TextBox1 runat="server">
  <%# TimeZoneInformation.ToLocalShortDateString(
    (DateTime)DataBinder.Eval(Container.DataItem, "FromDate")) %>
</asp:TextBox>
</EDITITEMTEMPLATE>

This will land you with a "'TextBox' cannot have children of type 'DataBoundLiteralControl'." error.

Solution.

<EDITITEMTEMPLATE>
<asp:TextBox id="TextBox1" runat="server" 
value='<%# TimeZoneInformation.ToLocalShortDateString(
    (DateTime)DataBinder.Eval(Container.DataItem, "FromDate")) %>'>
</asp:TextBox>
</EditItemTemplate>

In this case the "value" tag is valid, even though intellisense doesn't think so.