what are the three "core/key skills"?

Download Report

Transcript what are the three "core/key skills"?

COMP3121
E-Commerce Technologies
Richard Henson
University of Worcester
November 2012
Week 9: Mechanism of Shopping
System, Part 2

Objectives:
 Apply principles of user registration login to the
shopping cart system
 Explain the logic of creating, storing, and displaying
customer orders online
 Implement principles of online registration to the
asp.net client-server environment
 Create a system that saves client-server customer
orders, and orderlines to and recalls them from a
remote database
Ways to Connect server
scripts to a Database

Two methods:
1. use a specific control with each script
page
2. include a path (or connectivity string) to
the database in the web.config file, which
will be available to all pages, and their
controls

Method 1 is more “portable”; method 2
more economical in use of code…
WebXel controls and
Database Connectivity


WebXel uses web.config
WebXel controls require a specific label for
the connectivity string as a property of the
control (don’t recognise “AccessDataSource”)
 “constr” was used by default; could be anything

Once the web.config file is working correctly,
can use constr as OleDB link for all WebXel
controls
Customer Registration
and Marketing

A user that shows an interest in purchasing
goods from an e-commerce site needs to be
authenticated in some way
 can use cookies to store “clicking” behaviour on
their website based on computerID, even if not
registered as a user…
» according to EU Law, use of cookies must be declared, and the
user must give permission
 if a customerID is obtained, and email address
obtained, the clicking behaviour on the cookie can
be put in a wider context
Registration & Logon Systems

General website principle:
anyone with a valid email address can
apply for and get a login
user needs to see some advantage to
them of registering
» e.g. contribute to a blog
» e.g. access “restricted” pages
Alternative approaches to
providing login data


System automatically accepts all users who
provide their own unique
username/password
Administrator posts username/password to
a real email address
» can then validate the email address (particularly important
for e-commerce)
Requirements for a
Registration System (1)

“Login” link gives an option for
previously registered users to gain
access to “restricted” pages
could be presented at:
» “home” page
» payment page
» every page in the site…

If user doesn’t bother to login, they don’t
get access to the restricted pages
Requirements for a
Registration System (2)



“Registration” link required to take new
users to a “registration page”
User submit details, usually including a
username
Some systems:
 allow user to choose their own password
password…
» may be validated against password strength rules

Others send an email to user with
username and auto-generated password
Allocation of Passwords and
Data Protection


Passwords are amongst the most sensitive
data a user can supply to a computer system
Highly illegal to reveal someone’s password
without their permission
 HUGE confusion about this…

If the system generates the password and
sends it to the user’s email address…
 offers some degree of control and accountability
 passes responsibility to user to manage that
password
Logging on
through the Internet

Further responsibility of registration
system providers is to protect user data
ESPECIALLY passwords!
Should be stored encrypted
 Should be sent through the Internet
encrypted

use https and SSL (next semester’s
Information Security module…)
Creating a Registration System (1)

Essential components: HTML forms & web
controls
 collects new user information
 validates data obtained
 saves to one or more tables in a server database

Other essentials of registration:
 a “check user” function, to make sure the user
doesn’t choose a username that has already been
taken
 a mechanism to make sure the password is correct
» usually getting users to type it in twice and comparing
responses before saving/rejecting
Creating a Registration Page (2)

Use a wizard…
 Dreamweaver & Visual Studio have wizards &
templates for creating registration/login pages for
systems that use server scripting
 allows easy production of registration forms linked
to tables in relational databases

But wizards are generalised solutions
 May lack flexibility needed to fulfil specific
requirements
 non-experts don’t get this
 continuing problem for industry… (!)
Doing it Properly



Understand requirements and where the
wizards fall short…
Enhance the generated code until it does
what the user needs it to do
Many, many systems have been produced
using wizards that aren’t much good to the
client…
 clients should complain more but massive public
ignorance about computer code
WebXel Controls for
Login/Registration


WebXel designed to extend .net controls to
include specific functionality requirements of
online shopping systems with cart as session
cookie
Login/registration controls:
 <WebXel:WritetoDB> with form
» saves details of new customers to cart then database
» puts details of existing customers into cart then screen
 <WebXel:Login> with form
» authentication of existing users
» uses password data provided (with masking!)
» compares username/password data with existing data
Registration Page

For “new customer” mode:
form fields defined using textbox
controls
field names need to mesh with
parameters listed in WritetoDB

For “existing customer”
“Eval” command used to extract data
directly from database
“Checking the Password”

Very easy to make a typo!!!
 not helpful if the typo is in your password…

Registration systems therefore always request that
password is initially entered twice:
 entries can then be compared…
 unlikely that the same typo would happen in the same place
twice…

Coded by simple “if” statement, with the “else” return
the registration page where the user has to retype the
password
 achieved via web control through “postback” of the rest of
the data from cookie, so only the password is retyped
Coding the Login (1)

Only two fields used:
 Username (in practice, emailaddress)
 password

Data typed into the form isn’t written to database…
 a server script compares field contents with existing database
records
 searches by contents of relevant field…
 achieved through SQL query

On successful comparison…
 a session variable is generated, based on username allows
access to the restricted pages
» in an e-commerce site, these will be the on-line invoice and
subsequent pages to complete the transaction
Response to Successful Login


A web control now uses the authenticated
username (email address) to extracts existing
data from the customer table and display it
This provides an option for the customer to edit
this…
 complies with requirements of Data Protection Act
» customers must be presented with options to update their
personal data
 also in the business’s own interest
» e.g. otherwise they could send mail etc. to the wrong address…
Implementation of “existing
customer data”
Visual Studio web controls provide
“bare bones” of such functionality…
 WebXel provides further controls:

WebXel:Login and WebXel:WritetoDB

Need additional C# embedded serverside code customise system to work
with WebXel controls
WebXel “cart” storage

Several field names used in Customers table:
 Emailaddress
 Firstname
 surname
 Address
 Password



Need to be stored from database into the cookie
Need to be displayed on getcust and passed as
parameters to the cookie
Names need to “mesh” for smooth data passing
Passing “emailaddress”
parameter to get customer data
Getcust
page
Customer
fields
displayed
EmailAddress
value captured
Logon
page
Remote
DB
Shopping Cart
customerID
Compare with
value extracted
from table; if
yes populate cart
& other scripts
fields extracted
from remote
database
“Insert” or “Update”

C# code used with WritetoDB control
 creates a system that works for new customers
and existing customers using the same form (!)
 mechanism is to use an SQL query with “yes/no”
response to a check for username
» if yes… run update “method”
» if no… run insert “method”

Assumes use of connectivity string within
web.config (constr by default)
Consequence of
“Update” option


If the username exists, existing customer
details need to be extracted, added to the
cookie, and displayed
Existing customer now required to submit
password
 again SQL check against database
 action taken depends on result…
» incorrect password generates error message and screen “posted
back”.
» correct password
Consequence of
WebXel Login

Once customer data is validated…
 contents of shopping cart can now become an order

Further WebXel control WebXel:SaveOrder
 uses order data, customer data, and product data to
product the online invoice…


May be frustrating to some but this will be dealt
with…
Next Week…. 