Enhancing Online Shopping: Security and Registration Mechanisms for E-Commerce Systems

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

2. Week 9: Mechanism of an on-line Shopping System, Part 2 • Objectives: • Explain why it is important that some pages are restricted • Apply principles of customer login to asp.net, and shopping cart systems • Produce a system that forces customer login, or registration, before allowing an on-line purchase to proceed

3. Common Features of Shopping Cart Systems • Repeating from last week… • Many shopping cart systems available • Code written in many different languages • Basic features mostly the same • five data fields that make up a local dataset • description & price fields interact with a remote product database • further fields added to the local dataset to store results of calculations

4. Use of .net Web Controls • Many available within VWD • click-and-drag… • properties set directly frrom VWD environment • Others created outside VWD • included using dlls • need to know properties of such controls in order to set parameters

5. WebXel Controls • Several controls “assembled” into compiled code as WebXelCart.dll • <WebXelCart> • <WebXelCart:AddFromDB> • <WebXelCart:WriteToDB> • <WebXelCart:Login> • <WebXelCart:SaveOrder>

6. Registration • Principles of a basic login/registration system in asp.net apply to all scripting languages • including server scripting… • Required to authenticate a user that shows an interest in purchasing goods from their site • 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

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

8. Restricting access to a group of pages - 1 • 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… • If user doesn’t bother to login, they don’t get access to the restricted pages

9. Restricting access to a group of pages - 2 • Initial request for login is achieved through a “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 • Can also be used in conjunction with SSL (prevent viewing “in transit”)

10. Creating a Registration Page (1) • Main component: (HTML form or “web form”) • collects user information… • saved to one or more tables in a server database • Needs to have: • 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

11. Creating a Registration Page (2) • Such user data is private, and should be sent to database only via a secure connection • Web tools like Dreamweaver have templates for some scripting languages (e.g. asp) • allows easy production of registration forms linked to tables in relational databases

12. Creating a Registration Page in asp.net • More care is needed than when using interpreted languages • best way is to use web controls • e.g. WebXel has embedded controls that help with this process • As with all forms, the data boxes must have corresponding database fields for the data to be written to…

13. WebXel Controls for Login/Registration • Use <WebXel:WritetoDB> • to save details of new customers • Use <WebXel:Login> • authentication of existing users • uses password data provided (with masking!) • compares username/password data with existing data

14. “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… • Coding is a simple “if” statement, but the “else” must return the user to the registration page to retype the password • web controls can easily restore (or “postback”) the rest of the data, so only the password is retyped

15. Creating a Login page (1) • Another HTML form or Web form… • Data typed in isn’t written to database, but a server script compares it with an existing database entry (should be the primary key) • On successful comparison… • a session variable is generated, based on username • allows access to the restricted pages

16. Creating a Login page (2) • Different users can be given different levels of access, based on username • e.g. only users can be identified as “administrators” • using a user category field on the database • could then access a HTML form or webform based product editing system • and e.g, change the price of a product

17. Restricting page access to authorized users (1) • Essential to prevent the unauthorised user “cheating” the system by typing in the URL of the restricted page and displaying it manually • Readily achieved using a server behaviour/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

18. Restricted Pages and Secure Pages (2) • An intercept and redirect facility will ONLY protect HTML pages • and HTML can easily be hacked… • Secure pages use a separate https protocol, and are protected from the server end by a server (SSL) certificate • the user will have to be authenticated by the system, and then by the International Banking Network before payment can proceed • more about this currently in the Internet Security module… welcome to “drop in…”