Tone's Notes

The combination of the FromFile, RotateFlip and Save methods from System.Drawing.Image is an obvious approach when looking for functions to rotate JPEGs by 90 degrees, but there are reasons for not doing it this way:

      public static void SimpleRotate90(string inFile, string outFile, bool clockwise) {

            using (Image image = Image.FromFile(inFile)) {

                  image.RotateFlip(clockwise ? RotateFlipType.Rotate90FlipNone : RotateFlipType.Rotate270FlipNone);

                  image.Save(outFile);

            }

      }

Why isn’t this a good solution? Here’s why:

1.      The saved image is typically much larger than the original.

2.      While the image displays fine in IE and some other tools, Photoshop 8 complains about an “invalid jpeg marker” in the file and won’t open it.

3.      It’s slower than it needs to be.

One solution is to let the Save method do more of the work by passing it an Encoder parameter that tells it to transform the image as it is saved.

The code looks like this:

      using System.Drawing;

      using System.Drawing.Imaging;

      ...

      public static ImageCodecInfo GetImageCodecInfo(ImageFormat format) {

            foreach (ImageCodecInfo info in ImageCodecInfo.GetImageEncoders())

                  if (info.FormatID == format.Guid) return info;

            return null;

      }

      public static void Rotate90(string inFile, string outFile, bool clockwise) {

            using (Image image = Image.FromFile(inFile)) {

                  EncoderParameters eps = new EncoderParameters(1);

                  EncoderValue v = clockwise ? EncoderValue.TransformRotate90 : EncoderValue.TransformRotate270;

                  eps.Param[0] = new EncoderParameter(Encoder.Transformation, (long) v);

                  image.Save(outFile, GetImageCodecInfo(ImageFormat.Jpeg), eps);

            }

      }

Comments about this implementation:

1.      The saved image is about the same size as the original.

2.      Photoshop 8 seems happy.

3.      The using statement guarantees that image.Displose() gets called which guarantees the inFile gets released.

4.      The helper function GetImageCodecInfo uses the ImageFormat class instead of relying on mime type strings.

Being a long time quicken user there are some operations I’ve come to dread. Switching from manual account reconciliation to automated reconciliation is one of them.

Sure enough, after downloading a few months of transactions and attempting to resolve the duplicate transactions I was left in a situation where either the reconciliation balance could be made correct or the register balance could be made correct, but not both at the same time. Reconciliation seemed to have the better of it, since getting the register to balance required either modifying the accounts opening balance or adding an adjusting transaction.

The thing that seems to screw it up is deleting reconciled transactions. Why this is a hard thing for the poor program I have no idea.

What really compounds the injury however is the response of Intuit’s customer support. Perhaps it’s the only way they’ve found to insulate themselves from the hordes of people calling with problems, but the “pay first ask later”, “it’s not a bug it’s a feature and we charge for help with features” approach is extremely frustrating when facing the simple fact that the program either can’t add or that it’s keeping numbers to itself that it isn’t showing you on the screen. I don’t care how you slice it; it’s a bug, and a rather inexcusable one in a piece of accounting software.

Fortunately during a previous interaction with customer support I acquired a bit of Quicken magic: Holding the control and shift keys down while selecting the FileàValidate operation causes “Super Validation” to run.

Sure enough, the “super validation” log reported “removing 9 records not in register”. You might ask: “If they weren’t in the register, where were they removed from?” But I was much too happy restoring my opening balances to the original values and getting on to more interesting things in life than double checking Intuit’s accounting software.

Found the NAnt style task and the VSConvert.xsl XSLT for generating NAnt build files from Visual Studio project files.

It failed to properly convert non-local references. There is a <lib> element for the <csc> task that could be used or you can use fully qualified path names.

I modified the directory names used to avoid conflict with those used by the IDE. i.e. nantbin instead of bin.

A brief attempt at getting the VSNAntAddin working failed using both the IDE build and NAnt build procedures. Didn’t pursue it at this time.

