Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Non-Interrupting Logins

Reply
Thread Tools

Non-Interrupting Logins

 
 
kaburke
Guest
Posts: n/a
 
      08-16-2005
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


 
Reply With Quote
 
 
 
 
Lucas Tam
Guest
Posts: n/a
 
      08-17-2005
"kaburke" <(E-Mail Removed)> 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 ((E-Mail Removed))
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
 
Reply With Quote
 
 
 
 
kaburke
Guest
Posts: n/a
 
      08-17-2005
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" <(E-Mail Removed)> wrote in message
news:Xns96B4CD8273F92nntprogerscom@127.0.0.1...
> "kaburke" <(E-Mail Removed)> 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 ((E-Mail Removed))
> Please delete "REMOVE" from the e-mail address when replying.
> http://members.ebay.com/aboutme/coolspot18/



 
Reply With Quote
 
jasonkester
Guest
Posts: n/a
 
      08-17-2005
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/

 
Reply With Quote
 
kaburke
Guest
Posts: n/a
 
      08-17-2005
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> 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/
>



 
Reply With Quote
 
kaburke
Guest
Posts: n/a
 
      08-18-2005
I found the solution to my problem here:

http://www.codeproject.com/aspnet/Pe...tStatePage.asp

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

Thanks,
--kaburke

"kaburke" <(E-Mail Removed)> 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
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SQL Server 2000 question: What's the relationship between users and logins Leonard Martin MCSD 0 12-05-2005 09:15 PM
Wireless link not established until user logins on Windows 2000 Server Rob Nicholson Wireless Networking 2 11-29-2005 07:16 PM
AS5300: Preventing multiple logins of the same account Pavlov Cisco 0 11-23-2004 04:39 PM
Disallowing Logins to Routers Matt Cisco 1 05-21-2004 03:55 PM
Does PIX 515, Version 6.3.1 Support simultaneous logins? Jason Cisco 2 04-28-2004 07:21 PM



Advertisments