You searched for the word(s): userid:303008

More Search Options

RSS Available

• Re: HTTP 400 Bad Request error when trying to process http://localhost:5957/http://yahoo.com

  I snipped the following from a forthcoming What's New document covering Beta 2: ASP.NET 4 introduces new options for expanding the range of allowable application Urls. The simplest and most useful change is that ASP.NET gives developers the option to allow longer Urls. Previous versions constrained Url path lengths to 260 characters (the NTFS file path limit). In ASP.NET 4 developers have the option of increasing (or decreasing if they choose) this limit as appropriate for their applications

  Posted to ASP.NET 4 Beta 1 (Forum) by sschack on 6/15/2009

• Re: HTTP 400 Bad Request error when trying to process http://localhost:5957/http://yahoo.com

  In current versions of ASP.NET Urls containing characters like the colon character will be rejected as a potential security threat. The historical reason for this is that the underlying NTFS file system supports alternate resource streams that can be accessed with names like "yourfile.txt:hiddendata.txt". Blocking the colon character from Urls prevents poorly written applications from accidentally working with alternate resource streams. There is also a limitation in current versions of

  Posted to ASP.NET 4 Beta 1 (Forum) by sschack on 6/8/2009

• Re: New in ASP.NET: reality and dreams.

  Yes you will be able to run applications compiled against the previous frameworks (2.0, 3.0 and 3.5) unmodified on 4.0. Though there will be some minor breaking changes which we will document - the ones I've seen to date for ASP.NET can be switched off via configuration switches. In terms of running without any previous frameworks on the machine - yes that will also work. For example you could setup a Windows Server 2003 machine and only install ASP.NET 4 on it. You can then run both older code

  Posted to ASP.NET 4 Beta 1 (Forum) by sschack on 5/26/2009

• Re: New in ASP.NET: reality and dreams.

  I know the answer to the first three questions - hopefully one of my compadres will jump in for the fourth item 1. When Beta 2 comes out you will see a number of controls updated with new non-table-based rendering, including Menu. There just wasn't time to fit this in for Beta 1. 2. It is a compatibility issue. Existing compiled code contains references in the assembly metadata that points at physical assemblies like System.Web.Routing.dll. As a result those assemblies need to exist so that type

  Posted to ASP.NET 4 Beta 1 (Forum) by sschack on 5/26/2009

• Re: Cache providers

  As part of designing the cache extensibility API we looked at various cache implementations and designs: ASP.NET in-memory cache Velocity distributed cache Patterns and Practices caching application block JSR 107 memcached

  Posted to Cache Extensibility (Forum) by sschack on 4/28/2009

• Brief description of the technology this forum is for

  We just recently placed on Codeplex download-able documents outlining draft APIs for a new cache extensibility feature in the 4.0 .NET Framework. This forum is the discussion area for gathering feedback about the APIs, and how they will be used both inside the .NET Framework as well as by the community at large. So welcome to the forum - and we hope you find the project interesting and useful!

  Posted to Cache Extensibility (Forum) by sschack on 3/12/2009

• Re: Migrating users from RSAClearTrust to an ASP .NET 2.0 Membership database

  You would have to step through in a debugger and look at the actual byte[] values that result when converting from the base64 string. And then compare that to an attemped SHA1 encoding using the same cleartext password that was used to generate the hashed passwords in the first place. Just looking at the base 64 strings above won't help since base64 encoding adds in its own pad characters - so its not clear from above if either the password or hash have been clipped. For reference, this is the

  Posted to Security (Forum) by sschack on 4/30/2008

• Coding techniques for protecting against Sql injection

  Over the past few weeks there have been reports and commentary about SQL injection attacks being launched against both classic ASP and ASP.NET sites (some details at http://blogs.iis.net/bills/archive/2008/04/26/sql-injection-attacks-on-iis-web-servers.aspx ). Included in this post are VB.NET and C# samples that can be used to screen incoming query-string, form and cookie values for potential Sql injection values. However because valid input data varies from website to website, it is not possible

  Posted to SQL Server, SQL Server Express, and SqlDataSource Control (Forum) by sschack on 4/28/2008

• Re: Migrating users from RSAClearTrust to an ASP .NET 2.0 Membership database

  One other idea - you might be able to reuse the original hash if moving from a 5 byte to a 16 byte hash preserves the original hash value. i.e. Going from 12345 to 0000000000012345 should work since they are the same value. This is just padding the original value out to a 16 byte boundary. However going from 12345 to 1234500000000000 won't work because the hash value has changed.

  Posted to Security (Forum) by sschack on 4/24/2008

• Re: Migrating users from RSAClearTrust to an ASP .NET 2.0 Membership database

  If its possible - decrypt the password, and then re-encrypt with the SqlMembershipProvider. However if hashing was used originally I think you're out of luck. The second you change a salt value, even only 1 bit of the salt value, the resulting output is completely changed.

  Posted to Security (Forum) by sschack on 4/24/2008