Where is the user impersonation token stored?

Discussion in 'ASP .Net Security' started by Gery D. Dorazio, Oct 10, 2005.

  1. When a user visits a web site and is authenticated through the popup dialog
    box (Windows authentication) he enters his username and password. Evidently
    this creates the users impersonation token that is used on subsequent
    requests to secured web pages. On subsequent requests the
    WindowsAuthenticationModule is what authenticates on each request. The code
    that does this looks like this:

    WindowsIdentity wi = new WindowsIdentity(ctx.WorkerRequest.GetUserToken(),
    text2, WindowsAccountType.Normal, true);
    Context.User = new WindowsPrincipal(wi);


    The questions are:
    1. Where did the initial Windows authentication put the user impersonation
    token?
    2. Where is the user impersonation token stored as the user makes web page
    requests(or is it generated on each request and if so how?)?


    Thanks,
    Gery



    --
    Gery D. Dorazio
    Development Engineer

    EnQue Corporation
    www.EnQue.com
    www.ImagingHardware.com
     
    Gery D. Dorazio, Oct 10, 2005
    #1
    1. Advertising

  2. Hello Gery,

    1) The outcome os IIS authentication is stored in a blob called ISAP Extension
    Control Block - the ASPNET_ISAPI extension passes the token to ASP.NET (via
    WorkerRequest). This token is availabe in ASP.NET 2.0 using the Request.LogonUserIdentity

    2) There is some caching involved in IIS - but ASP.NET grabs the impersonation
    token on each request from IIS to populate Context.User.

    HTH
    ---------------------------------------
    Dominick Baier - DevelopMentor
    http://www.leastprivilege.com

    > When a user visits a web site and is authenticated through the popup
    > dialog box (Windows authentication) he enters his username and
    > password. Evidently this creates the users impersonation token that is
    > used on subsequent requests to secured web pages. On subsequent
    > requests the WindowsAuthenticationModule is what authenticates on each
    > request. The code that does this looks like this:
    >
    > WindowsIdentity wi = new
    > WindowsIdentity(ctx.WorkerRequest.GetUserToken(),
    > text2, WindowsAccountType.Normal, true);
    > Context.User = new WindowsPrincipal(wi);
    > The questions are:
    > 1. Where did the initial Windows authentication put the user
    > impersonation
    > token?
    > 2. Where is the user impersonation token stored as the user makes web
    > page
    > requests(or is it generated on each request and if so how?)?
    > Thanks,
    > Gery
    > EnQue Corporation
    > www.EnQue.com
    > www.ImagingHardware.co
     
    Dominick Baier [DevelopMentor], Oct 10, 2005
    #2
    1. Advertising

  3. Hi Dominick,

    Thanks for the feedback. Can you explain a little more with respect to IIS?

    Here is the scenareo that has me stumped and really the reason for the post:

    1) User requests a restricted page and the Windows popup dialog appears so
    the user logs in and is authenticated. Then the page is served up.
    2) The user then clicks on another secured page link and is directed to that
    page...no popup since he is already authenticated.

    Here is a question that may hit the core of the problem:

    How does IIS handle authenticated Windows accounts during client-server
    requests to a web server?


    Here is my thinking as to what happens and the source of my confusion:

    When an HTTP request is finished and the response is sent back to the client
    the worker thread is finished and recycled...at least that's how I
    understand it. Along with this understanding the server then would have no
    knowledge whether the user is logged in....eg http is stateless. Then for
    subsequent requests IIS would have to log them in automatically for each
    request since they already logged in once. But what happens on the next
    request? Where does IIS (or some ISAPI authentication filter/extension) get
    the information to re-logon the user? Translated....where is this:
    ctx.WorkerRequest.GetUserToken() getting its user token from?...is it stored
    in a header, an encrypted cookie passed back and forth between client and
    server?...all this is only in regards to Windows authentication and not
    ASP.NET forms authentication since I know that is encrypted in a forms
    cookie...


    Thanks and hope this is clear,


    Thanks,
    Gery


    --
    Gery D. Dorazio
    Development Engineer

    EnQue Corporation
    www.EnQue.com
    www.ImagingHardware.com

    "Dominick Baier [DevelopMentor]" <>
    wrote in message news:...
    > Hello Gery,
    >
    > 1) The outcome os IIS authentication is stored in a blob called ISAP
    > Extension Control Block - the ASPNET_ISAPI extension passes the token to
    > ASP.NET (via WorkerRequest). This token is availabe in ASP.NET 2.0 using
    > the Request.LogonUserIdentity
    >
    > 2) There is some caching involved in IIS - but ASP.NET grabs the
    > impersonation token on each request from IIS to populate Context.User.
    >
    > HTH
    > ---------------------------------------
    > Dominick Baier - DevelopMentor
    > http://www.leastprivilege.com
    >
    >> When a user visits a web site and is authenticated through the popup
    >> dialog box (Windows authentication) he enters his username and
    >> password. Evidently this creates the users impersonation token that is
    >> used on subsequent requests to secured web pages. On subsequent
    >> requests the WindowsAuthenticationModule is what authenticates on each
    >> request. The code that does this looks like this:
    >>
    >> WindowsIdentity wi = new
    >> WindowsIdentity(ctx.WorkerRequest.GetUserToken(),
    >> text2, WindowsAccountType.Normal, true);
    >> Context.User = new WindowsPrincipal(wi);
    >> The questions are:
    >> 1. Where did the initial Windows authentication put the user
    >> impersonation
    >> token?
    >> 2. Where is the user impersonation token stored as the user makes web
    >> page
    >> requests(or is it generated on each request and if so how?)?
    >> Thanks,
    >> Gery
    >> EnQue Corporation
    >> www.EnQue.com
    >> www.ImagingHardware.com

    >
    >
     
    Gery D. Dorazio, Oct 10, 2005
    #3
  4. Hello Gery,

    first of all the browser never tries to authenticate if he doesn't need to
    - when you hit a page where you don't have anonymous access - IIS bounces
    back a 401 to the client along with the possible authentication methods.

    From that point on the browser sends the authentication information as a
    header to the server on each request.

    download www.fiddlertool.com and try the different authentication settings
    in IIS - you can see the headers flowing back and forth. A good testpage
    to test the various settings can be found here:
    http://www.leastprivilege.com/UpdatedShowContextsAndRequestLogonUserIdentity.aspx

    ---------------------------------------
    Dominick Baier - DevelopMentor
    http://www.leastprivilege.com

    > Hi Dominick,
    >
    > Thanks for the feedback. Can you explain a little more with respect to
    > IIS?
    >
    > Here is the scenareo that has me stumped and really the reason for the
    > post:
    >
    > 1) User requests a restricted page and the Windows popup dialog
    > appears so
    > the user logs in and is authenticated. Then the page is served up.
    > 2) The user then clicks on another secured page link and is directed
    > to that
    > page...no popup since he is already authenticated.
    > Here is a question that may hit the core of the problem:
    >
    > How does IIS handle authenticated Windows accounts during
    > client-server requests to a web server?
    >
    > Here is my thinking as to what happens and the source of my confusion:
    >
    > When an HTTP request is finished and the response is sent back to the
    > client the worker thread is finished and recycled...at least that's
    > how I understand it. Along with this understanding the server then
    > would have no knowledge whether the user is logged in....eg http is
    > stateless. Then for subsequent requests IIS would have to log them in
    > automatically for each request since they already logged in once. But
    > what happens on the next request? Where does IIS (or some ISAPI
    > authentication filter/extension) get the information to re-logon the
    > user? Translated....where is this: ctx.WorkerRequest.GetUserToken()
    > getting its user token from?...is it stored in a header, an encrypted
    > cookie passed back and forth between client and server?...all this is
    > only in regards to Windows authentication and not ASP.NET forms
    > authentication since I know that is encrypted in a forms cookie...
    >
    > Thanks and hope this is clear,
    >
    > Thanks,
    > Gery
    > EnQue Corporation
    > www.EnQue.com
    > www.ImagingHardware.com
    > "Dominick Baier [DevelopMentor]"
    > <> wrote in message
    > news:...
    >
    >> Hello Gery,
    >>
    >> 1) The outcome os IIS authentication is stored in a blob called ISAP
    >> Extension Control Block - the ASPNET_ISAPI extension passes the token
    >> to ASP.NET (via WorkerRequest). This token is availabe in ASP.NET 2.0
    >> using the Request.LogonUserIdentity
    >>
    >> 2) There is some caching involved in IIS - but ASP.NET grabs the
    >> impersonation token on each request from IIS to populate
    >> Context.User.
    >>
    >> HTH
    >> ---------------------------------------
    >> Dominick Baier - DevelopMentor
    >> http://www.leastprivilege.com
    >>> When a user visits a web site and is authenticated through the popup
    >>> dialog box (Windows authentication) he enters his username and
    >>> password. Evidently this creates the users impersonation token that
    >>> is used on subsequent requests to secured web pages. On subsequent
    >>> requests the WindowsAuthenticationModule is what authenticates on
    >>> each request. The code that does this looks like this:
    >>>
    >>> WindowsIdentity wi = new
    >>> WindowsIdentity(ctx.WorkerRequest.GetUserToken(),
    >>> text2, WindowsAccountType.Normal, true);
    >>> Context.User = new WindowsPrincipal(wi);
    >>> The questions are:
    >>> 1. Where did the initial Windows authentication put the user
    >>> impersonation
    >>> token?
    >>> 2. Where is the user impersonation token stored as the user makes
    >>> web
    >>> page
    >>> requests(or is it generated on each request and if so how?)?
    >>> Thanks,
    >>> Gery
    >>> EnQue Corporation
    >>> www.EnQue.com
    >>> www.ImagingHardware.com
     
    Dominick Baier [DevelopMentor], Oct 11, 2005
    #4
  5. Hi Dominick,

    Do you know what the header is that contains the authentication information
    as I think that is what I am looking for? The ISAPI authorization filter I
    am looking at calls the ServerSupportFuntion with the HSE_REQ_EXEC_URL
    request with another parameter that contains the impersonation token...The
    docs don't say what header(s) get set that contain this information.

    The ISAPI authentication filter (CustomAuth from IIS 6 resource kit) is for
    using a web page to do Windows authentication so that the IE dialog is no
    longer used.

    Thanks,
    Gery

    --
    Gery D. Dorazio
    Development Engineer

    EnQue Corporation
    www.EnQue.com
    www.ImagingHardware.com

    "Dominick Baier [DevelopMentor]" <>
    wrote in message news:...
    > Hello Gery,
    >
    > first of all the browser never tries to authenticate if he doesn't need
    > to - when you hit a page where you don't have anonymous access - IIS
    > bounces back a 401 to the client along with the possible authentication
    > methods.
    >
    > From that point on the browser sends the authentication information as a
    > header to the server on each request.
    >
    > download www.fiddlertool.com and try the different authentication settings
    > in IIS - you can see the headers flowing back and forth. A good testpage
    > to test the various settings can be found here:
    > http://www.leastprivilege.com/UpdatedShowContextsAndRequestLogonUserIdentity.aspx
    >
    > ---------------------------------------
    > Dominick Baier - DevelopMentor
    > http://www.leastprivilege.com
    >
    >> Hi Dominick,
    >>
    >> Thanks for the feedback. Can you explain a little more with respect to
    >> IIS?
    >>
    >> Here is the scenareo that has me stumped and really the reason for the
    >> post:
    >>
    >> 1) User requests a restricted page and the Windows popup dialog
    >> appears so
    >> the user logs in and is authenticated. Then the page is served up.
    >> 2) The user then clicks on another secured page link and is directed
    >> to that
    >> page...no popup since he is already authenticated.
    >> Here is a question that may hit the core of the problem:
    >>
    >> How does IIS handle authenticated Windows accounts during
    >> client-server requests to a web server?
    >>
    >> Here is my thinking as to what happens and the source of my confusion:
    >>
    >> When an HTTP request is finished and the response is sent back to the
    >> client the worker thread is finished and recycled...at least that's
    >> how I understand it. Along with this understanding the server then
    >> would have no knowledge whether the user is logged in....eg http is
    >> stateless. Then for subsequent requests IIS would have to log them in
    >> automatically for each request since they already logged in once. But
    >> what happens on the next request? Where does IIS (or some ISAPI
    >> authentication filter/extension) get the information to re-logon the
    >> user? Translated....where is this: ctx.WorkerRequest.GetUserToken()
    >> getting its user token from?...is it stored in a header, an encrypted
    >> cookie passed back and forth between client and server?...all this is
    >> only in regards to Windows authentication and not ASP.NET forms
    >> authentication since I know that is encrypted in a forms cookie...
    >>
    >> Thanks and hope this is clear,
    >>
    >> Thanks,
    >> Gery
    >> EnQue Corporation
    >> www.EnQue.com
    >> www.ImagingHardware.com
    >> "Dominick Baier [DevelopMentor]"
    >> <> wrote in message
    >> news:...
    >>
    >>> Hello Gery,
    >>>
    >>> 1) The outcome os IIS authentication is stored in a blob called ISAP
    >>> Extension Control Block - the ASPNET_ISAPI extension passes the token
    >>> to ASP.NET (via WorkerRequest). This token is availabe in ASP.NET 2.0
    >>> using the Request.LogonUserIdentity
    >>>
    >>> 2) There is some caching involved in IIS - but ASP.NET grabs the
    >>> impersonation token on each request from IIS to populate
    >>> Context.User.
    >>>
    >>> HTH
    >>> ---------------------------------------
    >>> Dominick Baier - DevelopMentor
    >>> http://www.leastprivilege.com
    >>>> When a user visits a web site and is authenticated through the popup
    >>>> dialog box (Windows authentication) he enters his username and
    >>>> password. Evidently this creates the users impersonation token that
    >>>> is used on subsequent requests to secured web pages. On subsequent
    >>>> requests the WindowsAuthenticationModule is what authenticates on
    >>>> each request. The code that does this looks like this:
    >>>>
    >>>> WindowsIdentity wi = new
    >>>> WindowsIdentity(ctx.WorkerRequest.GetUserToken(),
    >>>> text2, WindowsAccountType.Normal, true);
    >>>> Context.User = new WindowsPrincipal(wi);
    >>>> The questions are:
    >>>> 1. Where did the initial Windows authentication put the user
    >>>> impersonation
    >>>> token?
    >>>> 2. Where is the user impersonation token stored as the user makes
    >>>> web
    >>>> page
    >>>> requests(or is it generated on each request and if so how?)?
    >>>> Thanks,
    >>>> Gery
    >>>> EnQue Corporation
    >>>> www.EnQue.com
    >>>> www.ImagingHardware.com

    >
    >
     
    Gery D. Dorazio, Oct 11, 2005
    #5
  6. Dominick,

    It looks like this is an IIS question now. I am going to look around over on
    the IIS.Security newsgroup and possibly post over there also.

    Thanks,
    Gery

    --
    Gery D. Dorazio
    Development Engineer

    EnQue Corporation
    www.EnQue.com
    www.ImagingHardware.com

    "Dominick Baier [DevelopMentor]" <>
    wrote in message news:...
    > Hello Gery,
    >
    > first of all the browser never tries to authenticate if he doesn't need
    > to - when you hit a page where you don't have anonymous access - IIS
    > bounces back a 401 to the client along with the possible authentication
    > methods.
    >
    > From that point on the browser sends the authentication information as a
    > header to the server on each request.
    >
    > download www.fiddlertool.com and try the different authentication settings
    > in IIS - you can see the headers flowing back and forth. A good testpage
    > to test the various settings can be found here:
    > http://www.leastprivilege.com/UpdatedShowContextsAndRequestLogonUserIdentity.aspx
    >
    > ---------------------------------------
    > Dominick Baier - DevelopMentor
    > http://www.leastprivilege.com
    >
    >> Hi Dominick,
    >>
    >> Thanks for the feedback. Can you explain a little more with respect to
    >> IIS?
    >>
    >> Here is the scenareo that has me stumped and really the reason for the
    >> post:
    >>
    >> 1) User requests a restricted page and the Windows popup dialog
    >> appears so
    >> the user logs in and is authenticated. Then the page is served up.
    >> 2) The user then clicks on another secured page link and is directed
    >> to that
    >> page...no popup since he is already authenticated.
    >> Here is a question that may hit the core of the problem:
    >>
    >> How does IIS handle authenticated Windows accounts during
    >> client-server requests to a web server?
    >>
    >> Here is my thinking as to what happens and the source of my confusion:
    >>
    >> When an HTTP request is finished and the response is sent back to the
    >> client the worker thread is finished and recycled...at least that's
    >> how I understand it. Along with this understanding the server then
    >> would have no knowledge whether the user is logged in....eg http is
    >> stateless. Then for subsequent requests IIS would have to log them in
    >> automatically for each request since they already logged in once. But
    >> what happens on the next request? Where does IIS (or some ISAPI
    >> authentication filter/extension) get the information to re-logon the
    >> user? Translated....where is this: ctx.WorkerRequest.GetUserToken()
    >> getting its user token from?...is it stored in a header, an encrypted
    >> cookie passed back and forth between client and server?...all this is
    >> only in regards to Windows authentication and not ASP.NET forms
    >> authentication since I know that is encrypted in a forms cookie...
    >>
    >> Thanks and hope this is clear,
    >>
    >> Thanks,
    >> Gery
    >> EnQue Corporation
    >> www.EnQue.com
    >> www.ImagingHardware.com
    >> "Dominick Baier [DevelopMentor]"
    >> <> wrote in message
    >> news:...
    >>
    >>> Hello Gery,
    >>>
    >>> 1) The outcome os IIS authentication is stored in a blob called ISAP
    >>> Extension Control Block - the ASPNET_ISAPI extension passes the token
    >>> to ASP.NET (via WorkerRequest). This token is availabe in ASP.NET 2.0
    >>> using the Request.LogonUserIdentity
    >>>
    >>> 2) There is some caching involved in IIS - but ASP.NET grabs the
    >>> impersonation token on each request from IIS to populate
    >>> Context.User.
    >>>
    >>> HTH
    >>> ---------------------------------------
    >>> Dominick Baier - DevelopMentor
    >>> http://www.leastprivilege.com
    >>>> When a user visits a web site and is authenticated through the popup
    >>>> dialog box (Windows authentication) he enters his username and
    >>>> password. Evidently this creates the users impersonation token that
    >>>> is used on subsequent requests to secured web pages. On subsequent
    >>>> requests the WindowsAuthenticationModule is what authenticates on
    >>>> each request. The code that does this looks like this:
    >>>>
    >>>> WindowsIdentity wi = new
    >>>> WindowsIdentity(ctx.WorkerRequest.GetUserToken(),
    >>>> text2, WindowsAccountType.Normal, true);
    >>>> Context.User = new WindowsPrincipal(wi);
    >>>> The questions are:
    >>>> 1. Where did the initial Windows authentication put the user
    >>>> impersonation
    >>>> token?
    >>>> 2. Where is the user impersonation token stored as the user makes
    >>>> web
    >>>> page
    >>>> requests(or is it generated on each request and if so how?)?
    >>>> Thanks,
    >>>> Gery
    >>>> EnQue Corporation
    >>>> www.EnQue.com
    >>>> www.ImagingHardware.com

    >
    >
     
    Gery D. Dorazio, Oct 11, 2005
    #6
  7. Gery D. Dorazio

    Ken Schaefer Guest

    Credentials are in the Authorization: header sent from client -> server.
    (unless you are using Passport authentication which is cookie based, or
    using client certificates etc).

    Again, using the HTTP Fiddler tool mentioned earlier will help you look at
    these things.

    Cheers
    Ken


    "Gery D. Dorazio" <> wrote in message
    news:...
    : Hi Dominick,
    :
    : Do you know what the header is that contains the authentication
    information
    : as I think that is what I am looking for? The ISAPI authorization filter I
    : am looking at calls the ServerSupportFuntion with the HSE_REQ_EXEC_URL
    : request with another parameter that contains the impersonation token...The
    : docs don't say what header(s) get set that contain this information.
    :
    : The ISAPI authentication filter (CustomAuth from IIS 6 resource kit) is
    for
    : using a web page to do Windows authentication so that the IE dialog is no
    : longer used.
    :
    : Thanks,
    : Gery
    :
    : --
    : Gery D. Dorazio
    : Development Engineer
    :
    : EnQue Corporation
    : www.EnQue.com
    : www.ImagingHardware.com
    :
    : "Dominick Baier [DevelopMentor]" <>
    : wrote in message news:...
    : > Hello Gery,
    : >
    : > first of all the browser never tries to authenticate if he doesn't need
    : > to - when you hit a page where you don't have anonymous access - IIS
    : > bounces back a 401 to the client along with the possible authentication
    : > methods.
    : >
    : > From that point on the browser sends the authentication information as a
    : > header to the server on each request.
    : >
    : > download www.fiddlertool.com and try the different authentication
    settings
    : > in IIS - you can see the headers flowing back and forth. A good testpage
    : > to test the various settings can be found here:
    : >
    http://www.leastprivilege.com/UpdatedShowContextsAndRequestLogonUserIdentity.aspx
    : >
    : > ---------------------------------------
    : > Dominick Baier - DevelopMentor
    : > http://www.leastprivilege.com
    : >
    : >> Hi Dominick,
    : >>
    : >> Thanks for the feedback. Can you explain a little more with respect to
    : >> IIS?
    : >>
    : >> Here is the scenareo that has me stumped and really the reason for the
    : >> post:
    : >>
    : >> 1) User requests a restricted page and the Windows popup dialog
    : >> appears so
    : >> the user logs in and is authenticated. Then the page is served up.
    : >> 2) The user then clicks on another secured page link and is directed
    : >> to that
    : >> page...no popup since he is already authenticated.
    : >> Here is a question that may hit the core of the problem:
    : >>
    : >> How does IIS handle authenticated Windows accounts during
    : >> client-server requests to a web server?
    : >>
    : >> Here is my thinking as to what happens and the source of my confusion:
    : >>
    : >> When an HTTP request is finished and the response is sent back to the
    : >> client the worker thread is finished and recycled...at least that's
    : >> how I understand it. Along with this understanding the server then
    : >> would have no knowledge whether the user is logged in....eg http is
    : >> stateless. Then for subsequent requests IIS would have to log them in
    : >> automatically for each request since they already logged in once. But
    : >> what happens on the next request? Where does IIS (or some ISAPI
    : >> authentication filter/extension) get the information to re-logon the
    : >> user? Translated....where is this: ctx.WorkerRequest.GetUserToken()
    : >> getting its user token from?...is it stored in a header, an encrypted
    : >> cookie passed back and forth between client and server?...all this is
    : >> only in regards to Windows authentication and not ASP.NET forms
    : >> authentication since I know that is encrypted in a forms cookie...
    : >>
    : >> Thanks and hope this is clear,
    : >>
    : >> Thanks,
    : >> Gery
    : >> EnQue Corporation
    : >> www.EnQue.com
    : >> www.ImagingHardware.com
    : >> "Dominick Baier [DevelopMentor]"
    : >> <> wrote in message
    : >> news:...
    : >>
    : >>> Hello Gery,
    : >>>
    : >>> 1) The outcome os IIS authentication is stored in a blob called ISAP
    : >>> Extension Control Block - the ASPNET_ISAPI extension passes the token
    : >>> to ASP.NET (via WorkerRequest). This token is availabe in ASP.NET 2.0
    : >>> using the Request.LogonUserIdentity
    : >>>
    : >>> 2) There is some caching involved in IIS - but ASP.NET grabs the
    : >>> impersonation token on each request from IIS to populate
    : >>> Context.User.
    : >>>
    : >>> HTH
    : >>> ---------------------------------------
    : >>> Dominick Baier - DevelopMentor
    : >>> http://www.leastprivilege.com
    : >>>> When a user visits a web site and is authenticated through the popup
    : >>>> dialog box (Windows authentication) he enters his username and
    : >>>> password. Evidently this creates the users impersonation token that
    : >>>> is used on subsequent requests to secured web pages. On subsequent
    : >>>> requests the WindowsAuthenticationModule is what authenticates on
    : >>>> each request. The code that does this looks like this:
    : >>>>
    : >>>> WindowsIdentity wi = new
    : >>>> WindowsIdentity(ctx.WorkerRequest.GetUserToken(),
    : >>>> text2, WindowsAccountType.Normal, true);
    : >>>> Context.User = new WindowsPrincipal(wi);
    : >>>> The questions are:
    : >>>> 1. Where did the initial Windows authentication put the user
    : >>>> impersonation
    : >>>> token?
    : >>>> 2. Where is the user impersonation token stored as the user makes
    : >>>> web
    : >>>> page
    : >>>> requests(or is it generated on each request and if so how?)?
    : >>>> Thanks,
    : >>>> Gery
    : >>>> EnQue Corporation
    : >>>> www.EnQue.com
    : >>>> www.ImagingHardware.com
    : >
    : >
    :
    :
     
    Ken Schaefer, Oct 11, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Cronus
    Replies:
    1
    Views:
    676
    Paul Mensonides
    Jul 15, 2004
  2. G Fernandes
    Replies:
    1
    Views:
    531
  3. Wessi
    Replies:
    3
    Views:
    862
    Lawrence Kirby
    Aug 11, 2005
  4. =?Utf-8?B?Y2FzaGRlc2ttYWM=?=

    This is an unexpected token. The expected token is 'NAME'

    =?Utf-8?B?Y2FzaGRlc2ttYWM=?=, Jul 13, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    784
    =?Utf-8?B?Y2FzaGRlc2ttYWM=?=
    Jul 13, 2007
  5. J
    Replies:
    0
    Views:
    1,555
Loading...

Share This Page