1. COMP3121 E-Commerce Technologies Richard Henson University of Worcester November 2011

2. Week 9: Mechanism of an on-line Shopping System, Part 2 n Objectives:  Apply principles of customer login to asp.net, and shopping cart systems  Complete a system that saves customer orders, and orderlines to database, before allowing an on-line purchase to proceed to payment

3. Customer Registration n 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…  however if a customerID is obtained, and email address obtained, the clicking behaviour can be put in a wider context

4. Registration & Logon Systems n General shopping site principle:  anyone with a valid email address can apply for and get a login n Alternative approaches:  automatically accept all users who provide their own unique username/password  administrator posts username/ password to a real email address

5. Restricting access to a group of pages (1) n A Login page 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… n If user doesn’t bother to login, they don’t get access to the restricted pages

6. Restricting access to a group of pages (2) n Initial request for login achieved via “registration page”  would-be users submit their details and request a username & password… »either auto-allocation of requested username/password offers no restriction »or sending email to user with username/password offers some degree of control and accountability n Can also be used in conjunction with SSL (to prevent viewing data “in transit”)

7. Creating a Registration System (1) n Essential component: “HTML” form/“web form”  collects user information…  saves to one or more tables in a server database n Other essentials:  a “check user” function, to make sure the user doesn’t get 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

8. Creating a Registration Page (2) n User registration data is private…  should be sent to database only via a secure connection n Web tools like Dreamweaver & Visual Studio have wizards & templates for registration/login systems that use server scripting  allows easy production of registration forms linked to tables in relational databases  but lack flexibility… often a need for some hard coding

9. Creating a Registration System using WebXelCart controls

10. WebXel Controls for Login/Registration n Use with form  to save details of new customers n Use with form  for authentication of existing users »uses password data provided (with masking!) »compares username/password data with existing data

11. “Checking the Password” n Very easy to make a typo!!!  not helpful if the typo is in your password… n 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… n Coded by simple “if” statement, with the “else” return the registration page where the user has to retype the password  achieved on a web controls through “postback” of the rest of the data, so only the password is retyped

12. Coding the Login page (1) n Data typed into the form isn’t written to database…  a server script compares it with existing database records  searches by contents of relevant field…  achieved through SQL query n On successful comparison…  a session variable is generated, based on username »allows access to the restricted pages »in an e-commerce site, this will be the on-line invoice and subsequent pages to complete the transaction

13. Saving the Order n Happens when user clicks on “checkout”  and becomes a true customer… n Uses the WriteToDB control  But (unlike the customer handling scripts) »writes Cart fields to database not form fields »writes to Orders table, not Customer table

14. Saving Order Details n Also happens when customer accepts the order (by clicking “checkout”) n Handled by WebXelCart:SaveOrder control  works in a similar way to WritetoDB  but writes cart fields to the ORDERITEMS table n Important differences between WritetoDB and SaveOrder in this coding:  WriteToDB writes cart fields  SaveOrder writes form field contents

15. Creating a login page for different access levels n Different users can be given different levels of access to resources, based on username  e.g. only users can be identified as “administrators” »using a user category field in the customers/users table  administrators may be able to access a further HTML form or webform »allows write access the products table »can add new product details »and change details (e.g. price) of an existing product

16. Restricting page access to unauthorized users n Essential to prevent the unauthorised user “cheating” the system by typing in the URL of the restricted page and displaying it manually n Readily achieved using a server script that automatically brings the user back to a pre- defined page if they HAVEN’T successfully logged on  e.g. takes control back to the home page

17. Restricted Pages and Secure Pages (2) n Such an intercept and redirect facility will ONLY protect HTML pages  problem: HTML can easily be hacked… n Secure pages use the https protocol, and are protected from the server end by a server (SSL) certificate

18. https, and e-commerce systems n Before payment, the user will also have to be authenticated by the International Banking Network (IBN) before payment can proceed  this MUST happen at a fully protected page »via https »logged in checking »(additionally) a system-defined “time out”  control then passes to a merchant services provider for interaction with the IBN n more about https in the Internet Security module… COMP3123-7,8 on RH’s website

19. Order information and the Merchant System n At least one parameter needs to be passed with the credit/debit card details  this is “GrandTotal”  saved in Orders Table n Needs to be used to check whether the customer has enough funds in their account to allow the transaction…