I've seen questions around both submitting to self (same url) and submitting to different url. Which one is the right way to go?
Neither is "right". Both are fine. Use whichever one suits your needs.
Submitting to a different URL can simplify keeping your "show form" and "process submission" logic separate (and thus easier to maintain).
Submitting to the same URL simplifies redisplaying the form with error messages if the user makes an error in their input.
Related
Much like the mailto: link you can add ?subject=
I wanted to be able to create a web link which would send you to a webpage that contained a form.
In that Form, I would like the value of the TextArea to contain information Inserted by the contents of the referring Weblink.
Example:
example.com/page-url?textarea=content
Is that possible? If so, can you tell me?
I pay in chocolates.
Thanks for your time and I look forward to any replies.
Plain HTML can't do this by itself. You'll need to use Javascript or some kind of server-side processing to get the values from the submission.
Forms have two methods - POST, which submits through the headers, and GET, which submits through a querystring. With the querystring it's easier for users to mess with your data, so keep that in mind as you design this. (Not that it's impossible with POST, but it takes a little more work)
Since you're passing to a textarea, make sure you URLEncode your post or things like spaces will cause you a lot of headaches.
I tried to look through SO for similar question but I couldn't find one, also searched through the web with my best effort, sorry if it's a silly/duplicate question
The focus of my question is :
If I have a form with a unencoded password in it, is it "safe" to pass the form back to [self] i.e. <form action="">
EDIT: I would like to focus on security regarding third parties, assuming the user himself is NOT the hacker.
I this is a broad question, so I would like to narrow it down to:
does server handle submit form to self as a internal-forward thing or do it actually treat is as a normal server-to-server http call?
Is it possible to somehow intercept the form submit and extract the password from this action? (including things like tapping the connect between server and client??)
If anyone knows any potential security problem in general for [submit to self], feel free to leave it as answer so that future SO user might benefit from it, thanks.
The only thing safe regarding submitting data to a webpage is to never trust the users input.
Now regarding your 2 questions:
submitting the form will be handled as a regular request, albeit a POST request probably.
internet traffic can be captured, so if you're sending password data over the internet you'd better make sure it's over HTTPS.
Using a developer tool like Mozilla's FireBug it's pretty easy to change all the data that is submitted through the form. You don't even have to use your webpage, one can easily spoof a POST request to your page by using a tool like Telnet.
So I'd say it doesn't really matter what the action of the form is; use HTTPS if possible and always validate the input...
Whether you submit your form to the same page or not has no security implications. There are many other things you can/should do to secure your forms. Submitting-to-self is irrelevant. It could however pose a UX annoyance. Have you ever tried refreshing a page only to have the browser try to resubmit the form.
Not a redirect. Normal post. However to mitigate this UX annoyance I
mentioned, you would redirect to the same page after doing whatever
you need to to with the data.
It depends on many other things other than whether the form submits to itself or not. Starting with is your form on a secure (https) server.
I was just searching for this types of posts.
Yeah..
As far as i know, this is not a valid approach,
attacker can change the methods to download the content like he can use the parameters from POST to GET.
We actually have tools like tamper data which is an addon to the firefox browser. We can post the data or tamper the data which is in form submit. You can add this addon to your browser and you can check out that the data can be modified by clicking tamper before submitting the form. You can also check out the online http tampers, tamper data, modifying live headers to change your data. This may also result in sql injection.
Correct me if im wrong. :)
Cheers.
After many updates:
The action="" is the same as action="somefile" in sense of security. So there is nothing wrong with action="", and as far I know most websites treats forms like that. The most popular solution is to:
At first check with PHP if there is any post data
Check if this data is OK (safety, server side verification)
Make something with data (save to database, mail to someone)
Render the form with action="".
A quick example:
<?php
$name = '';
if (isset $_POST['name']) {
$name = $_POST['name'];
if (ctype_alpha(str_replace(' ', '', $name)) !== false) { // verify data
// in that case name consist only letters and spaces, it is ok.
// do something with data here, for example save to database
header('Location: successfile'); // Remove post data after all
}
}
// render form
$name = htmlspecialchars($name); // if name was in POST, here it is!
echo '<form action="" method="post" />'
echo '<label id="name" name="name" value="'.$name.'" />';
echo '</form>';
?>
In that case one file is doing two jobs. It checks for data and do something with it, and render form.
Please, remember that the form can be rendered using the "partly" data from submit (POST). So for example if someone enter his name with special characters, while you need name only with letters and spaces, the data is not missed. You can render form, and in input name value, you can enter the wrong posted data.
So the form "remember" what was filled, and what was not filled.
Hope it helps
I have working the auto population of this form: http://getpocket.com/save
I'm using it rather than the API so that it works when users are logged into Pocket on the same browser as my website.
However, it's not a good user experience to then have to click 'save', so how can I "automate" that?
I won't show my code, because it essentially is just to generate a link of the form:
http://getpocket.com/save/?title=thetitle&url=encodedurl
It populates the form fine, but how can I submit? I tried apending &save and &submitand then each of those =True, in vain. Is the issue that the save button doesn't have a name= field, which is what's used to hook into the title and URL fields?
EDIT: Just to be clear, I didn't have any malicious intentions, only to save articles to read later on click of a button.
If I find the time I'll have a look at the API.
Luckily this is impossible (on Pocket and most sites) due to cross site forgery request protection to prevent exactly what you are trying to do.
A token is set in the form and together with session information for the user on pocket (or any other site that uses csfr token protection) it will need to form some sort of secret hash. When the 'save' form is submitted the combination of these strings will be checked and normally new strings will be set. Because there is (practically) no chance that you will be able to predict the token form the form itself and have no real way of manipulating the session hash, you are out of luck. And we are all very happy for that :).
Otherwise you could make links on other sites that would delete your whole database when you happen to click on them, etc.
In short: You can't.
On any form without csrf protection you'd have to target not the url of the page with the form, but the 'action' of the form. You can see this action by inspecting the form with your browser's DOM inspector. But, as I said, csrf protection will prevent this from working most of the time.
http://en.wikipedia.org/wiki/Cross-site_request_forgery
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
I read some AJAX-Form tutorial like this. The tag form is used in HTML code. However, I believed that it is not necessary. Since we send HTTP request through XmlHttpRequest, the sent data can be anything, not necessary input in form.
So, is there any reason to have form tag in HTML for AJAX application?
Apart from progressive enhancement as already discussed (don't make your site require JavaScript until it really has to), a <form> with onsubmit would be necessary to reliably catch an Enter keypress submission.
(Sure, you can try trapping keypresses on separate form fields, but it's fiddly, fragile and will never 100% reproduce the browser's native behaviour over what constitutes a form submission.)
Sometimes, web apps using ajax to transform their data either use forms as a fallback when the user has no JavaScript enabled (a sometimes expensive but very good thing to do).
Otherwise, if an application builds and sends an AJAX request, there is no compelling reason to use a form except in rare special cases when you actually need a form element. Off the top of my head:
when using jQuery's form serialize function
when monitoring all fields in a form for changes
when there is need to make use of the reset form button (that to my knowledge is available in a proper <form> only).
I see at least two possible reasons :
Graceful degradation (see also Unobtrusive JavaScript) : if a user doesn't have Javascript enabled in his browser, your website should still work, with plain-old HTML.
Behavior of the browser : users know what forms look like and how they behave (auto-completion, error-correction, ...) ; it's best not going too far away from that
And I would add that, if you want the user to input some data, that's why <form> and <input> tags exist ;-)
Using the right tags also helps users -- as an example, think about blind users who are navigating with some specific software : those software will probably have a specific behavior for forms an input fields.
It really depends what you're doing. If you're wanting to take form content submitted by the user and use AJAX to send that somewhere then you're going to want to use the form tag so your user can enter their data somewhere.
There will be other times when you're not sending data from a form and in that case, you wont have a form to be concerned about :)
When doing web programming there seem to be two different ways of handling a form and its action. Is there a reason to prefer one method over the other?
Method 1: One page that displays a form or handles a submitted form. This seems simple, in that there's one form for everything. But it also means the if/else cases can become rather large.
if [form has not been submitted] {
// display form for user input
} else {
// handle submitted form
}
Method 2: Handle user input on one page with a form, with the form submitting to a second page.
page 1 (input.html):
<form action="./submit.html">
// display form for user input
</form>
page 2 (submit.html): Handles the input from the form.
I've seen both of these methods used. The upside of the first method is that there's only one page and one set of variables to worry about, but the page can get large. In the second method, each file is simpler and shorter, but now you have twice as many files to worry about and maintain.
I typically submit back to the same page, as you will often need to redisplay the initial page if there are validation errors.
Once the record has been successfully saved, I typically use the Post/Redirect/Get method to avoid the common multiple submit issue.
I think it depends on what kind of form it is. If it has too much validation I would go with two pages.
I always use to pages though because I like my code to be clean, but I use AJAX whenever possible e.g. contact forms since they are short, and I just post the response back to a div in the form.
Caching.
If the server has a series of static HTML pages livened maybe only by AJAX (and even these requests cached, server side, per user), it reduces its load and traffic significantly. Then confining the dynamic content of targets of forms to a relatively small area is a boon, because a page that is a target of POST can't be retrieved from the cache, it has to be regenerated from scratch no matter how heavily loaded it is.
Of course this doesn't solve the question of n static pages + 1 CGI vs n static pages + m CGI.
But once you don't need to spit out sophisticated HTML, just a simple redirect, keeping things in one place may be profitable - error checking and handling, authentication, session management and so on.
OTOH if every your page is a CGI script that creates a new page on each visit, there is no reason why it can't accept form data and handle it at the same time.