13.07.2015 Views

Software Engineering for Internet Applications - Student Community

Software Engineering for Internet Applications - Student Community

Software Engineering for Internet Applications - Student Community

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Consider that if you're authenticating users over the phone thecontributions that might be most interesting are any new responsesto questions asked by that user.10.11 Exercise 6: Content Approval/Rejection byTelephoneMany Web sites have user-created content that must be approved byan administrator or moderator be<strong>for</strong>e it becomes live on the site.Examples are the product reviews at amazon.com, articlesubmissions at slashdot.org, and bulletin board postings in amoderated <strong>for</strong>um.Typically you'd open your Web browser, log in, and go to an adminpage from which you can approve, reject, or edit submissions.But it sure would be nice to approve and reject submissions with yourcellphone when you're out walking the dog. (Editing is harder to do byphone, but it's less common anyway, so it can wait until you're backat your desk.)Create some simple voice-accessible admin pages. Since the typicalusername/password authentication is so tedious, you might want tomake them accessible with just a numeric pin. Note that it isn't idealin general to protect a set of pages with just one pin because thatmakes it harder to delegate/revoke admin privileges later, but it willdo <strong>for</strong> this exercise.10.12 Exercise 7: Implement Some Real ServicesDepending on the complexity of the services you came up with inExercise 2, implement one or two or three of them. If you implementmore than one, you may wish to create a voice service menu as theentry point <strong>for</strong> all your voice users.That works great <strong>for</strong> fields such as first_names, last_name,street_address, subject summary lines, etc., where there is novalue to having an HTML tag. For some longer documents obtainedfrom users, however, it might be nice to enable them to use arestricted set of HTML tags such as B, I, EM, P, BR, UL, LI, etc. Ifyou're going to store HTML in the database once and serve it backout thousands of times per day it is better to check <strong>for</strong> legal tags atupload time. The problem with checking <strong>for</strong> disallowed tags such asSCRIPT, DIV, and FONT is that HTML keeps getting extended in dejure and de facto ways. Unless you want the responsibility of keepingcurrent with all of the ways in which new HTML tags can makebrowsers behave it may be better to check <strong>for</strong> approved tags. Eitherway you'll want the allowed or disallowed tags list to be kept in aneasy-to-modify configuration file. Further you probably want toper<strong>for</strong>m a bit of validation on the use of allowed tags such as B or I. Auser who makes a mistake and <strong>for</strong>gets to close one of these tagsmight render 100 comments underneath in an unusual font style.7.10 Exercise 3Document your team's approach to preventing one user fromattacking other users with malicious HTML. Your documentation ofthis infrastructure should include procedure names and examples ofhow those procedures are to be used.7.11 Time and MotionAll of the exercises in this chapter are intended to be done by theteam as a whole. A team that takes the assignment seriously shouldspend about 3 hours together agreeing to and documentingstandards. They then might decide to rework some of their older codeto con<strong>for</strong>m to these standards, which could take another 5 or 10programmer-hours. The second step is optional though by the end ofcourse we would expect all the projects to be internally consistent.10.13 Exercise 8: Client SignoffAs with mobile browser interfaces, a voice interface is tough <strong>for</strong> mostpeople to think about until they've actually used one. Try to sit downwith your client face-to-face and observe them going through all thenooks and crannies of your VoiceXML interface. If that isn't practical,email your client explicit instructions and then follow up with a phonecall.Write down the client's answers to the following questions:196153

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!