COMP3121 E-Commerce Technologies

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

2. 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

3. Ways to Connect server scripts to a Database • Two methods: • use a specific control with each script page • 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…

4. 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

5. 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

6. 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

7. 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)

8. 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

9. 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

10. 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

11. 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…)

12. 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

13. 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… (!)

14. 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

15. 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

16. 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

17. “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

18. 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

19. 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…

20. 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 server-side code customise system to work with WebXel controls

21. 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

22. Passing “emailaddress” parameter to get customer data Logon page Getcust page EmailAddress value captured Customer fields displayed Remote DB Compare with value extracted from table; if yes populate cart & other scripts Shopping Cart customerID fields extracted from remote database

23. “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)

24. 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

25. 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…. 