Setting RequireSSL to true causes authentication to require that all requests uses https; but it does NOT automatically switch to https when redirecting to the loginUrl page. If you don’t start out using https to access protected pages you are still transferred to the http flavor of your login page but login will not appear to work. What appears to be happening is this: authentication succeeds but does not end up adding a valid authentication cookie to the session (because https isn’t being used), you are redirected to the original protected content page, because there’s no cookie you are re-redirected back to the login page.

Therefore the practical consequence of RequireSSL is not to require SSL for login but rather to require it for all access to protected pages.

It would be nice if you could set forms authentication to force SSL for login and then have the redirectUrl return to the previous access mode (https or http).

See this post for more information.

David Hall’s efficient and compact managed C++ approach to accessing NT security classes from .NET

A much fatter approach to NT security class access for .NET by Renaud Paquay

Collection of Tips from BugsLayer article written by John Robbins for MSDN Magazines.

Walt Mossberg reviewed OurPictures which is close to one idea I’m developing.

A fellow blogger pointed me at BlogJet, which reminded me to get cranking on TonesNotes.

So you read the available documentation an put together the basic Forms authentication framework for an ASP.NET application (for which there’s a good article by Abel Banda on O’Reilly) and you say to yourself, boy it really sucks that these passwords are being sent over the internet unencrypted; which leads to the next logical step of using SSL for the login.aspx page.

The steps to follow are these:

1.      Add a server certificate to the web site root folder (Internet Information ServicesàDefault Web SiteàPropertiesàDirectory SecurityàServer Certificate…)

2.      Create folder in your web app for which you will require SSL access. Call it “ssl”.

3.      Move your login.aspx file to ssl/login.aspx.

4.      Make sure the NTFS security settings on the web application folder includes the anonymous IIS user account (IUSR_machine typically).

5.      Disable Integrated Windows authentication and make sure Anonymous access is enabled for the web app (Internet Information Servicesàweb app folderàPropertiesàDirectory SecurityàAnonymous access and authentication controlàEdit…)

6.      Require SSL for your ssl folder (Internet Information Servicesàssl folderàPropertiesàDirectory SecurityàServer Certificate…àcheck the “Require Secure Channel” box.)

7.      Modify the loginURL attribute of the Forms element in your web.config file to reference the new login.aspx location with an absolute url beginning with “https://”.

8.      Test your application.

At this point if you’re like me, a few things will begin to annoy you. First you’ll be reminded that you can’t debug under Visual Studio 2003 without Integrated Windows authentication. That’s okay. Leave it off for now. Just open a browser and manually try to hit your test page.

Again, if you’re like me, you should be getting a 401.2 error attempting to get the login.aspx page.

You might even try directly accessing the login page from the browser with https – no good. And you might try changing the loginUrl back to a relative url (“ssl/login.aspx”) and requesting your test page with https. Wow! That works!?! Hmm… You might also test what happens if you change the “deny users=”?”” to “deny users=”bob””. Again it works accessing each page with https, but you’ve given up forcing the redirect to the login page. If you actually tried any of these things, put things back the way they were and move on to the solution.

Add this in front of your existing <system.web> element in the web.config file:

<location path="ssl/login.aspx">

     <system.web>

         <authorization>

             <allow users="?" />

         </authorization>

     </system.web>

 </location>

This block tells the authorization logic to explicitly allow the anonymous user to access the ssl/login.aspx page and overrides the blanket deny element that comes later. There seems to be some special case code that handles relative login URLs but fails on absolute login URLs.

Change your loginUrl attribute back to an absolute “https://”  url and the authentication should work.

One annoyance remains: The ReturnUrl passed to the login page doesn’t include the request scheme (the “http://” part) so you end up stuck in SSL after you login.

So I tried taking charge of the redirect URL with the following code. Thanks to Scott Hanselman for the xml timeout hack, and yes, it needs better packaging for production:

System.Xml.XmlDocument x =new System.Xml.XmlDocument();

x.Load(Request.PhysicalApplicationPath + "web.config");

System.Xml.XmlNode node = x.SelectSingleNode("/configuration/system.web/authentication/forms");

int timeout = int.Parse(node.Attributes["timeout"].Value, System.Globalization.CultureInfo.InvariantCulture.NumberFormat);

string userData = "Place application specific data for this user here.";

FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(

      1,

      UserName.Value,

      System.DateTime.Now,

      System.DateTime.Now.AddMinutes(timeout), // Should be timout from web.config

      PersistCookie.Checked,

      userData,

      FormsAuthentication.FormsCookiePath);

string encTicket = FormsAuthentication.Encrypt(ticket);

Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, encTicket));

