Redirection maintaining GET and POST data

M

mark007

Centurion
Joined
Jan 22, 2005
Messages
185
Location
York, UK
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.

:)
 
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 ;)
 
When login control finds out that there was POST, and session is ended, You still know the user's ID, IP address etc...
Click to expand...

How do I still know the userid etc.?

Serialize it, store it some safe place.
Click to expand...

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

:)
 
How do I still know the userid etc.?
Click to expand...
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
Click to expand...
Database, filesystem, application cache ... you name it.

And what key could I use
Click to expand...
* 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 :(
 
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.
Click to expand...

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.

:)
 
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...
Click to expand...

I hope the following example gives you a hint.
Code: 
Cache.Insert("My GUID", objSerializedPostData, Nothing, DateTime.Now.AddDays(1))
 
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.

:)
 
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.
 
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.
 
mark007 said:
Also what's wrong with checking a session to see if someone is logged in?
Click to expand...


more than often, the session cookie outlives the session. You could automate the login process by storing the credentials in a cookie.
 
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.

:)
 
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.
 
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.

:)
 
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.
 
people sometimes 'misuse' it, such as using the session state to perform authenticaton.
Click to expand...

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...

:)
 
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?
 
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.

:)
 
mark007 said:
Only if you haven't used the app in the last 20 minutes.
Click to expand...
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.
 
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.
 
Back
Top