I was just validating some of my html5 pages on W3C with forms (PHP) on them and I get the following validation error:
Error: Bad value for attribute action on element form: Must be non-empty.
I thought that when the form submits to itself, it is good practice to leave the action attribute empty. Is this not the case? How can I fix this?
Thank you!
Simply put in "#".
<form action="#" method=post>
While browsers currently support the empty action since the spec says it's needed browsers in the future may not support it. In my opinion this is unlikely but you never know.
The reason I would add the action attribute is so if there is JavaScript somewhere that is actually posting the form the next developer in line is certain that this is were the form posts to and doesn't have to look though the relevant JavaScript files to see if this is intended or left out on mistake.
It can be fixed my putting the current page in the action attribute.
Hope that helps.
Related
I'm using TYPO3 9.5 and building a search Extension with extbase and have some problems with the cHash.
I build my search form in fluid with f:form and use GET as method. There are no problems if I use POST.
My search action is configured as non-cachable action. I also tried to set the TypoScript config requireCHashArgumentForActionArguments = 0 for my extension.
But every time I try to search, I get a 404. Even when I let the form viewhelper generate a cHash. The only workaround that is working, is to disable pageNotFoundOnCHashError in the LocalConfiguration. But that feels wrong to me.
The action works also if I create a Link with fixed search words.
So there are some questions that came up to me.
Why is a cHash for a non-cachable action needed?
How can the cHash work on a form at all? It's the concept of a form that the user can modify the values, and as far as I understand it is the concept of the chash to prevent this.
Here is also some example code
<f:form
id="search-form"
class="press-search-widget"
additionalAttributes="{'role': 'search'}"
method="get"
action="search"
extensionName="MySearch"
pluginName="Mysearch"
controller="Search"
section="search-form" >
<f:form.textfield
id="pressfilter-search"
class="form-control"
type="text"
name="searchTerms[searchTerm]"
value="{parameters.searchTerm}"
placeholder=""
/>
</f:form>
Why is a cHash for a non-cachable action needed?
cHash is evaluated before it is known which TypoScript should be fetched, so it is also not known which (un-)cached plugins should be loaded or if they require cHash evaluation (or have it disabled).
How can the cHash work on a form at all? It's the concept of a form that the user can modify the values, and as far as I understand it is the concept of the chash to prevent this.
I don't know the reason of you using a form submission with HTTP GET. However all GET parameters are taken into account except for the ones excluded (see response above already).
I strongly recommend switching to HTTP POST - mainly because the HTTP standard requires POST parameters to not be cached (also not in the browser!), otherwise Visitor A could submit something with the form and Visitor B sees the result from Visitor A. POST is for data submission, GET is actually defined as a "read-only" mode in HTTP.
Two options for TYPO3 are:
switch to POST if there is no 100% necessity for GET in your use case
use the cHashExcludedParameters option in TYPO3 to disable all user-input values from the form.
cHash is a security feature. It protects against maniuplation of parameters. And servers as an additional layer of security it also prevents a cache bloat attacks.
Where a bot can generate links with new parameters and TYPO3 then caches the result of every such page and quickly grow the cache tables in the database.
It is however possible to exclude certain parameter from this caluculation using the install tool: [FE][cHashExcludedParameters] setting.
The excluded parameters then also do not affect the caching. (pages are cached as if the parameters are not present) but as you have a non-cacheable-action your result has to be generated on the fly anyway.
Why is a cHash for a non-cachable action needed?
I dont really know. Maybe they just forgot it or no one really uses GET forms.
How can the cHash work on a form at all? It's the concept of a form that the user can modify the values, and as far as I understand it is the concept of the chash to prevent this.
The URL parameters are included in the chash. So sending via POST shouldnt take use of the chash except for the action/controller parameters.
You have to build the form by yourself and validate it manually or use Javascript. Indexed_search uses POST, changes the page/pointer ind the hidden form fields and submits the form again for the pagination.
My application has "survived" many Facebook API changes, to the point where it's quite messy.
Anyway: I'm no longer able to POST a simple HTML form. The entire page reloads and no data is saved.
I've tried several things. Changing the "action" url to include several Facebook parameters, changing the target (canvas_iframe) but to no avail.
Has anyone else encountered problems with this?
try to write absolute path in "action". Its not important include Facebook parameter
Give site url("www.example.com/") as the value of the action attribute rather the Canvas URL(http://appifylabs.com/facebook/yourapp/processform.php)
e.g
if processform.php is the script that will manipulate your form so give the value
site_url = "www.example.com/";
action="<?php echo site_url; ?>processform.php"
Here it says it's required
http://www.w3schools.com/tags/att_form_action.asp
but I see that forms get submitted even if I don't specify an action attribute, and the form gets submitted to the current page which is exactly what I want.
The requirement is only by standards. It is perfectly possible to do whatever you want on a page and not follow standards. Things may not display or work correctly if you do that, but likely they will. The goal is to follow them, and the idea is that if you follow them, your page will always work; you don't have to worry about anything.
Yes, the form is required to have an action attribute in HTML4. If it's not set, the browser will likely use the same method as providing an empty string to it. You really should set action="" which is perfectly valid HTML4, follows standards, and achieves the same exact result.
In HTML5, you can actually specify an action on the submit button itself. If there isn't one, it uses the form's action and if that is not set, it defaults to the empty string (note you cannot explicitly set the action to an empty string in HTML5).
It looks like the HTML4 spec requires it. I suspect some browsers do what you want to "make things easier". I don't recommend relying it on though. Since you're in undefined behavior, a browser could reasonably decide to just do nothing when the form is submitted with no action.
You can get the behavior you want while following the spec by leaving the action blank (since it's relative, blank means the current page):
<form action="" ...>
As mentioned by bazmegakapa, the HTML5 spec doesn't seem to require the action attribute:
The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces.[emphasis added]
Interestingly, this means in HTML5, <form action=""> is not valid, but it's not clear if a form without an action is required to work (submit to the current page).
Technically it's a violation of the HTML 4 spec, but all browsers will post back to the originator of the response if no action is specified. I would agree it's not a smart idea to rely on it but it does work.
EDIT: As it has been pointed out to me that this question is tagged as HTML 5:
In HTML 5 they list the action attribute as no longer required: http://www.w3schools.com/html5/att_form_action.asp which is in accordance with the HTML 5 specs.
// thread resurrection alert
To extend upon animuson's answer...
If after all button formaction and form action attributes have been assessed, if "action" still evaluates as "empty string", then from HTML5.2 spec section 4.10.21.3 point 8 states:
If action is the empty string, let action be the document’s URL of the
form document.
when it comes to submission of the form, which is what you wanted.
I am wondering if anyone can give a "best practices" response to using blank HTML form actions to post back to the current page.
There is a post asking what a blank HTML form action does here and some pages like this one suggest it is fine but I'd like to know what people think.
The best thing you can do is leave out the action attribute altogether. If you leave it out, the form will be submitted to the document's address, i.e. the same page.
It is also possible to leave it empty, and any browser implementing HTML's form submission algorithm will treat it as equivalent to the document's address, which it does mainly because that's how browsers currently work:
8. Let action be the submitter element's action.
9. If action is the empty string, let action be the document's address.
Note: This step is a willful violation of RFC 3986, which would require base URL processing here. This violation is motivated by a desire for compatibility with legacy content. [RFC3986]
This definitely works in all current browsers, but may not work as expected in some older browsers ("browsers do weird things with an empty action="" attribute"), which is why the spec strongly discourages authors from leaving it empty:
The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces.
Actually, the Form Submission subsection of the current HTML5 draft does not allow action="". It is against the spec.
The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces. (emphasis added)
The quoted section in mercator's answer is a requirement on implementations, not authors. Authors must follow the author requirements. To quote How to read this specification:
In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example Web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.
The change from HTML4—which did allow an empty URL—was made because “browsers do weird things with an empty action="" attribute”. Considering the reason for the change, its probably best not to do that in HTML4 either.
Not including the action attribute opens the page up to iframe clickjacking attacks, which involve a few simple steps:
An attacker wraps your page in an iframe
The iframe URL includes a query param with the same name as a form field
When the form is submitted, the query value is inserted into the database
The user's identifying information (email, address, etc) has been compromised
References
Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution
This will validate with HTML5.
<form action="#">
IN HTML 5 action="" IS NOT SUPPORTED SO DON'T DO THIS. BAD PRACTICE.
If instead you completely negate action altogether it will submit to the same page by default, I believe this is the best practice:
<form>This will submit to the current page</form>
If you are sumbitting the form using php you may want to consider the following. read more about it here.
<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">
Alternatively you could use # bear in mind though that this will act like an anchor and scroll to the top of the page.
<form action="#">
I think it's best to explicitly state where the form posts. If you want to be totally safe, enter the same URL the form is on in the action attribute if you want it to submit back to itself. Although mainstream browsers evaluate "" to the same page, you can't guarantee that non-mainstream browsers will.
And of course, the entire URL including GET data like Juddling points out.
Just use
?
<form action="?" method="post" enctype="multipart/form-data" name="myForm" id="myForm">
It doesn't violate HTML5 standards.
I used to do this a lot when I worked with Classic ASP. Usually I used it when server-side validation was needed of some sort for the input (before the days of AJAX). The main draw back I see is that it doesn't separate programming logic from the presentation, at the file level.
I use to do not specify action attribute at all. It is actually how my framework is designed all pages get submitted back exact to same address. But today I discovered problem. Sometimes I borrow action attribute value to make some background call (I guess some people name them AJAX). So I found that IE keeps action attribute value as empty if action attribute wasn't specified. It is a bit odd in my understanding, since if no action attribute specified, the JavaScript counterpart has to be at least undefined. Anyway, my point is before you choose best practice you need to understand more context, like will you use the attribute in JavaScript or not.
When you put empty action then some security filtration consider it malicious or phishing. Hence they can block your page. So its advisable not to keep action= blank.
This is my first time posting - I greatly appreciate any and all guidance on this subject.
Background: I am building a Real Estate web site. I would like to use the free IDX data provided by my local MLS board. The MLS board does not allow me the option of displaying a predefined search and only provides me with a link to the search field. after filling out the search field, I am able to view the results.
Goal: I would like to bypass this step and frame the results page into a GoDaddy website I am building, which supports HTML.
Here is a link to the search page:
http://fgcmls.rapmls.com/scripts/mgrqispi.dll?APPNAME=Fortmyers&PRGNAME=MLSLogin&ARGUMENT=vBSJvLQtMcbg7F0O0KnXDiggv%2F12B0S6Ss9wv4510QA%3D&KeyRid=1
I am trying to only show the listings that appear in my neighborhood. Options include:
1. Property Type - Residential
2. GEO Area - FM11
3. Developments: Fiddlesticks Country Club
Once this criteria is entered, I have the page needed to make this project work.
Thank all of you for taking the time to read this and for the time you spend helping me out.
Best regards,
Chris
Without looking at the page itself, it's probably doing a "POST" operation to give the form to the website. You should be able to use javascript (maybe jquery or some other ajax framework) to do this for you in the frame and have it display the results.
-Adam
So long as this is a POST form and they aren't doing a lot of strict referrer checking, the following should work:
Replicate the form on your own site.
Make a few minor changes to automate a few of the fields to better serve your geographic area/company.
Ensure everything is a full path and not relative to the server handling the query.
You will probably end up changing a lot of the text/select fields to hidden fields with pre-set values to keep it simple for end-users. The server handling the request won't know the kind of field it came from, just the value and name.
I took a look at the page HTML, the form posts is defined thusly:
<FORM action="/scripts/mgrqispi.dll" method="POST" name="InputForm" />
you may be able to create your own form defined like this:
<FORM action="http://fgcmls.rapmls.com/scripts/mgrqispi.dll" method="POST" name="InputForm">
</FORM>
You will have to go through the HTML on the page you provided to get the appropriate ID's and Name's of the form elements you are interested in. Its possible their processing page checks to ensure its their form that is submitting to it, in which case this wouldn't work.
good luck.