Carrying form values without cookies or sessions.

[G]

Hello,

Is it possible to send form values from PAGE1 to PAGE2, and then retain the
form info for PAGE3 without using cookies, sessions or DB storage? Also, I
dont want to repost page2 to page3 using hidden form fields.

Just curious! Want to know how to "simply" maintain user form inputs across
a web site even when security and privacy controls are set to MAXIMUM on the
browser. I know using databases would do it, but I would love to find a
simpler solution.

Gary.

[Ken Schaefer]

You need some way to maintain state. HTTP is a stateless mechanism.

so you need to either:
a) use some kind of hidden page storage
b) use some kind of capability of the browser (eg cookies)
c) use some kind of storage capability of the server (eg a database, or ASP
sessions). However, you are stil stuck with the problem of associating the
stored data with the user's next request. Even ASP Sessions rely on the
browser accepting an ASPSessionID cookie that contains the Session's ID
value. This needs to be returned on the next request, so IIS can associate
the browser with their existing session.

Cheers
Ken

"G" <no**********@here.com> wrote in message
news:c3*******************@news.demon.co.uk...
: Hello,
:
: Is it possible to send form values from PAGE1 to PAGE2, and then retain
the
: form info for PAGE3 without using cookies, sessions or DB storage? Also,
I
: dont want to repost page2 to page3 using hidden form fields.
:
: Just curious! Want to know how to "simply" maintain user form inputs
across
: a web site even when security and privacy controls are set to MAXIMUM on
the
: browser. I know using databases would do it, but I would love to find a
: simpler solution.
:
: Gary.
:
:

[G]

> so you need to either:

a) use some kind of hidden page storage
b) use some kind of capability of the browser (eg cookies)
c) use some kind of storage capability of the server (eg a database, or ASP sessions). However, you are stil stuck with the problem of associating the
stored data with the user's next request. Even ASP Sessions rely on the
browser accepting an ASPSessionID cookie that contains the Session's ID
value. This needs to be returned on the next request, so IIS can associate
the browser with their existing session.

So, No? :)

[Fawke101]

Hi,

I take it that the site is supposed to be pretty secure.
Could you not use a querystring, passing the values in the URL from page to
page?
Or is this not what you were looking for?

I suggest you look at implementing another solution (as opposed to ASP) if
you require this functionality, as Ken stated the points in ASP. (take a
look at Coldfusion, there are some very useful tags that allow this kind of
security and form maintenance)

Hope this helps

--

Fawke

Please remove ANTI and SPAM
from my email address before emailing me.

www.bradflack.com
"G" <no**********@here.com> wrote in message
news:c3*******************@news.demon.co.uk...

so you need to either:
a) use some kind of hidden page storage
b) use some kind of capability of the browser (eg cookies)
c) use some kind of storage capability of the server (eg a database, or

ASP

sessions). However, you are stil stuck with the problem of associating the stored data with the user's next request. Even ASP Sessions rely on the
browser accepting an ASPSessionID cookie that contains the Session's ID
value. This needs to be returned on the next request, so IIS can associate the browser with their existing session.

So, No? :)

[Phillip Windell]

Since you have eliminated most forms of doing this, the Hidden Form Fields
is about the only ASP method you have left yourself.
--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
"G" <no**********@here.com> wrote in message
news:c3*******************@news.demon.co.uk...

so you need to either:
a) use some kind of hidden page storage
b) use some kind of capability of the browser (eg cookies)
c) use some kind of storage capability of the server (eg a database, or

ASP

sessions). However, you are stil stuck with the problem of associating the stored data with the user's next request. Even ASP Sessions rely on the
browser accepting an ASPSessionID cookie that contains the Session's ID
value. This needs to be returned on the next request, so IIS can associate the browser with their existing session.

So, No? :)

[Phillip Windell]

Nevermind,..I see you've eliminated those as well.
--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
"Phillip Windell" <@.> wrote in message
news:#5**************@TK2MSFTNGP11.phx.gbl...

Since you have eliminated most forms of doing this, the Hidden Form Fields
is about the only ASP method you have left yourself.
--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
"G" <no**********@here.com> wrote in message
news:c3*******************@news.demon.co.uk...

so you need to either:
a) use some kind of hidden page storage
b) use some kind of capability of the browser (eg cookies)
c) use some kind of storage capability of the server (eg a database, or

ASP

sessions). However, you are stil stuck with the problem of associating the stored data with the user's next request. Even ASP Sessions rely on

the browser accepting an ASPSessionID cookie that contains the Session's ID value. This needs to be returned on the next request, so IIS can

associate the browser with their existing session.

So, No? :)

[G]

"Phillip Windell" <@.> wrote in message
news:eF**************@TK2MSFTNGP11.phx.gbl...

Nevermind,..I see you've eliminated those as well.

lol ;)
Just wanted to see if there was another way, thought I would eliminate all
the methods I knew of and see which clever boffin could come up with
another...

G.

[Chris Hohmann]

"G" <no**********@here.com> wrote in message
news:c3*******************@news.demon.co.uk...

"Phillip Windell" <@.> wrote in message
news:eF**************@TK2MSFTNGP11.phx.gbl...

