3

I run an Azure web role in Full IIS mode. Requests are authorized with custom basic authentication.

I have MyAssembly.CustomIdentity class that inherits from System.Security.Principal.GenericIdentity. When HttpApplication.AuthenticateRequest handler (OnEnter() code from the link above) is invoked it performs checks, then creates an instance of MyIdentity.CustomIdentity and assigns it to HttpContext.Current.User. Then an actual ASP.NET request handler obtains that object and can use it to find what user it is for.

Now everything more or less works fine in default configuration when IIS is running under NETWORK SERVICE account. During role startup I restart IIS application pool under a local user (to grant it extra privileges). Now even the following code

public partial class Default : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        bool isAvailable = Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.IsAvailable;
    }
}

will throw various exceptions. First it says it can't serialize my CustomIdentity class (which I fix by adding Serializable attribute), then it says it can't load MyAssembly assembly (which I fix by handling AppDomain.AssemblyResolve event).

What I don't get is why serialization kicks in? Why running the application pool under s local user and invoking that trivial code suddenly trigger serialization?

sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • 2
    you haven't changed session management from inproc to sql have you? – Daniel Powell Jun 27 '11 at 12:22
  • @Daniel Powell: No idea. How do I check that and what is that? – sharptooth Jun 27 '11 at 12:23
  • should be in your web config, its how sessions gets stored, inproc is basically on the local server memory and you can get away with things not being serialised, when its set to sql anything stored in the session needs to be serialised http://msdn.microsoft.com/en-us/library/ms972429.aspx – Daniel Powell Jun 27 '11 at 12:32
  • Do you do anything with events that might impact this? The biggest cause of unexpected data via BinaryFormatter is events. – Marc Gravell Jun 27 '11 at 12:39
  • @Marc Gravell: I guess, I don't do anything at all. – sharptooth Jun 27 '11 at 12:49

3 Answers3

4

EDIT Re-reading your question, I'm not so sure this is the issue. I'm leaving it here because I spent 5 minutes writing it, and it's useful info :) If you're writing web-apps, you need to know about session state and your storage options!

As Daniel Powell says, it's very likely that you are storing an instance of your object in the session state.

ASP.NET applications have 3 standard modes for storing session state. InProc (in-process) stores it in memory, so no serialization is required. StateServer or SqlServer will attempt to serialize the session state to either an ASP.NET State Server or a SQL server respectively.

To confirm that this is the issue you will need to check what the mode attribute of the sessionState element is in the web.config file.

<sessionState mode="InProc|SqlServer|StateServer" />

If you are using SQL Server or State Server, then your application will be serializing the entire session state at the end of every request. You have a few options here:

  1. Change your session state to InProc. This will prevent the serialization, but you will not be able to use a load-balanced environment. Also, if your application restarts, all users will lose their session (as it is held in memory).

  2. Stop putting this object in the Session. If you don't need to store this object in the Session, then don't! Problem solved.

  3. Make the object, and any child elements of it, serializable, by implementing ISerializable. This will not be possible if the object uses "live" elements such as database connections, etc.

RB.
  • 36,301
  • 12
  • 91
  • 131
1

Be cautious with this answer, as I am not absolutely sure it is the good one.

First, I assume you haven't set up something like sql session management, and the only thing you changed is the user under which IIS is running.

You observe two phenomenon:

  1. Serialization of an object which shouldn't be serialized
  2. Loading of your assembly by an AppDomain which hasn't already loaded it.

As your appdomain has already loaded the assembly, it seems safe to assume that the exception is thrown by another AppDomain. If it is thrown by another Appdomain, it's probably because this AppDomain is attempting to deserialize your custom object. (It has been serialized before the other exception demonstrates that.)

OK. Now even if IIS is running under a local user, Role environnement isn't. This service is installed with the Azure OS, you can't choose the user it runs under (you could probably in fact, but I wouldn't)

What I think is that in order to get informations from RoleEnvironnement, the Azure runtime is able to use two code paths:

  1. One if the IIS service and Runtime are running under the same user, which doesn't require appdomain switching.
  2. another if the IIS service and runtime doesn't share the user they are running under. In this case, the runtime requires it, as the two user doesn't have the same rights.

To conclude, I certainly don't know why the Azure runtime would like to move your user between different AppDomain, but it is probably doing exactly that.

Eilistraee
  • 8,220
  • 1
  • 27
  • 30
0

Is this related to the following connect bug:

https://connect.microsoft.com/VisualStudio/feedback/details/712500/cant-use-appdomains-inside-wcf-called-methods

XIU
  • 804
  • 7
  • 11