URL parameter

[Oaklander]

I have to use get method (instead of post) for form action but dont want to show the url parameter in the action page url.

Anyway to hide or encrypt a form input value after it goes into my database?

Code:

<form action="actionpage.cfm" method="get">
<input type="text" name="myValue">
<input type="submit" name="submit">
</form>

[Dan_Bracuk]

Submit your form to an intermediate page.  On that page, change the url variable to a session variable and re-direct to the action page.

[Scott Stroz]

Not sure why you need to use GET as opposed to POST, other than 1) you cannot modify actionpage.cfm or b) there is a lot of code looking for URL scoped variables on actionpage.cfm.

If it is the latter, one thing you could do is send the form via POST and add this to the top of actionpage.cfm: structAppend(url, form)

[BKBK]

In a separate, preliminary process, use a key and an algorithm to encrypt the message.  For example,

<cfset myMessage = "Open sesame!">
<cfset myKey = "abracadabra">
<cfset encryptedText = encrypt(myMessage, myKey)>

Then output the value of encryptedText (which is ,<$.>B/_ "EQ=FZIV) and use it in the form, thus

<cfform action="actionpage.cfm" method="get">
<cfinput type="text" name="secret_code" value=",<$.>B/_ ""EQ=FZIV">
<cfinput type="submit" name="submit" value="Send">
</cfform>

The vital connection in the communication is that the sender(the form page) must reveal its key to the receiver(the action page). Otherwise, decryption would be practically impossible.

actionpage.cfm

<cfif isDefined("url.secret_code")>
<cfset theKey = "abracadabra">
<cfset decryptedText = decrypt(url.secret_code, theKey)>

<!---<cfoutput>#decryptedText#</cfoutput>--->
<!--- query to insert decryptedText to database --->
</cfif>

[Adam Cameron.]

BKBK is on the right track to answer your question here: encrypt the form values before submitting the form.

But... why?  Why are you wanting to do this?  The whole idea (well: it's a significant part of it... there's the whole notion fo GETs being idempotent too, that some people bang on about.  There's nothing to say a POST can't be idempotent too, though) of a form submitted with a GET is to have the params on the URL.  If you don't want them there, don't use a GET, use a POST.

--

Adam

[Owainnorth]

Anyway to hide or encrypt a form input value after it goes into my database?

*After* is goes into your database? I think more or less everything's been covered, but to clarify - there is *no* way of sending encrypted data from a form through URL parameters. As mentioned, you can send it to an intermediate page which encrypts then redirects, but that's about it.

If you can explain a little more the hows and whys I'm sure there'll be a way to do what you're after.

Bonus points should go to Adam for dropping in the word "idempotent".

[Adam Cameron.]

there is *no* way of sending encrypted data from a form through URL parameters.

Well one could encrypt the form field values onsubmit.

Bonus points should go to Adam for dropping in the word "idempotent".

Ha.  Ah, people bandy it around when discussing HTTP methods, especially in the context of RESTful interfaces.  I had to look it up when I first heard it.  I don't actually like using words that people are likely to have to look up to understand (my yardstick being that if I have to look it up, most other people will need to as well), especially when the word is such that one cannot be expected to infer what it means from just looking at it.  However I think "idempotent" is used in the context of HTTP methods sufficiently that it's pretty much lingua franca.

I have now used that word a total of twice (I mean... ever).

--

Adam

[Owainnorth]

Well one could encrypt the form field values onsubmit.

From a browser? Surely that would leave you only Javascript as an encryption method, and even then you'd have to store the key in the user's browser. Unless I misunderstand what you're saying.

I don't actually like using words that people are likely to have to look up

I definitely did not have to look up this word and read the explanation several times.

[Adam Cameron.]

Well one could encrypt the form field values onsubmit.

From a browser? Surely that would leave you only Javascript as an encryption method, and even then you'd have to store the key in the user's browser. Unless I misunderstand what you're saying.

Sorry, yeah.  I should have qualified that more.  One can encrypt the string adequately if the intent is simply to obfuscate the values, but I did not make clear what you point out: the encryption mechanism and the key to (en|de)crypt the string will all be exposed to anyone who is determined to find out the values by decrypting them.  Then again... the user has just entered the values on the form, so they already know what they are anyway.  This all seems like a fool's errand to me.

Again, it's difficult to give a sensible and thorough answer here without knowing why the question is being asked.

--

Adam

[BKBK]

Adam Cameron. wrote:

Sorry, yeah.  I should have qualified that more.  One can encrypt the string adequately if the intent is simply to obfuscate the values, but I did not make clear what you point out: the encryption mechanism and the key to (en|de)crypt the string will all be exposed to anyone who is determined to find out the values by decrypting them.

Exposure of the ciphertext to the world isn't a problem. The trick is of course to make it practically impossible for non-communicants to get the key.

Then again... the user has just entered the values on the form, so they already know what they are anyway.  This all seems like a fool's errand to me.

No, it isn't as you assume. The basic assumption is that the user(sender) knows the ciphertext, the algorithm and the key! He sends the ciphertext via the form, but not the key. The sender has given the key to the receiver beforehand, presumably via secret means. The point is that any unauthorized middleman who intercepts the communication wont be able to decipher it.

[Adam Cameron.]

Um... if that was the requirement, then one would just use SSL.

--

Adam

[Owainnorth]

So basically...

it's difficult to give a sensible and thorough answer here without knowing why the question is being asked.

[BKBK]

Idempotence doesn't quite get into it. At least, not on this occasion. Idempotence relates to the response of the GET method, whereas this question relates to the request.

[BKBK]

Owainnorth wrote:

there is *no* way of sending encrypted data from a form through URL parameters.

No way? The form page plus action page example shows one way!

[Owainnorth]

Yes, but that's *not* sending encrypted data from a form, it's sending unencrypted data from a form, then passing that between pages on a webserver.

It's a small point I know, but there's a difference.