Nevermind,..I see you've eliminated those as well.
lol ;)
Just wanted to see if there was another way, thought I would eliminate

all the methods I knew of and see which clever boffin could come up with
another...

G.

You didn't disclude the Application scope. So, you could generate a GUID
(globally unique identifier) and store an XML representation of the
state in the Application scope under that GUID. Then pass around the
GUID in the action attribute of your forms.

-Chris Hohmann

[Ravichandran J.V.]

1. Server.Transfer
2. Using the Cache object. Put the values into the cache
Cache.Insert("<key",value)
3. Use inheritance as all ASPX pages are classes.

with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Ken Schaefer]

At some point though, you still need to send something to the client (and
have the client return it), so that the server can maintain session state.

In which case, you might as well use hidden form fields, or cookies, or one
of the other things mentioned.

Cheers
Ken

"Chris Hohmann" <no****@thankyou.com> wrote in message
news:Oh****************@TK2MSFTNGP11.phx.gbl...
: "G" <no**********@here.com> wrote in message
: news:c3*******************@news.demon.co.uk...
: >
: > "Phillip Windell" <@.> wrote in message
: > news:eF**************@TK2MSFTNGP11.phx.gbl...
: > > Nevermind,..I see you've eliminated those as well.
: >
: > lol ;)
: > Just wanted to see if there was another way, thought I would eliminate
: all
: > the methods I knew of and see which clever boffin could come up with
: > another...
: >
: > G.
:
: You didn't disclude the Application scope. So, you could generate a GUID
: (globally unique identifier) and store an XML representation of the
: state in the Application scope under that GUID. Then pass around the
: GUID in the action attribute of your forms.
:
: -Chris Hohmann
:
:

[Chris Hohmann]

"Ken Schaefer" <ke*******@THISadOpenStatic.com> wrote in message
news:u4**************@TK2MSFTNGP11.phx.gbl...

At some point though, you still need to send something to the client (and have the client return it), so that the server can maintain session state.
In which case, you might as well use hidden form fields, or cookies, or one of the other things mentioned.

The OP indicated that he did not want to use hidden form fields,
cookies, sessions or DB. The scenario I proposed uses none of these. The
GUID associated with the state is passed via the form's action
attribute. I am not endorsing this methodology, I am simply offering up
a solution that meets the OP's requirements.

-Chris Hohmann

[Roland Hall]

"G" wrote in message news:c3*******************@news.demon.co.uk...
: Is it possible to send form values from PAGE1 to PAGE2, and then retain
the
: form info for PAGE3 without using cookies, sessions or DB storage? Also,
I
: dont want to repost page2 to page3 using hidden form fields.
:
: Just curious! Want to know how to "simply" maintain user form inputs
across
: a web site even when security and privacy controls are set to MAXIMUM on
the
: browser. I know using databases would do it, but I would love to find a
: simpler solution.

You can use FSO to write it to and read from a file on the server. This
doesn't use cookies, sessions or db storage. One would assume you do not
want text file storage either but eventually you will be out of options.
You will have to make sure you have CHANGE rights in the directory you're
storing the file and outside the web root is preferred.

HTH...

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Ken Schaefer]

"Chris Hohmann" <no****@thankyou.com> wrote in message
news:e1**************@tk2msftngp13.phx.gbl...
: "Ken Schaefer" <ke*******@THISadOpenStatic.com> wrote in message
: news:u4**************@TK2MSFTNGP11.phx.gbl...
: > At some point though, you still need to send something to the client
: (and
: > have the client return it), so that the server can maintain session
: state.
: >
: > In which case, you might as well use hidden form fields, or cookies,
: or one
: > of the other things mentioned.
:
: The OP indicated that he did not want to use hidden form fields,
: cookies, sessions or DB. The scenario I proposed uses none of these. The
: GUID associated with the state is passed via the form's action
: attribute. I am not endorsing this methodology, I am simply offering up
: a solution that meets the OP's requirements.

So, you're passing it in the querystring. You could, I suppose, just pass
everything in the querystring - which was mentioned earlier.

Cheers
Ken

[Chris Hohmann]

"Ken Schaefer" <ke*******@THISadOpenStatic.com> wrote in message
news:uP**************@tk2msftngp13.phx.gbl...

"Chris Hohmann" <no****@thankyou.com> wrote in message
news:e1**************@tk2msftngp13.phx.gbl...
: "Ken Schaefer" <ke*******@THISadOpenStatic.com> wrote in message
: news:u4**************@TK2MSFTNGP11.phx.gbl...
: > At some point though, you still need to send something to the client : (and
: > have the client return it), so that the server can maintain session : state.
: >
: > In which case, you might as well use hidden form fields, or cookies, : or one
: > of the other things mentioned.
:
: The OP indicated that he did not want to use hidden form fields,
: cookies, sessions or DB. The scenario I proposed uses none of these. The : GUID associated with the state is passed via the form's action
: attribute. I am not endorsing this methodology, I am simply offering up : a solution that meets the OP's requirements.

So, you're passing it in the querystring. You could, I suppose, just pass everything in the querystring - which was mentioned earlier.

There are limits to how much data can be passed via the querystring.

-Chris Hohmann