I am looking for a deeper explanation of the html form action attribute than is usually given. What is really happening when the user hits 'submit' in the browser? I assume that the browser sends some kind of message to the web server software. So the browser is communicating with for instance Nginx.
But the way people talk about the action attribute makes it sound as if the browser is really sending the data to some arbitrary URL. Like to a php script located at that URL, but that doesn't really make sense to me. Is the form data really being sent to the web server and then the web server parses the action attribute and attempts to somehow submit the parameters and values to a script located there? In that case the URL specified by the action attribute would really be more like a suggestion to the web server.
Can someone explain to me what is really going on? I find the idea of the form data being sent to a 'where' or anything other than to the web server quite confusing and I have not been able to find a deeper explanation anywhere. All paths seem to lead to the concept of the form data being sent to some URL as if that actually made sense.
Related
How can we submit a form without Javascript and not by pressing any buttons?
I need to transfer a content to another file when a function works under certain conditions. Both the files are written in Perl. The pages are loaded in a webserver(same). I need to transfer a value, which the user doesn't want to know what I'm sending. So I came up with the post method is safe.
But there I didn't find any ways to redirect a URL where the values are transmitted in post method. So I came up with the form submission. But the problem is I need to use javascript or make user to press a button to complete the task.
The problem with Js is there some users who disable JS in their browsers.
So using it is not preferable. With the button,
I can't make the user to do that for me.
Is there any other scripting language, which supports such functionality?
There are some conditions that I can't use session
What I did is encryption for identifying the user from knowing what data is transmitted. The receiving page will decrypt it when it is required. But it's not what I needed.
I need to transfer a value, which the user doesn't want to know what I'm sending. So I came up with the post method is safe.
It isn't. If you pass it through the user's browser, then the user can see it.
Is there any other scripting language, which supports such functionality?
No. There is no programming language as well supported in browsers as JavaScript, and none that are harder to disable then JS.
Store the value on the server (you could use a session) and redirect the user with a normal 302 status and Location header. You can pass a session token via cookies or the query string.
You can't make a user do anything, unless you're writing for a browser the equivalent of a trojan.
But secondly, without something on the client side, you can't ensure that you can get information that you didn't have when you sent the page.
You could place some links, and know which links they clicked on by passing it through a central tracking program, but those links wouldn't have anything in them that didn't originate on the server without client script running.
Still, despite that you can entice a user to click on a link more than a simply functional button, in either case you can't get guaranteed new information from them. They can always close the tab, close the browser, or press the back button. This goes back to point #1: you can't make users do anything.
I have a web application that I want to force users to log in before they can get to any other pages. I have set up the login and it is working but I can't figure out how to stop them from by passing the login on subsequent visits.
for example they save a link to main.html so I haven't authenticated them. Ideas??
thanks John
For authentication purposes, you should never really on client-side validation only.
Client-side, there's not really much you can do, as the user could just go in and change your code.
The correct way to handle this, is a server-side check (using PHP, ASP.NET, ...) combined with setting a cookie
Please let us know which technology you are using on the server-side (if any)
I have a form which is posted to an MVC3 controller that then has to be POSTED to an external URL. The browser need to go to the URL permanently so I thought a permanent redirect would be perfect.
However, how do I send the form POST data with the redirect?
I don't really want to send another page down to the browser to do it.
Thanks
A redirect will always to be a GET, not a POST.
If the 2nd POST doesn't need to come from the client, you can make the POST using HttpWebRequest from the server. Beware the secondary POST may hold up the return of the client request if the external server is down or running slowly.
A permanent redirect is wholly inappropriate here. First, it will not cause form values to be resubmitted. Second, the semantics are all wrong - you would be telling the browser "do not request this url again. instead, go here". However, you do want future submissions to go to your same url.
Gaz's idea could work. It involves your server, only.
Alternatively, send a form with the same submitted values and the external URL, and use client-side code to automatically submit it.
I have a form which is posted to an external API. There is a parameter called customer_token which is passed as an input field. It is used for authentication by the API and every customer is assigned one token. The input field is visible in Firefox's Firebug (even though it is a hidden field).
How do I hide it?
Options
Using javascript as I thought initially
I think using javascript to create that input field at the run time before submitting the form and immediately removing the field will work but still the field will appear momentarily. So, even if a person can't manually get it, I am afraid that a crawler or spider (I don't know the exact term - but some automated script) may get the customer token. Is there a better solution for this? After form submission, the same form remains displayed.
Using one-time token concept as suggested by Ikke
I am not sure how it will work? The API needs the correct customer token value to process any request. So, even to generate a one-time token and return, a request with the customer token has to be sent. This way anyone is able to see my customer token value and they can also send a request to get a one-time token and use it. So how does it solve the problem?
Resolved
Check How to post form to my server and then to API, instead of posting directly(for security reasons)?
Thanks,
Sandeepan
This is not possible. Firebug just reads the DOM in it's actual state, so even if it's added in a later stage, it can still be retrieved.
This way of security is called Security through obscurity and is a kind of non-security. You would have to solve it another way, like letting the server do the request in stead.
You let the user submit the form to the server. Then with curl, you make the call to the webservice with the correct user code.
I don't think this is possible I'm afraid.
Firebug will still see the element if it's inserted via Javascript, as it watches the DOM tree. If this input exposes a security vulnerability then it's the job of your server-side code to validate/fix it.
More details on the API might help somebody answer this question in more detail.
I hope this helps
Ok, get this.
I have been assigned to write an html form to be EMAILED to clients so that they can fill it in and submit it FROM THE EMAIL CLIENT! apparently emailing a link to the existing form on our website is not good enough.
I am still trying to get my head around this as it seems almost void of common sense, but anyways, my guess is that I will have no way of validating data, and if actually works, how will the user know? WTF?????
Get this, They will be emailing both a pdf and an html doc to clients, I tried putting my case forward but apparently the marketing pro's say IT IS POSSIBLE AND MUST BE DONE, WORKING BY FRIDAY!
This is not a good idea on many fronts:
Not all email clients will support a form post from HTML
see: http://www.campaignmonitor.com/blog/post/2435/how-forms-perform-in-html-emai/
No clientside validation
What's exactly wrong with a link?
How are you getting data from PDF form submission? You can get expensive form tools from Adobe: http://www.adobe.com/government/forms.html
Some spam / av checkers will dispose of form based emails.
There are only two possiblities: first one the mail client must have a php runtime environment to run the php script locally, also an embedded mail server - which isnt the case for the most of them. Second one is that your mail client acts like a browser and displays the form (which is located still on the internet) in his mail viewing window (which is perhaps possible but i dont know any common mail client doing this).
So you either submit a link to the form or you construct the mail this way, that there're placeholders to be filled and submitted like a normal mail response.
This idea is plainly wrong. You're creating a phishing vector for your company which could expose them to huge legal liability. Just ask them how much money they are going to be putting into the legal defense fund in order to pay out for the lawsuits they are going to lose.
An adobe pdf server is about the only reasonable method for doing this, but that takes lots of cash and work on your network to support a new type of server.
It's generally bad idea. Most email clients only allow limited HTML, with limited CSS and without any JavaScript at all.
See: http://www.sitepoint.com/code-html-email-newsletters/
Many mail clients will not allow submitting any form (at least with standard security settings).