The following demonstrates how to use the thread's current IIdentity that has been authenticated using Windows security (and therefore is a WindowsIdentity, and not a GenericIdentity), to perform an action beyond the rights of the current thread's User context (the ASPNET user):

//Impersonate an authenticated user:
using System.Security.Principal;
...
  //Will be ASPNET user:
  //Debug.WriteLine("Current User is {0}", 
  //WindowsIdentity.GetCurrent().Name);

  //Get the WindowsIdentity:
  WindowsPrincipal wPrincipal = (WindowsPrincipal)this.User;
  WindowsIdentity wIdentity = wPrincipal.Identity;

  //Get the context (it's IDisposable):
  using (WindowsImpersonationContext impersonationContext = 
    wIdentity.Impersonate(){

    //Will be impersonation:
    //Debug.WriteLine("Current User is {0}", 
    //WindowsIdentity.GetCurrent().Name);


  //...perform code that requires security Context
  //of authenticated user.
  
   //Not required when using 'using':
   //impersonationContext.Undo();
  }//Undo() & Dispose.

  //Will be ASPNET user:
  //Debug.WriteLine("Current User is {0}", 
  //WindowsIdentity.GetCurrent().Name);

                

Links:

• WindowsImpersonationContext Class
• Page.User Property (System.Web.UI)
• http://support.microsoft.com/kb/306158
• http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToImpersonateAUserGivenHerToken.html

Just parking for later:

http://igorinnet.blogspot.com/

Just parking a link to this:

http://www.cybertouch.info/website-design/aspnet-commonly-used-26-optimization-performance-method.html

Parking a link to a provocative article: http://gadgetopia.com/post/6509

And I also like the 3 other article links at the bottom of the page:

The End of the “PHP sucks” Argument

ASP.Net and the Confusion of GET and POST

The Needless Complexity of ASP.Net ***

If we are talking about the HttpApplication class, like the class that
Global derives from in IDE generated global.asax files, then there are
*multiple* instances of this class. They are kept in a pool, and one
instance is pulled from the pool and associated with a request during
it's lifetime, then returns to the pool.

The sequence that the global events are raised is expressed below:

What you need is the following concept (in Page_Load or later):

uiButton.Attributes.Item("onclick") = 
    "this.disabled=true;" +
    GetPostBackEventReference(uiButton);

What we’re doing here is injecting a JScript disabled statement into the button’s onclick attribute, but we’re putting it before the jscript that is already there from the button’s normal postback behavior.

That’s all there is to it.

I would suggest encapsulating both these calls in a uscx, with 2 properties (destination page + window and drop the control on the page:

Using JScript:

body.Attributes.Add(
   "onLoad", 
   string.Format(
        "window.setTimeout(\"window.location.href='{0}'\",{1});",
    "login.aspx",
    (Session.Timeout * 60 * 1000) + (10 * 1000))
);

Using Refresh Meta Tag:

Response.AppendHeader(
    "Refresh", 
    string.Format("{0}; url=\"{1}\"”,
        Convert.ToString((Session.Timeout * 60) + 10),
        "login.aspx"
        )
    );

Further Reading:

Wikipedia: Refresh Meta Tag

Metas: general stuff

I'm touching up the XAct.Web.Controls.ListManager which uses some ClientSide script to manage the ICallBackHandler related stuff...which is not the point of this post.

The point of this post is that I'm using a single TextBox to PostBack a string of text:value;text:value;text:value pairs (the serialized text/value pairs within a ListBox), and when one sends back data like that one quickly runs in to the question of:

"What chars should I use for dividers?"

If you started coding around 2000A.D. you were breast-fed at the CSS udder, and the first set of chars that come to mind might be the ':' and ';' which would do fine for simple cases...but sooner or later,you would have to write a parser for more complex situations -- one that could handle quoted ':' and escaped chars...

If you go back before that, when VB6 and 5 were in vogue (cough!), you might prefer CSV stuff, so the next natural choices would be maybe ('\t' or ',') AND '|', and you still would get all lost in some kind of parser trying to handle exotic quotes, escaped quotes, etc...

Then if you're really old...when computers fit into ...well...my first computer had 1k of memory...so you couldn't even dream of fitting a parser into anything, and you just had to solve it a different way.

Enter ASCII (before it became un-PC to have any acronym start with the word "American") and you'll find these 4 chars:

FS, btw, was from even before my time, when things were on tape reels... I'm long in the tooth, but not that old...geez!

The point is...when transmitting data between computers, you don't have to have a human readable format: using non-printable chars means you don't have to worry about escaping or quoting or any other peculiarity.

Oh...and if you want to see what it was like back in the days of dinosaurs...you can download, and run (oh! the geek joy!) this fantastic job of a ZX-81 emulator...with pops, squeaks, and awful graphics...(you really had to be there to understand what was so damn great about it... 1 friggin K of memory! Yahoo!!!! )

I forget *ALL* the time...so I better write this done.

When writing a class (eg: SampleData) in an aspx's page that's not backed by a *.cs code, , and you want to refer to it from an ObjectDataSource, the TypeName is going to be...

Anyone? Anyone?

Its going to be in a namespace automatically generated by MS as ... ASP

And the class is going to be ...

Anyone? Anyone?

...the name of the file...

So, if you are writing in default.aspx page, and you haven't wired it up, it gets compiled as ...

namespace ASP {
...
  public class alphalistpicker3_aspx {
    ...
    public class SampleData {
      public string[] MySelect(){
      ...
      }
    }
    ...
  }
  ...
}

Voila...Voodoo in the machine... gives you a typename that is ASP.defautl_aspx.SampleData

I uploaded an article earlier this month that I slapped together from notes I found on my hard-drive as I was cleaning up.

As I put it up...I had a niggling feeling about it...that it was just plain wrong.

Turns out that I was right: I/it was wrong.

After doing a quick Investigation last night, I've re-written it to be hopefully right this time...

ASP- The Order in which ControlBuilder parses Declarative Tag attributes and nested tags 

Mea Culpa.

Just in case you missed this in the ASP.NET documentation...and you've been wondering how to use the controls i posted in the System.Web.Controls assembly page...

Also note that in v2.0, you can map multiple namespace/assembly pairs to the same tag prefix... so you could in fact use the tag prefix as sort of a brand identifier of sorts, even if you develop/ship multiple control assemblies

Nikhil Kothari

So its totally valid to:

<%@ Register  TagPrefix="XACT" 
    Namespace ="XAct.Web.Controls" 
    Assembly="XAct.Web.Controls.RepeaterII" %>

<%@ Register  TagPrefix="XACT" 
    Namespace ="XAct.Web.Controls" 
    Assembly="XAct.Web.Controls.XmlTransformer" %>
 
 

Which is why I now put each Control in its own assembly, unlike in the past when I had to decide what assembly to put a new control in, and it would take a long time to compile the whole assembly even though there was just one little change...

I don't do this enough to remember it when I need it...

<%--
   <XACT:XButton runat="server" id="myButton"></XACT:XButton>
--%>

The Default Behaviour: WebControls are Spans

The default behaviour for all custom controls are that they are wrapped in a Spans.
This is because all controls inherit from System.Web.UI.Control, and inherit its TagKey code, which defines that all Controls are wrapped in Spans:

protected virtual HtmlTextWriterTag TagKey {
    get { return HtmlTextWriterTag.Span; }
}

protected override HtmlTextWriterTag TagKey {
    get { return HtmlTextWriterTag.Div; }
}

Comparing the Two:

Spans

1. SPAN elements have 'display:inline' elements, which mean
2. Subsequent Sibling tags are rendered to the right.

Divs

1. DIV elements have 'display:block' elements, which mean
2. Subsequent Sibling tags are rendered after a BR tag is inserted.

The official w3 specs (at http://www.w3.org/TR/REC-CSS2/visuren.html#normal-flow) are:

9.4.2 Inline formatting context
In an inline formatting context, boxes are laid out horizontally, one after the other, beginning at the top of a containing block. Horizontal margins, borders, and padding are respected between these boxes. The boxes may be aligned vertically in different ways: their bottoms or tops may be aligned, or the baselines of text within them may be aligned. The rectangular area that contains the boxes that form a line is called a line box. The width of a line box is determined by a containing block. The height of a line box is determined by the rules given in the section on line height calculations. A line box is always tall enough for all of the boxes it contains. However, it may be taller than the tallest box it contains (if, for example, boxes are aligned so that baselines line up). When the height of a box B is less than the height of the line box containing it, the vertical alignment of B within the line box is determined by the 'vertical-align' property. When several inline boxes cannot fit horizontally within a single line box, they are distributed among two or more vertically-stacked line boxes. Thus, a paragraph is a vertical stack of line boxes. Line boxes are stacked with no vertical separation and they never overlap.

This means the following:

Spans

Pros

1. Good for Form elements (INPUT based cont