I've seen a lot of PHP code that handles form input in which the input field names contain square brackets. I understand that this somehow results in PHP arrays when a PHP script examines the $_POST variable.
Example HTML:
<form action='http://zzz.com' method='post'>
<input name='fruit[1]' value='apple' />
<input name='fruit[2]' value='banana' />
</form>
Example URL:
http://zzz.com?fruit[1]=apple&fruit[2]=banana
Example PHP:
assert($_POST['fruit'] === array(1=>'apple', 2=>'banana'));
My questions about this:
What is the mechanism behind it? At what point do these names that contain brackets get converted into arrays? Is this a feature of the HTTP protocol? Of web servers? Of the PHP language?
Continuing the previous question, is this a commonly used hack or a normal programming tool?
What are (all) the rules for using brackets in input field names?
Can multidimensional arrays be created this way?
What is the mechanism behind? At which
point this names that merely contain
brackets are converted to arrays? Is
this a feature of the HTPP protocol?
Of web servers? Of the PHP language?>
This is a feature of the PHP language. In fact, the HTTP protocol does not forbid the use of multiple identical GET/POST parameters. According to the HTTP spec, the following:
foo=bar&foo=baz
Should not result in foo == baz. These are two parameters with two different values. However, PHP will overwrite the former foo with the latest, resulting in $_POST['foo'] == 'baz', even if they could be parsed separately.
Continuing the previous question, is
this a commonly used hack or a normal
programming tool?
It depends on the point of view. In the PHP world, it is completely normal, as the language does not support the specification of multiple parameters of the same name without using the brackets []. In the HTTP world though, foo != foo[].
What are (all) the rules of using
brackets in input field names?
The same as PHP arrays, except that you don't have to quote string keys.
Can multidimensional arrays be created
this way?
Yes, you can.
To my knowledge, this is a mechanism of PHP internally seeing (and parsing) elements passed via form (GET/POST) with the [] postfix and interpreting them as an array of elements. The HTTP protocol doesn't care, it merely passes the element's name with it's associated value in the query string.
It's been a normal programming tool as far back as I can remember (I think I even remember it more commonly used for multi-file uploads back when you had "add file" links that appended another element to the form, using the same name (with []) as the previous.)
The same rules that apply in PHP apply in the form. You can use [] to auto-index the elements (for generic lists) or explicitly list them using element IDs (e.g. file[1], file[2], etc. (following my previous example))
Yes, multi-dimensional arrays can be used.
For more information, check out PHP's very own _POST documentation (especially the comments)
This is completely php language feature. HTTP knows nothing about arrays. In http either foo or bar[baz] is just a names of variable
It is a normal practice
Use them when it is handy for you. For example: to group several fields, that belong to one entity, such as news[title] + news[body]
Yes. TIAS
Related
I want to know how this code is working:
memberpage.php?action=admin_mail_list&type=outbox
Yes, memberpage.php is a page but is admin_mail_list&type=outbox a separate page?
If No, what is it then?
If Yes, why is there no file type after the name (I mean .php or .html)?
That link is using the GET method, meaning variables are defined in the URL rather than the PHP code itself.
For example, if you were to run a Google or Bing search, it wouldn't just be:
https://google.com/search
It would be something like:
https://www.google.co.uk/search?q=test
The benefit of using this, is if the page is refreshed or sent to a friend, the variable won't need to be redefined like POST, it's already defined in the URL.
So, for example, you may have :
http://example.com/example?q=test
The /example page would have this PHP code:
echo $_GET['q'];
which would print "test".
See the following pages if you need more help.
http://php.net/manual/en/reserved.variables.get.php
https://www.tutorialspoint.com/php/php_get_post.htm
You're describing two different parts of a URI. This isn't exclusive to PHP, the URI recommendation applies to all websites regardless of their programming language.
The first (memberpage.php) is the path, and W3 describes it like this:
Path
The rest of the URI follows the colon in a format depending on the
scheme. The path is interpreted in a manner dependent on the protocol
being used. However, when it contains slashes, these must imply a
hierarchical structure.
and the second (?admin_mail_list&type=outbox) is the query string and is described like this:
Query strings
The question mark ("?", ASCII 3F hex) is used to delimit the boundary
between the URI of a queryable object, and a set of words used to
express a query on that object. When this form is used, the combined
URI stands for the object which results from the query being applied
to the original object.
Within the query string, the plus sign is
reserved as shorthand notation for a space. Therefore, real plus signs
must be encoded. This method was used to make query URIs easier to
pass in systems which did not allow spaces.
The query string represents some operation applied to the object, but
this specification gives no common syntax or semantics for it. In
practice the syntax and sematics may depend on the scheme and may even
on the base URI.
To put it simply, the path of the URI dictates which script is to be run, and fields in the query string are parameters to use in that script.
If you're familiar with working on the command line it might be easier to think of these parameters like options on a command line utility. A comparable command might look something like this:
$ php memberpage.php --admin_mail_list --type=outbox
It's important to remember that parameters like this aren't necessarily required to access the URI so it's inappropriate to think of these are arguments on a command line. If your script absolutely needs these parameters to function, you must create that logic within the script yourself, as it is not enforced by the URI.
To answer your question directly:
Yes!
Passing different parameters to the URI can lead to wildly different pages.You absolutely should consider different URI's to be different pages because from the perspective of your users and the larger web, they certainly are. Both users and search engines will consider them distinct and so should you.
That means that the "memberpage.php" script takes two parameters via $_GET:
"action" which has the value "admin_mail_list"
"type" which has the value "outbox"
See: http://php.net/manual/en/reserved.variables.get.php
I am doing programming in PHP and HTML these days. But the problem I am facing is that many times the data is accepted by the PHP engine using NAME attribute used in the HTML syntax of Forms but many times (like when there was a multi-radio button program) ID and NAME together gave me the required output.
Can anyone here give me a nice explanation of the concept and the difference between these two? I already tried googling but I could not understand.
Help will be appreciated :)
The name attribute is used on form controls (like <input>) to associate a known label with a (possibly) variable value that will appear in the submitted data. It does not have to be unique, but PHP will only handle multiple fields which share a name properly if that name ends in [].
<input name="foo" value="bar"> will be available through $_POST['foo'] or $_GET['foo'] when the form is submitted.
The id attribute can be used on any HTML element so it can be referenced with client side technologies (such as <label for>, JavaScript and fragment identifiers in URIs). It does have to be unique.
NB: It is possible to use a name attribute to reference an element with client side technologies, but it is almost always a better idea to use id (or class for groups of elements) rather then adding a name attribute.
I'm passing user-generated HTML into a database and I'm trying to make sure that no malicious code is passed through. One of the steps I'm taking is to run passed code through pear's HTML_Safe class to remove vulnerable markup. However, one thing I've noticed is that the name attribute of submitted elements gets removed. Sure enough, when you look at the source code, name is one of the few attributes that's blacklisted by default:
http://pear.php.net/package/HTML_Safe/docs/latest/HTML_Safe/HTML_Safe.html#var$attributes
What's the danger in allowing users to pass values for name? How can values for name be used to nefarious ends? Any thoughts? If not, I'm tempted to modify the blacklist.
In HTML form elements, the name attribute is used as an identifier. Therefore, if you allow name then someone may be able to override your HTML name attributes (that you may have used) with one of their own. The first matching name found is often the one used by either Javascript or server side processing.
This would then allow someone to exploit any possible Javascript or server side form processing you may be using that references the first matching name attribute found.
It is not just form elements that can use name, but they would be the least safe ones.
Another override issue is if you are using Javascripts getElementsByName in any of your functions (as pointed out below), you could end up with a function that does not do what you expect.
Edit: Some corrections and a note about getElementsByName issue (as pointed out below).
Is there anything bad in using post arrays for post variables?
<input type="text" id="stuff" name="stuff[text]"/>
instead of
<input type="text" id="stuff" name="stuff"/>
Tips when to use them?
No, there is no reason not to do this.
However, PHP is pretty much the only language which allows to create arrays like this - so if you ever change your backend to a different language you might have to change things.
It isn't a bad way. Typically programmers use array in such manner to post array with non-determined lenght. Still. Don't know for certain, but when You want to change method to GET then on IE <= 8 is a limit to 2048 chars in address lenght. And dynamic generated array can easy depleat this limit. On other browsers limit is much higher or there is none.
Another drawback of this method is that PHP will preceed correctly, but other server side languages may not. This isn't specified in official HTML docs, as far I know.
So it is more convinient to put it in a single cell in post array, that do subarray. If You want to do some namespacing, then You can write name in such way:
name="styff.text"
as do some of forum engines (for certain Vanilla 2 does).
If it has no diffrence to You I would stay to single variable name in html names. Mostly because of backend.
For tips how to use them I could recommend to use such array to cover dynamic generated content on site. Still it can be handled with normal names, but it is pretty ugly. If we have a case that You want to do a picture adding system, that I would name each input file with "pic[]" and on server iterate whole table.
The same thing for generating documents on client side. I would then do names like "content[][name]" "content[][type]" "content[][value]" and so on. Whathever I woud have in document part class I would throw in this kind of naming, and on server just check is set and do certain things for certain block of document.
This could be talked for a long time since every programmer have own technics and they tend to stick with it. For example I throw a in every form I have on site, and each action is parsed by a generall controller, and then passed by do specific controllers.
Nothing bad. If it is useful four you, use it.
In my project I have submissions and comments, each with an ID. Currently the ID's are just numeric and correspond to their database ID's. Everything is working fine but when I run it through the W3 validator I get the error:
value of attribute "id" invalid: "1" cannot start a name
I suppose instead that I could just precede all ids with some sort of string but then whenever I was using or manipulating the id in JQuery or PHP I have to do a id.replace('string', '') before using it. This seems rather cumbersome. Any advice?
Yes, using numbers as HTML element IDs is bad practice.
It violates W3C specification.
You noted this in your question, and it is true for every HTML specification except HTML5
It is detrimental to SEO.
Search-engine optimized HTML element IDs SHOULD reflect the content of the identified element. Check out How To Compose HTML ID and Class Names like a Rockstar by Meitar Moscovitz. It provides a good overview of this concept.
There can be server-side scripting issues.
Back when I first started programming in ASP classic, I had to access submitted form fields by a syntax like Request.Form("some_id"). However, if I did Request.Form(1) it would return the value of the second field in the form collection, instead of the element with an Id equal to 1. This is a pretty standard behavior for working with collections. Its also similar with javascript, and could make your client side scripting more complicated to maintain as well.
I suggest you to use prefixes "comment-ID" or "post-ID".
If you need the id in JavaScript, you just have to id.substring(8) (for "comment-")
The HTML 5 Specification lifts this restriction. If you're worried about validity you might simply consider changing the DTD to HTML5's.
http://www.w3.org/TR/html5/elements.html#the-id-attribute
If you're manipulating the element then you can just use $(this).jQueryOperation() - therefore you can have a prefix without having to replace anything!
The best way for your need is having the prefix for your class, I mean something like item-x and x is the number that you need.
But from my personal experience, it is better to use classes for your elements, and you know that you must use classes if the item is not unique in the page