|
|
Posted by Steve on 04/23/07 22:53
"Gordon Burditt" <gordonb.rxpjs@burditt.org> wrote in message
news:132qddgetht559f@corp.supernews.com...
|>| WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER SAID
| >| ABOUT THE USER LOGGING IN!
| >
| >imagine if you will/can, that the form carries a tag perhaps identifying
| >say, an ip address - i know it's a stretch for you. that would certainly
be
| >ONE way to marry an instance of data with a browser. input is stored in a
db
| >with each post/get. when that ip (in this instance) and its data was
| >analized, we could then still tell where the user left off - or what the
| >next step would be.
|
| Imagine that you subscribe to AOL, where consecutive web hits from
| your browser appear to come from different IP addresses. Imagine
| that you subscribe to a dialup ISP, where getting back the same IP
| address after the modem disconnects can take days of tries. Imagine
| that you sometimes access the Internet from different places, like
| home, work, and your cell phone, all of which have different IP
| addresses.
gee, imagine that each time you connect, you get a different session_id
regarless of ANY of these factors. imagine you actually go on now to explain
to me the architectual advantage OVER my suggestion(s) to db data rather
than session it.
as it is, the only time any of this becomes an issue with my suggested
architecture is when there is no login...but i guess that's why yall have
picked at that. under that scenario, AT BEST sessions are equal to db driven
steps...however you'll not be able to reuse your sessioning code in more
secure sencarios that i did layout where a login is required; nor will you
be able to scale sessioning data even if you were to port it to said
environment.
make a case that shows sessioning data is BETTER than db driven steps...then
you'll impress me. until then, you're just bitching trying to catch up.
Navigation:
[Reply to this message]
|