Re: Need help with Form, almost have answer
- From: Harlan Messinger <hmessinger.removethis@xxxxxxxxxxx>
- Date: Thu, 11 Sep 2008 10:40:55 -0400
smk17 wrote:
To make a long story short, we have an online course. There used to be
only one way to register and pay online, that was through Paypal/
Verisign. Everything was secure. Course is $50.00. Everything worked
for 8 years, no problems. But only US residents could pay for the
course (not sure if this is a Cornell related constraint).
The client now wants people all over the world to be able to pay for
and take this course. He wants two ways to be able to register. One,
if you live in the United States you can go to our secure online
section and use your credit card. Two, if you live outside the United
Staes, you can make an Initernational Wire Transfer to a bank of
Cornell's choosing. But he had no idea how to make it work while still
being secure.
So, he contacted the Cash Management office at Cornell to see if they
knew of a way to do this. They devised a way (we are still testing)
for international students to first register (through another online
form) and then this form, that we are talking about, to alert Cornell
of their intention to complete an International Wire Transfer. The
data we collect from this form is to track their International Wire
Transfer transaction, not actually make the transfer of funds. Someone
at Cornell has to manually track the incoming international wire
transfers and match it up with the data received on this form.
If I'm understanding correctly, the form is being submitted to a website other than the website that the form came from, and this is data that's needed to relate the form data at the submission destination to the person's information at the form's source.
As has been pointed out to you, the readonly attribute will avoid impulsive changes by ordinary users but doesn't provide a guarantee that a savvy user won't change the data*. What you can do to provide an extra measure of assurance against tampering by the user is for the source server to generate a unique code to associate with the person, one that is virtually unguessable, like a random string 20 characters long. Include that code as a hidden field in the form. At the form submission destination, send a web request to the source server to verify that the code received corresponds with the personal data received. A web resource on the source end will need to be set up to accept this data and return a "good" or "bad" response.
*For example, twice in the past couple of months I've placed orders on websites in which the Javascript validation code, in checking the entered e-mail address, turned out to have an arbitrary requirement that the user name have at least three letters. There is no such restriction, and the e-mail address I was using is of the form x@xxxxxxxxxxxx So I examined the Javascript and doctored it to get around this validation and submitted the form again. Of course, if the same validation were happening on the server side [which should always be the case--don't ever rely on client-side validation because the client may have Javascript turned off, or not have Javascript at all, or could circumvent the existing Javascript just as I did], then the submission would have failed anyway, but it did succeed.
.
- References:
- Need help with Form, almost have answer
- From: smk17
- Re: Need help with Form, almost have answer
- From: Jukka K. Korpela
- Re: Need help with Form, almost have answer
- From: smk17
- Need help with Form, almost have answer
- Prev by Date: Re: Validator Blockquote Bug as of ISO: 2008-Sep-07 WAS: Re: How to Embolden A Blockquote?
- Next by Date: Re: Validator Blockquote Bug as of ISO: 2008-Sep-07 WAS: Re: How to Embolden A Blockquote?
- Previous by thread: Re: Need help with Form, almost have answer
- Index(es):
Relevant Pages
|
