JavaScript PageMethods call loosing HttpContext.Current State

I am in a bit tricky situation. I am using JavaScript's PageMethod functionality where I am invoking a PageMethod which works like a gem. However I am having an issue in accessing the HttpContext's state which returns me a value "SYSTEM" for

HttpContext.Current.User.Identity.Name

which is not the actual current User Name.

I know there are couple options like storing HttpContext.Current in a Session or saving Context's state in some other custom container but given a web farm environment I am assuming that this will not work as expected.

Here is the code I am working on with

function MyFunction(){
    PageMethod.MyPageMethod();
}

here is the signature of the server method

    [System.Web.Services.WebMethod()]
    public static void MyPageMethod()
    {
       // gives me "SYSTEM"
       var user = HttpContext.Current.User.Identity.Name;
    }   

Also if I use the above code to access user name in OnLoad event of the page then it works fine and returns me the CurrentUserName.

I am trying to get the above code to work in an ASP.NET Webform... :)

So I am wondering if there is a way to access the current actual user in page methods without making use of sessions.

Any help will be deeply appreciated.

NiK...

After quite some reading I think I was trying to do something which is not correct as to how page methods work. It gets quite tricky when your application's authentication system is windows based and these page methods when you invoke from JavaScript will not cause a postback and do not invoke the HttpModules. Instead it just calls that page method.

FYI, we had our own custom HTTPModule to handle security.This is even before any other HttpModule occurs and this was not being invoked while calling the page method as we are not doing a postback or even a partial postback (so the whole "niche" of a HTTPPost was missing). Moreover this led to a conclusion that we were making service calls without any authentication and was potentially a big security issue for us.

The bottom line is it was a bad design, well having said that I would like to mention about the solution/workaround we came up with and here is what we did. So, the only option we had is to do a postback keeping the UI alive and we wanted to update a label's message asynchronously and we achieved it by doing a hack using Sys.Application.add_init.

<script language="javascript" type="text/javascript" >
    Sys.Application.add_init(function() {
        Sys.WebForms.PageRequestManager.getInstance().add_endRequest(endRequest);
    });  

      function beginProcess() {           
        processCurrentItem();
    }

       var currentItem = 0;
      function processCurrentItem() {
         if (currentItem < 5) {
            currentItem = currentItem + 1;
            __doPostBack('updatePanel', currentItem);                
        }
    }
     function endRequest() {
       processCurrentItem();
    }
    </script>

The markup we had in place was pretty simple with a label in the update panel and a button that invokes the "beginProcess()" function. Finally in the OnLoad we had the following code in place

protected override void OnLoad(EventArgs e)
    {
        if (this.IsPostBack)
        {               
           this.lblLabel.Text = "text you may wanna update with";
           // Call the Method you may wanna call 
           // also you may use Request["__EVENTARGUMENT"] to know who caused the 
           // postback and Request["__EVENTTARGET"] to access the argument you may 
           // have passed in. 
        }            
    }

And this solution is no longer using the JavaScript Page methods. And based on this solution if anyone thinks I am missing something here or think there is any other other way of doing this then do update this post with your suggestions.

• NiK