Redirection maintaining GET and POST data

[mark007]

I've searched around a bit but can't find anything that has handled POST data. There are numerous examples of the easy scenario of GET data.

 

I have a Login Control that I place on each of my pages. This control checks the session to see if a user is loggedin or not and if they are set a LoggedIn property of the control to true so that the page the control is on can display the content and hide the login control or vice versa.

 

If the login control is displayed they enter their username and password and hit login. The credentials are checked and any errors reported or the user is logged in. On being logged in the page can then be displayed.

 

However I'm considering the scenario where someone is logged in and enters lots of details into a form to the extent that the session expires while they are doing this. They then hit submit and the form is posted back. The login control notices the session no longer exists and sets loggedin to false so processing is halted and the login control displayed. They then enter their username and password and hit login.

 

How can I now access the data they originally filled in on the form. Clearly if it was simple data that used GET then I could just store the querystring. However posted data seems to be a different animal altogether. Any ideas?

 

Help very much appreciated.

 

:)

[djjaan]

When login control finds out that there was POST, and session is ended, You still know the user's ID, IP address etc... also You should be able to gather POST data.

Serialize it, store it some safe place. When same user comes back, either fill form with unserialized data, or even better, ask if he/she wants to continue editing the form. Hope you got my point ;)

[mark007]

When login control finds out that there was POST, and session is ended, You still know the user's ID, IP address etc...

 

How do I still know the userid etc.?

 

Serialize it, store it some safe place.

 

What safe place did you have in mind? And what key could I use to access it again when they have logged in again?

 

:)

[djjaan]

How do I still know the userid etc.?

Use for example ASP.NET Sessions to store User_ID, and IP address. If newly logged in User_ID and IP match with previous, then you are good to go.

 

What safe place did you have in mind

Database, filesystem, application cache ... you name it.

 

And what key could I use

* create GUID when user starts editing the form, and include it in ViewState

* When session ends on POST, store the POST data with GUID

* Redirect to login page, with GUID in parametes

* After successful login, redirect back to form, with GUID in param

* When form finds GUID in param, it tries to re-fill the form

 

puh, this was looooong, wasn't it ;)

BTW: I am not trying to do the work for you, instead, give some tips and ideas.

PS:Sorry for my bad english :(

[mark007]

I by no means expect you to do the work for me!!!

 

I still don't see how this works:

 

Use for example ASP.NET Sessions to store User_ID, and IP address. If newly logged in User_ID and IP match with previous, then you are good to go.

 

But the whole point is that the session has expired so I no longer have these session details.....I therefore don't know who the user is.

 

Thinking it through though I guess a possibility is to do it kind of backwards to your suggestion:

 

1) Store the data

2) Place the key used for storing this data into thenewly created session

3) When they login check if an "OldPostData" item exists in the sessions collection.

4) If so then obtain the data back

 

This should work I think.

 

Would also need a session_end event (or whatever it's called) to check for the existence of the "OldPostData" key and if so delete the data under this key. Or perhaps a safer way might be to have a cleanup whereby data over 1 day old is deleted...

 

The user should then only have trouble if they take time to login - in which case tough!

 

Thanks for the ideas, it got me thinking.

 

:)

[djjaan]

Would also need a session_end event (or whatever it's called) to check for the existence of the "OldPostData" key and if so delete the data under this key. Or perhaps a safer way might be to have a cleanup whereby data over 1 day old is deleted...

 

I hope the following example gives you a hint.

Cache.Insert("My GUID", objSerializedPostData, Nothing, DateTime.Now.AddDays(1))

[mark007]

Yes, could use the cache I guess.

 

The danger is it's deleted sooner than expected due to lack of memory though. Hopefully this would be fine though so I might well go with this.

 

Thanks for the suggestion.

 

:)

[HJB417]

use an authentication (such as forms authentication) and store they login information in a cookie. you shouldn't be using a session to determine if a user has logged in or not and that was your first mistake.

[mark007]

forms authentication isn't flexible enough for what I want. I don't believe that it will maintain the post data anyway from my reading of it.

 

Also what's wrong with checking a session to see if someone is logged in? A session is effectively a cookie i.e. it comes via a cookie but main data stored on the server.

[HJB417]

Also what's wrong with checking a session to see if someone is logged in?

 

 

more than often, the session cookie outlives the session. You could automate the login process by storing the credentials in a cookie.

[mark007]

Yep, I may do that but I'm not sure whether I want to yet for security reasons.

 

I got everything I wanted to work working anyway so all seems good so far. Now just looking into some Custim Server controls for the menu.

 

:)

[HJB417]

there is no secure way really. use ssl or encrypt the data that's going to be stored in the cookie.

And also, another thing about determining if a user is logged in by using sessions is, what if the session state is disabled. Unfortunately, the machine.config has session state enabled by default and I think it has let to some poor app design/implementation choices.

[mark007]

You're quite anti-sessions aren't you ;)

 

Not really sure what you mean - but fundamentally I don't see an issue in using sessions unless MS mucked something up in their implementation. I use them all the time in PHP.

 

:)

[HJB417]

people sometimes 'misuse' it, such as using the session state to perform authenticaton. That's all. But also, when I create asp.net applications, I disable everything and then I enable only what is needed. I'm not antisession, I just try to be efficient @ runtime.

[mark007]

people sometimes 'misuse' it, such as using the session state to perform authenticaton.

 

Do you consider what I'm doing misuse?

 

Fundamentally using a session is just using a cookie for an id and storing the data for that id on the server right? Where's the problem in checking part of that server stored data for a loggedin property for example?

 

Don't get me wrong here, I'm not trying to prove you wrong or argue with you. Just want to see where potential flaws are...

 

:)

[HJB417]

so using your web app, when my session expires after 20min or whatever you set it at, assuming it's in proc, I will have to reenter my username and password?

[mark007]

Only if you haven't used the app in the last 20 minutes.

 

The PC's this will be run on may well be multiuser so a permanent cookie isn't really an option.

 

:)

[HJB417]

Only if you haven't used the app in the last 20 minutes.

And there lies the problem, I feel someone shouldn't have to reneter their credentials each time the web application is re/started or their session state expires.

When I create web applications that use both authentication and sessions, I re/create the session objects/data if they don't already exist.

[mark007]

Like I say it's not possible to store a persistent cookie with details as the machines are multiuser.

[HJB417]

didn't stop every forum on the internet and you can make it an option for user to have their login cookied but it's your app and u can do what you want.

[mark007]

I know, I have a similar option on my own forum. I just don't think it's applicable to this app. Thanks for the comments though! :)

[wessamzeidan]

You can also increase the session timeout period. One thing I want to note is that if your user needs more than 20 minutes to fill out a form, then I think you should reconsider designing your data entry form to span multiple forms, thats IMO.

[mark007]

Sure, if was a questionnaire type form I would. But it will be making changes to large amounts of data in a large textbox - no way round it. It's not that I expect people to take 20 minutes with it though anyway. More that it's quite likely to start then get interrupted by a phone call and then resume after - easily passing 20 minutes.

 

:)

[VBAHole22]

My 2 cents:

 

What if the client machine is set to deny cookies and the user can't change the option?

 

And

Where exactly would one change the session timeout? There seem to be quite a few timeout settings littered throughout a solution and machine.config.

[wessamzeidan]

you can change the session timeout in the sessionState element in the Web.Config file