Need help with Form, almost have answer

I've spent the last few minutes searching for this question and I
found an answer, but it wasn't quite what the client wanted.

I have a simple online form where the user needs to fill out five
fields out of nine. The other four are already there and filled out
for the user. When they hit submit, all data is sent to us.

But, if they desire (for whatever reason) the user can possibly delete
what is already there and fill in something else. We do not want that.

Is there a way to have that info already filled in and untouchable? I
thought about having it type="hidden" but I think the client wants the
user to be able to see it.

The test page example is here: http://gmptraining.aem.cornell.edu/i...al/back-05.htm

Thanks
Steve

re: Need help with Form, almost have answer

On Sep 10, 2:59*pm, smk17 <sm...@cornell.eduwrote:I figure out my own question.

I used the readonly attribute like this:

<input readonly type="text" name="Department Phone"
value="631-632-8730" size="12">

re: Need help with Form, almost have answer

smk17 wrote:
You are not telling which answer you found, but, judging from indirect
evidence, it seems that it is basically the correct answer.
That's possible, though the question arises why you send four pieces of data
just to get them back.
Surely he can. You can make it more difficult by using the readonly
attribute (which may also affect rendering), but it's easy to create a copy
of a page, edit it by removing that attribute etc.
No.
You can include a copy of the data as normal visible content. This approach
takes a further step in making it more difficult to change the data - though
only in the sense that the user does see it as being in a form field, so it
will come less often to the user's mind that it will be sent and could be
modified.

If you know what the extra data must be, just _use_ it on the server that
receives the form data and associate it with the data set submitted. Things
get tricky if the data is, in fact, dependent on the situation and was
generated for a particular instance. But you would need to explain the
scenario in more detail, preferably in another question, since this isn't
really an HTML question (except marginally, in a rather trivial sense).
I'm not sure of what is being done there, but I get suspicious when money
issues are dealt with without using https (SSL). Where I live, the normal
approach is that when payment is required in some context on the web, the
user is asked to select a method of online payment, then an https secured
transaction takes place either via online bank transfer or via credit card
payment, and the user returns to the service and everyone is happy.

If you have to play with less developed methods of payment, essentially
offline, I don't see what you gain by having that form. In such cases, it
would appear normal to have a subscription form together with information
that explains how the payment is to be performed. Then someone has to
process the payments as they arrive and match them with submitted form data;
manual work is needed here anyway.

ObHTML: Reset button considered harmful. If you don't agree, think how much
damage it does when it is used.

Yucca

re: Need help with Form, almost have answer

On 2008-09-10, smk17 <smk17@cornell.eduwrote:[...]Bear in mind that a determined user can still change the data that's
actually submitted to the server if they want to.

All readonly does is stop them modifying it with the form control. They
could use curl, or Firefox's "Tamper Data" plugin, or other things, to
submit whatever form data they like to the server.

For example they could only credit the suggested account with $1 if they
wanted instead of $50.

I don't know important is it to you that the data be really
"untouchable".

re: Need help with Form, almost have answer

On Sep 10, 3:30*pm, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:Thanks Yucca,

This form is not connected to an ecommerce, https site.

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.

The client wanted 4 of the fields in this form to be already filled
out for the user so there would be no mistake in them entering this
important data. My first test he noticed that he could select what was
in those 4 fields and delete/change what was in there. As an extra
precaution he decided to have me try and make it so that text could
not be altered and still sent when they submitted the form, which led
me to this newsgroup to ask the question.

This data from this form is then sent to a folder on a server here at
Cornell as a .txt file that we then forward to the Cornell Cash
Management people.

Is there a better way to do this? Probably, but you go to war with the
army that you have. And we are a team of only two people.

Again thanks, I know I came off as kind of upset about crossposting
but I truly do not know the best way to get a question out to as many
people as possible.

re: Need help with Form, almost have answer

smk17 wrote:
PayPal allows international payments in a wide variety of currencies.
Yes. Read the Paypal help screens and learn how to set it to allow
payments from any country.

re: Need help with Form, almost have answer

smk17 wrote: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@example.com. 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.