1

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.
  • surely the normal solution is to add the original url to the query string and redirect there after login success. I'm not sure from your question why this doesnt work for you? – Ewan Oct 2 '15 at 9:00
  • @Ewan: The original URL isn't sufficient information, since a given URL will usually have multiple resources. – Brian Oct 2 '15 at 12:55
  • dynamically add the extra request data as hidden fields to the login form so the full request can be rebuilt? – Ewan Oct 2 '15 at 13:14
  • 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). – Brian Oct 2 '15 at 13:23
  • sounds tricky. I guess a 'clean' approach would be one where you loose the state and extra data. hard to do in a webforms system – Ewan Oct 2 '15 at 13:42
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.