How can I cleanly handle a several permutations of Resource Request, (Optional) Login Control, Resource Result?

Question

Whenever a user interacts with a resource while not logged in, I need to:

1. Redirect them to a secure page.
2. Show a signup/login dialog (which is usually partially customized based on the resource, and may have a link to a no-login version of the resource).
3. Send the user to the resource (if they login).

This is a relatively common/simple problem, but unfortunately there are several wrinkles:

1. There are several types of resources, each of which has a slightly different login control.
2. Some of the resources require customized business logic and/or login controls.
3. Some user states require customized business logic and/or login controls.

My current approach, grown organically over time by multiple developers:

1. When a user requests a resource, the resource object does one or more of the following:
   A) Stuff a state object into the user's session.
   B) Craft a query string based on the current state and on the requested resource.
   C) Direct the user to a secure page.
2. Other controls on the page detect A-C. One of these controls renders a login dialog.
3. The login dialog sends the user to the resulting page.

This works, but has several problems:

1. The code responsible for handling resource requests is entirely independent from the code generating the requests. Effectively, the state object is a user-specific global variable.
2. The code responsible for handling resource requests for logged in users is heavily separated from the code handling resource requests for unlogged in users, even though it is heavily overlapping. Note that this is a problem of indirection (i.e., code duplication is mostly avoided in favor of layers of indirection and heavily nested calls to shared code).
3. The code is somewhat fragile; there are a lot of ways it can break.

How can I clean this up? I've contemplating adding an Action (or a state machine) to the state object. This would give the resource request object has direct control over the resource result object, rather than indirect control through the login control. However, that really doesn't strike me as sufficient to simplify the logic.

Notes:

1. I'm using asp.net webforms with .Net 4.0.
2. I don't care if the session object is serializable.

Answer 1

The problem I'm trying to solve is how to give the request result the data more cleanly; the login form already has the data, but that's why it's complicated; the data is being ferried from the resource request to the login form to the resource result. Also, keep in mind that the login form is completely independent from the resource request (and a given resource may be connectable to more than one login form, depending on context).

It turns out 90% of this can be solved by

1. Changing the originating URL into an SSL page.
2. Changing the redirect into a postback.
3. On click, setting the target of the form to _blank

The key I was missing was #3. Otherwise, business logic rules like, "continue this flow in a new window" require ferrying the data.