Non-Interrupting Logins

Discussion in 'ASP .Net' started by kaburke, Aug 16, 2005.

  1. kaburke

    kaburke Guest

    My application is a simple create/update/delete system, with user
    authentication. Everything is working well, except session timeouts are
    creating user-experience nightmares.

    The standard workflow of my application is as follows:

    Login -> View Items -> Edit Item -> Save Item

    The following should be noted about each step:
    1) Login
    The login is a customized version of the FormsAuthentication. It
    accesses a database to retrieve user information, and uses
    FormsAuthentication.SetAuthCookie/Server.Transfer instead of
    FormsAuthentication.RedirectFromLoginPage.
    2) View Items
    A list of items is retrieved from a database and displayed in a DataList
    control.
    3) Edit Item
    The user clicks on an edit button in the DataList control from step (2),
    and is taken to a separate form to edit the information (in-line editing is
    not being used).
    4) The user clicks a save button, which persists the data to the database
    and takes the user back to the View Items page.

    As I said, everything is working. The problem I am having is when the user
    takes a long time editing the item and his session times out. In such a case
    the flow is as follows:

    Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item

    This is all well and good, except that upon return to the Edit Item page,
    the form values the user has entered are no longer there, so the user must
    re-enter the data. Ideally the flow should be:

    Login -> View Items -> Edit Item -> Click Save -> Login -> Persist Data to
    DB -> View Items

    assuming validation passes, otherwise

    Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item

    with the form filled out and any viewstate-dependant controls rehydrated.

    Any ideas as to how I can accomplish this?

    Thanks,
    --kaburke
    kaburke, Aug 16, 2005
    #1
    1. Advertising

  2. kaburke

    Lucas Tam Guest

    "kaburke" <> wrote in
    news:kTsMe.223841$on1.47537@clgrps13:

    > This is all well and good, except that upon return to the Edit Item
    > page, the form values the user has entered are no longer there, so the
    > user must re-enter the data. Ideally the flow should be:
    >
    > Login -> View Items -> Edit Item -> Click Save -> Login -> Persist
    > Data to DB -> View Items
    >
    > assuming validation passes, otherwise
    >
    > Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item
    >
    > with the form filled out and any viewstate-dependant controls
    > rehydrated.
    >
    > Any ideas as to how I can accomplish this?


    I don't think you can easily persist the data on a session timeout.

    I would just raise the timeout value to >20 minutes or add some custom
    javascript to keep the page alive.

    --
    Lucas Tam ()
    Please delete "REMOVE" from the e-mail address when replying.
    http://members.ebay.com/aboutme/coolspot18/
    Lucas Tam, Aug 17, 2005
    #2
    1. Advertising

  3. kaburke

    kaburke Guest

    Persisting the filled values themselves doesn't seem to be too difficult.
    Currently, when a user is redirected to the login page (because his session
    has timed out), I iterate through all of the Form and Querystring parameters
    and print out a hidden field for each one. Upon submission of the login
    form, the user is sent back to the page of origin (using Server.Transfer),
    whereupon the OnInit of my Page class (it is actually the OnInit of a base
    class from which all of my pages inherit) loops through the submitted hidden
    fields and rehydrates any relevant controls in the Page.

    The problem I am now trying to overcome is persistance of the ViewState
    information. For example, the form contains a DataList whose enableViewState
    property is set to true - when the user is sent back to the form, however,
    the DataList is not repopulated. Any ideas as to how I can accomplish this?

    Thanks,
    --kaburke

    "Lucas Tam" <> wrote in message
    news:Xns96B4CD8273F92nntprogerscom@127.0.0.1...
    > "kaburke" <> wrote in
    > news:kTsMe.223841$on1.47537@clgrps13:
    >
    >> This is all well and good, except that upon return to the Edit Item
    >> page, the form values the user has entered are no longer there, so the
    >> user must re-enter the data. Ideally the flow should be:
    >>
    >> Login -> View Items -> Edit Item -> Click Save -> Login -> Persist
    >> Data to DB -> View Items
    >>
    >> assuming validation passes, otherwise
    >>
    >> Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item
    >>
    >> with the form filled out and any viewstate-dependant controls
    >> rehydrated.
    >>
    >> Any ideas as to how I can accomplish this?

    >
    > I don't think you can easily persist the data on a session timeout.
    >
    > I would just raise the timeout value to >20 minutes or add some custom
    > javascript to keep the page alive.
    >
    > --
    > Lucas Tam ()
    > Please delete "REMOVE" from the e-mail address when replying.
    > http://members.ebay.com/aboutme/coolspot18/
    kaburke, Aug 17, 2005
    #3
  4. kaburke

    jasonkester Guest

    Coming back from the login page, you'll need to give yourself enough
    information to pull the page context out of temporary storage, right?
    Since you've already got a branch set up to put the fields back in
    place, why not repopulate and rebind at the same time? Unless your
    DataList is particularly expensive to rebuild, I don't see much value
    in trying to freeze & thaw the ViewState.

    Jason Kester
    Expat Software Consulting Services
    http://www.expatsoftware.com/
    jasonkester, Aug 17, 2005
    #4
  5. kaburke

    kaburke Guest

    With a DataList that may be the best option, but with other controls such a
    technique may be irritating and cumbersome. On the form, for example I have
    labels whose values change to reflect UI state (e.g., whether the record
    being represented is "dirty"). For example (using the "dirty" scenario), the
    Page_Load sets the label's text to "Unmodified," but when the contents of
    any control on the form are changed, the label is changed to "Modified." In
    such a case it would be far more convenient to merely "thaw," as you say,
    the ViewState, rather than have to analyse the record for changes upon
    redirection from the login page. This is particularly true as I would like
    to implement a generic means of maintaining state through a Session Timeout
    (i.e., on this page I have a "dirty" label, but elsewhere what needs to be
    preserved will be entirely different, and I don't want to have to implement
    custom rehydration code for every page).

    Thanks,
    --kaburke

    "jasonkester" <> wrote in message
    news:...
    > Coming back from the login page, you'll need to give yourself enough
    > information to pull the page context out of temporary storage, right?
    > Since you've already got a branch set up to put the fields back in
    > place, why not repopulate and rebind at the same time? Unless your
    > DataList is particularly expensive to rebuild, I don't see much value
    > in trying to freeze & thaw the ViewState.
    >
    > Jason Kester
    > Expat Software Consulting Services
    > http://www.expatsoftware.com/
    >
    kaburke, Aug 17, 2005
    #5
  6. kaburke

    kaburke Guest

    I found the solution to my problem here:

    http://www.codeproject.com/aspnet/PersistentStatePage.asp

    My situation was not identical to the scenario outlined in the article, but
    the methods described where easily translated.

    Thanks,
    --kaburke

    "kaburke" <> wrote in message
    news:kTsMe.223841$on1.47537@clgrps13...
    > My application is a simple create/update/delete system, with user
    > authentication. Everything is working well, except session timeouts are
    > creating user-experience nightmares.
    >
    > The standard workflow of my application is as follows:
    >
    > Login -> View Items -> Edit Item -> Save Item
    >
    > The following should be noted about each step:
    > 1) Login
    > The login is a customized version of the FormsAuthentication. It
    > accesses a database to retrieve user information, and uses
    > FormsAuthentication.SetAuthCookie/Server.Transfer instead of
    > FormsAuthentication.RedirectFromLoginPage.
    > 2) View Items
    > A list of items is retrieved from a database and displayed in a
    > DataList control.
    > 3) Edit Item
    > The user clicks on an edit button in the DataList control from step
    > (2), and is taken to a separate form to edit the information (in-line
    > editing is not being used).
    > 4) The user clicks a save button, which persists the data to the database
    > and takes the user back to the View Items page.
    >
    > As I said, everything is working. The problem I am having is when the user
    > takes a long time editing the item and his session times out. In such a
    > case the flow is as follows:
    >
    > Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item
    >
    > This is all well and good, except that upon return to the Edit Item page,
    > the form values the user has entered are no longer there, so the user must
    > re-enter the data. Ideally the flow should be:
    >
    > Login -> View Items -> Edit Item -> Click Save -> Login -> Persist Data to
    > DB -> View Items
    >
    > assuming validation passes, otherwise
    >
    > Login -> View Items -> Edit Item -> Click Save -> Login -> Edit Item
    >
    > with the form filled out and any viewstate-dependant controls rehydrated.
    >
    > Any ideas as to how I can accomplish this?
    >
    > Thanks,
    > --kaburke
    >
    kaburke, Aug 18, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    4
    Views:
    897
    Roland
    Jan 27, 2005
  2. Noozer

    Interrupting navigation.

    Noozer, Mar 25, 2006, in forum: HTML
    Replies:
    13
    Views:
    591
    Noozer
    Mar 26, 2006
  3. William
    Replies:
    1
    Views:
    598
    Jack Klein
    Mar 28, 2005
  4. J. W. McCall

    Canceling/interrupting raw_input

    J. W. McCall, Apr 18, 2005, in forum: Python
    Replies:
    2
    Views:
    808
    Daniel Cer
    Apr 18, 2005
  5. stephan
    Replies:
    1
    Views:
    296
    Andrew Dalke
    May 1, 2005
Loading...

Share This Page