Training, Open Source computer languages
PerlPHPPythonMySQLApache / TomcatTclRubyJavaC and C++LinuxCSS 
Search for:
Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
Problem on user varification?

Posted by michelle (michelle), 11 April 2005
Hello graham, this is Michelle from Liverpool. Hope everything goes well with you. I have a question about the program.The company still want to have a client password varification rather than click confirm box, that would be great if you could give me a similar example on this function, please? Thank you very much for any help that you offer.  

Posted by admin (Graham Ellis), 12 April 2005
An interesting example of the customer requiring more data input than's really necessary, but I can understand why. Michelle's talking about an application tat we were discussing on last week's PHP course where there's a data entry system for business accounting between two companies, and a requirement for both companys to see and approve the data entered.

Since each person logs in before they can view the data, and only if the login (and matching password) are appropariate ones are they given rights to view certain data (i.e. for companys they're concerned with, certain check boxes, etc), I felt there's no need for them to re-enter their password when approving - especially as their name and time of approval was to be recorded from their session variables and the system clock as an audit trail. However I can understand that, Phsycologically, the client wants to do more that just check a box ...

a) Replace the checkbox on the form with a password field
<input type=password name=xxxxxxxxxxxx>
where xxxxxxxxxxxxx is the same as the name you used for the checkbox

b) When you get the input back, run the same SQL query that you already have at initial login on the user / password database, and check the password in the same way ... I can't easily provide a sample that will be suitable as you already have this code not me - you were writing it on your own laptop the other evening  

c) You will need to add in an extra alternative respones in the "finishing up" code for approvals .... don't move on a page, but respond with an "error in password" message.

Two more tips

1. Rather than doing an "I approve" checkbox AND a password box, just do the password.   Use the text "Enter your password to approve this [form / line]" and take the presence of any [[:graph:]] text as being an attempt to approve, with an empty box meaning that no approval attempt is being made

2. Write the code so that you can switch back to the original idea of just a checkbox once they're logged in for approval.  I expect they'll get VERY tired of entering passwords VERY quickly.  



This page is a thread posted to the opentalk forum at www.opentalk.org.uk and archived here for reference. To jump to the archive index please follow this link.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho