Using Session manager class in Global.asax
Long ago, I’ve written about Session Manager class. The class purpose was to wrap
session variables in properties and gain type safety to them.
In this class we’ve added a Session property with get accessor, which wraps the
HttpContext.Current.Session. Everything went well until I’ve encountered the need
to use this class on Session_End method in global.asax
Global.asax is not a regular Http Handler and therefore it doesn’t hold an HttpContext
This means that when going to the Session we’ve received our good old
NullReferenceException.
On global.asax there is access to the session variables but through it’s own Session
property.
So, what can we do?
One and not so recommended solution is skip the use of Session Manager and go directly
to the session variables in the old fashion way. That’s how you skip the type safety
provided by this class. This is not so recommended because of the type safety being broken
and code being replicated instead of being reuse
The other approach is to create Session property on the Session Manager class and set
it from the constructor. We’ll allow setting it from the constructor because we wouldn’t
want any unexpected corruption of this property.
And that’s how the constructor and the session property will look like:
public SessionManager(HttpSessionState session)
{
Session = session;
}
public virtual HttpSessionState Session
{ get;
private set;
}
All other properties we might want to put there, should stay exactly the same.
The Session property is virtual because if we would want to use it from our application’s pages
we’d like to inherit and use HttpContext.Current.Session
In order to use it from our regular pages (the one that holds HttpContext during their Load -->
Render lifecycle) we can inherit and override the Session property.
The code of the derived class will look like that:
public class CurrentContextSessionManager : SessionManager
{
public CurrentContextSessionManager()
:base(null)
{
}
public override HttpSessionState Session
{
get
{
return HttpContext.Current.Session;
}
}
}
Now we can gain back our type safety from SessionManager class. Here is
some example of how we can use the base class (a cleanup mechanism called
from Session_End).
protected void Session_End(object sender, EventArgs e)
{
ProductsBL productBL = new ProductsBL();
SessionManager sessiongManager = new SessionManager(this.Session);
productBL.ClearShoppingCart(sessiongManager.ShoppingCart);
}
Where Shopping cart is a property wraps a session variable.
Summary
Our Session Manager class is good to go from every page in our application until
we have to do some actions with it from Async Http handlers such as global.asax
In these cases we have to set our own Session property. For all other pages we
can use a derived class that gets it’s session from HttpContext.Current.Session.
At the end, everyone points at the same session variables, and our type safety
won’t harm.
404.2 and , ISAPI restriction and Web Service Extension
A common and very misleading http error is the status with code 404.2 .
It is misleading because it belongs to the 404 family which may indicate
that the resource was not found, however this error indicates that the
server has blocked our request by it’s lockdown policy.
The web server lockdown policy’s job is restrict the requests to a known
and valid pages / resources. For example, this is very rare to find servers
that allows you to run executable programs remotely by HTTP requests.
Another common scenario of request blocking is for known extension,
registered to an ISAPI executable which was not allowed by the server’s
configuration. The most common scenario I’ve encountered was that ASP.NET
4.0 ISAPI was not allowed. (occurs on machines installed initially without
.Net 4.0) One good examples for this scenario can be seen on Gil Fink’s post.
One other common scenario I’ve encountered was heaving to host Magic
application on IIS. Magic web application required a special ISAPI executable.
In order to do so, we have to add new extension and add the Magic’s ISAPI
DLL to it.
How can we configure these settings?
IIS 6: In here it is called Web Service Extensions, You can find it by clicking
it’s corresponding folder. You can allow or prohibit each extension.
In case of new extension, you need to press on the “Add new web service extension”
(circled above), and add the required file(s). You can also add / remove files and
and allow / prohibit each one of them.
IIS7: On that IIS, it called ISAPI & CGI restrictions. You can choose it by
clicking once on the server’s name, and then from feature view selecting
ISAPI & CGI restrictions (circled below)
The registration list looks a bit different from the extensions list on IIS6,
in here wee see every file on that list along with it’s description
By looking at the figure below you can see some description that repeat
themselves (like Web Service Extension in IIS6 that have more than one file).
Summary:
In this post we’ve seen the connection between IIS lockdown
(HTTP error No. 404.2), Web Service Extension and ISAPI
Restrictions. In fact, we’ve seen that installing the appropriate
ISAPI executable is not enough, we have also to allow it.
We’ve seen how to allow it on both IIS6 and IIS7