string url = FormsAuthentication.GetRedirectUrl(UserName.Value, PersistCookie.Checked);

Uri uri = Request.Url;

url = uri.Scheme.Replace("https", "http") + "://" + uri.Host + url;

Response.Redirect(url, true);

That does the trick but generates a very annoying Security Alert dialog (“You are about to be redirected to a connection that is not secure.”).

To avoid this warning which is intended to remind naïve users that they are being taken away from the protection of https by the never-to-be-trusted server you must arrange for the client to request the shift back to non-SSL traffic.

Instead of the “Response.Redirect(url, true)” at the end of the previous block of code, replace it with:

(FindControl("RedirectUrl") as System.Web.UI.HtmlControls.HtmlInputHidden).Value = url;

And merge the following bit of code into the login.aspx file:

            <script language="javascript">

            <!--

            function DoOnLoad() {

                  if (Form1.RedirectUrl.value)

                        window.navigate(Form1.RedirectUrl.value);

            }

            -->

            </script>

      </HEAD>

      <body onload="DoOnLoad()">

            <form id="Form1" method="post" runat="server">

                  <input type=hidden id="RedirectUrl" name="RedirectUrl" runat="server" />

That should do it. Nothing could be simpler…. J

The following notes are from Jason Loader,

2005-04-08

Here’s a good list of tools for troubleshooting ASP.NET authentication, authorization, and security issues.

Dynamically adding UserControls (ascx files and classes derived from System.Web.UI.UserControl) gets tricky when you start needing the controls re-instantiated at postback time.

For this discussion, I start with a conventional Web Form page (aspx file and class derived from System.Web.UI.Page) where the Page_Load method contains logic to create and add a variety of System.Web.UI.Control derived instances to the page’s Controls collection. The Page_Load implementation should only do the construction if IsPostPack is false because the context that determines how many and/or which controls to create should come from the ViewState for a post back.

Here are a few things to keep in mind:

1.      LoadViewState gets called before Page_Load and only on post back (i.e. when the request contains a hidden __VIEWSTATE form field.)

2.      If the correct structure of controls exists at the end of the Page derived class’ LoadViewState method then their state will automatically be restored.

3.      The content of the savedState argument to LoadViewState is just the state for the current control. It does not include the state for child controls.

4.      The Page class’ LoadViewState implementation restores any ViewState[string] assignments that were made.

A simple way to have the state of dynamically created controls restored on post back is to do the following:

1.      At the end of the Page_Load implementation, store just enough information in ViewState to recreate the same structure on post back. E.g. ViewState[“DynamicControlCount”] = 6;

2.      Override the LoadViewState method in the derived Page class.

a.       First call base.LoadViewState(savedState). This will restore the page’s ViewState. E.g. the value of ViewState[“DynamicControlCount”].

b.      Use ViewState[“DynamicControlCount”] to recreate the prior control structure.

That’s it! After calling the derived page class’ LoadViewState method, the framework will call the LoadViewState methods on each child control in a fixed traversal order.

Using the XmlSerializer class to deserialize an object from its XML representation from an assembly invoked in an ASP.NET context on Windows Server 2003 fails with a file not found error.

The problem is that the “INTERNET SERVICE” account doesn’t have write access to the c:\winnt\Temp folder.

This is a recognized problem.

Then again if we’re in an every accelerating whirlpool towards The Singularity within our lifetimes, perhaps its time to really start paying attention.

Transhumanism is the active pursuit of human improvement beyond what’s normal through technology.

www.orkut.com

Here’s Vernor Vinge’s 1993 article on The Singularity.