The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

IHttpModule Context.User.Identity.IsAuthenticated

I would like to implement an intercept filter so that anyone not yet authenticated go into a guest list.

the problem is
application.Context.User
is null.

anyone with any solutions? httpmodule makes the most sense to put this logic at.

PHP Code:

using System;
using System.Collections;
using System.Collections.Generic;
using System.Data;
using System.Data.Common;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

never mind here is my solution

PHP Code:

using System;
using System.Collections;
using System.Collections.Generic;
using System.Data;
using System.Data.Common;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

I would double check the sources on the SqlMembershipProvider, but I doubt that they are storing anything in the Session. Its too unreliable for stuff as important as Membership.

Also---I would highly advise not catching exceptions like you are catching them. That will just truncate the stack trace and leave you wondering what went wrong. I would just skip the catch clause there, unless you are going to do something with it. If you do want to throw an exception you have caught, use throw by itself:

First, that was pretty much off the cuff example code--more likely one would see something like this:

Code:

catch
{
transaction.RollBack();
throw;
}

The real point being that catching should do something rather than just rethrow an error.

As for your example, that is great--when your code knows it is in a website with a IHttpApplication floating around. But when you are writing core components that get used across services, one should definitely avoid needing to know that said application exists, but one might want to attach logging functions deeper down the stack.

On global exception handling, my general philosophy is don't handle--log it and push users to a friendly error page. And now, with the new WebEvent stuff in ASP.NET 2.0, you can handle the logging bits from configuration rather than from the code.