Which System is More Reliable?

  • Thread starter Thread starter Jonathan Wood
  • Start date Start date
J

Jonathan Wood

In the same online ordering system mention in my other posts, I'm still
trying to decide the best way to track items in the shopping cart, before
the order has officially been placed.

So far, I've been favoring using a combination of Session and ViewState.
However, I know that Sessions can be reset for a variety of reasons and am
wondering if I should be using the database instead.

But is using a database more reliable? Sure, the data would be more secure,
but I need to track an ID that would identify which records were associated
with the current user. If the Session reset, then my SessionID could also
and I'd lose my connection between the current user and the products they
were ordering.

I'd love to hear anyone else's thoughts on this.

Thanks!

Jonathan
 
For most systems that require a single-sign on or span multiple domains, I
create an authentication web service which all the sites have access to.
The authentication service returns an encrypted GUID, User ID, datetime
created and datetime of expiration.
This GUID is written to a client cookie and is re-validated with every
postback to the same site by using an IHTTPModule.

When crossing from one site to another, the Encrypted Cookie / GUID is
appended to the URL (or as form post data) and then re-authenticated using
teh same method at teh new site (which creates its own client-side cookie)

Each site then sends these credentials to whatever shopping cart web service
you create, in order to store order information.

If you need to do Price Overrides, simply create a price override web
service (removing the processs from exposure to the client).

When it's time for checkout, the checkout web service simply updates each
item they purchased with a date purchased field, order number and anything
else you require.

To test the theory of it all, just make two web applications on different
domains and practice creating a single-sign on solution using a web service
for authentication.
Once that's done, the rest is fairly academic.

William
 
I hate sites that require me to log in in order to give them my money and
won't be requiring this of my customers. PayPal supports this behavior so my
approach is not without precedence.

So, you're saying each approach has similar reliability, assuming I don't
require a login?

Thanks.

Jonathan
 
Create a unique pre-account-creation-ID for each customer that is used just
while they are browsing and shopping. Save that ID in a client-side cookie.
Use this ID to pass around and only associate it with a verified user ID
when it's time for checkout.

All a user name and password does is verify a user id, that doesn't infer
that not everyone gets one before they sign in.

William

Jonathan Wood said:
I hate sites that require me to log in in order to give them my money and
won't be requiring this of my customers. PayPal supports this behavior so
my approach is not without precedence.

So, you're saying each approach has similar reliability, assuming I don't
require a login?

Thanks.

Jonathan
Click to expand...
 
Hi William,
For most systems that require a single-sign on or span multiple domains, I
create an authentication web service which all the sites have access to.
The authentication service returns an encrypted GUID, User ID, datetime
created and datetime of expiration.
This GUID is written to a client cookie and is re-validated with every
postback to the same site by using an IHTTPModule.
Click to expand...

That sounds like a pretty good suggestion there. I've already considered
that Web services might be able to play a couple of roles related to the
project I'm working on. Unfortunately, I've yet to write a Web service and
still have some issues about it that I'm unclear on. So it might not make my
current timeframe for that reason. But ultimately, I'd like to incorporate
them, and the way you've described sounds really good to me.

(Note: At the heart of my project are routines that provide registration
codes for my shareware. If that were implemented using Web services, I could
allow resellers to access these routines. And, by requiring a password of
some type, my code could track how much commission I should be expecting
from each reseller!)
When crossing from one site to another, the Encrypted Cookie / GUID is
appended to the URL (or as form post data) and then re-authenticated using
teh same method at teh new site (which creates its own client-side cookie)

Each site then sends these credentials to whatever shopping cart web
service you create, in order to store order information.

If you need to do Price Overrides, simply create a price override web
service (removing the processs from exposure to the client).

When it's time for checkout, the checkout web service simply updates each
item they purchased with a date purchased field, order number and anything
else you require.

To test the theory of it all, just make two web applications on different
domains and practice creating a single-sign on solution using a web
service for authentication.
Once that's done, the rest is fairly academic.
Click to expand...

Yeah, it's the first part that would take me a bit of thought and I actually
need to get this working by Tuesday. But, ultimately, I think I should
consider the type of stuff you are suggesting to be my ultimate
implementation.

Thanks!

Jonathan
 
Hi William,
Create a unique pre-account-creation-ID for each customer that is used
just while they are browsing and shopping. Save that ID in a client-side
cookie.
Use this ID to pass around and only associate it with a verified user ID
when it's time for checkout.
Click to expand...

So, just to boil this down, you're saying that while the SessionID may
reset, a cookie is much less likely to be lost during the session? Is that a
fair statement?

If so, it sounds like, IF I made the decision to store the shopping cart in
the database (prior to checkout), it makes more sense to use a cookie
instead of the SessionID to associate cart items with the current user.

Thanks.

Jonathan
 
I'd suggest looking into it, it's actually *far* easier to learn (and
consume) than you might suspect.
I'd be shocked, judging by your current abilities, if it would take you more
than an hour or two to become fairly proficient at publishing and consuming
web services.

A lot of articles go a long way towards giving the impression that it
requires a sack lunch, a degree in astrophysics and carving pentagrams on
your keyboard to get them to work, but it's suprisingly painless and easy to
do.

William
 
Correct, a client-side cookie persists between visits to a domian.

Don't store sensetive data in them of course, just enough to know when it
was created, when it expires and to relate the cookie with the stored data.
Encrypt the contents of the cookie as well.

When they check out / log in to pay, just replace (or pop into a different
column) the temp ID with thier verified ID (and replace the ID in the cookie
with the verified one)

William
 
Hi William,
Correct, a client-side cookie persists between visits to a domian.

Don't store sensetive data in them of course, just enough to know when it
was created, when it expires and to relate the cookie with the stored
data.
Encrypt the contents of the cookie as well.

When they check out / log in to pay, just replace (or pop into a different
column) the temp ID with thier verified ID (and replace the ID in the
cookie with the verified one)
Click to expand...

Sounds good. The more I delve into this, the more problems I'm seeing. To
add to the complexity, you're really not allowed to store the credit card in
a database at all (unless you pay a fee to be certified that your technique
is sufficiently secured).

But I'm strongly considering moving the shopping cart to the database, and
using a cookie to associate the cart with the current user.

Jonathan
 
Yeah, I appreciate that. I've probably got some reading to do there before
I'd be comfortable implementing it as part of a payment system.

Thanks!

Jonathan
 
Back
Top