Implemented: Properly encode parameters for form fields with ENCODE variable
Search forms like
FormattedSearchFormTesting and
TWikiApplication sometimes show URL parameters in a form field using the
%URLPARAM{...}%
variable. URL parameters need to be encoded properly into
HTML entities before passing it into a form field. There are two enhancements to do that:
1. ENCODE variable with
type
parameter
The existing
%URLENCODE{...}%
variable is renamed to
%ENCODE{...}%
, and a new
type
parameter is added. The URLENCODE variable is kept as an undocumented feature to be backward compatible. The
type
parameter can be set to
"url"
for URL encoding (default), or
"entity"
to encode special characters into
HTML entities. Other encoding types can be added in the future as needed.
Example
<input type="text" name="myparam" value="%ENCODE{ "%PARAM{ "myparam" }%" type="entity" }%" />
2. PARAM veriable with
encode
parameter
The existing
%URLPARAM{...}%
variable is renamed to
%PARAM{...}%
, and a new
encode
parameter is added. The URLPARAM variable is kept as an undocumented feature to be backward compatible. The
encode
parameter can be set to
"url"
for URL encoding, or
"entity"
to encode special characters into
HTML entities, default is no encoding. Renaming the variable is in preparation of
ParameterizedIncludes.
Example
<input type="text" name="myparam" value="%PARAM{ "myparam" encode="entity" }%" />
Contributors:
--
PeterThoeny - 14 Jan 2004
Sample form
Try out above form. All it does is to show the submitted text in the text field. It should work for these special characters: (please report if you experience any problem)
Char |
Problem |
Fix |
" |
Double quote and text after disappears because it gets interpreted as the end of the value parameter |
Escape with " |
% |
Variables like %WEB% and %INCLUDE{...}% get expanded |
Escape percent sign with % |
* , _ , = |
TWiki formatting like *bold*, _italic_ and =fixed= get interpreted |
Escape with * , _ , = |
[ , ] |
[[][]] links like [[WebHome][home]] get interpreted |
Escape with [ , ] |
< , > |
HTML tags get interpreted, like when you enter normal<italic>normal |
Escape with < , > |
| |
Fails if form field is in a TWiki table |
Escape with | |
WikiWord |
WikiWords get autolinked |
Place whole form into <noautolink> tags |
Above characters need to be converted into their
HTML entities if placed in
HTML form fields.
Possible solutions
1. Introduce new ENTITYENCODE variable
The
%ENTITYENCODE{...}%
variable (any better name?) encodes special characters into
HTML entities.
Example
%ENTITYENCODE{ "%URLPARAM{ "myparam" }%" }%
Pros and cons:
- Simple to use
- Consistent with existing
%URLENCODE{...}%
variable
- Slightly slower rendering due to new variable
2. Add an encode
parameter to URLPARAM variable
Special characters get translated into their
HTML entities if the
encode="entity
parametr is specified.
Example
%URLPARAM{ "myparam" encode="entity" }%
Pros and cons:
- Simple to use
3. Add a translate
parameter to URLPARAM variable
The
translate
parameter can be used to change special characters into their
HTML entities. The parameter has comma delimited
from,to pairs;
$quot
represents the double quote char.
Example
%URLPARAM{ "myparam" translate="$quot, ", %, %, <, <, >, >, |, |" }%
Pro and cons:
- Flexible to do all types of conversions, not just HTML entities
- More complex to use
4. Rename URLENCODE to ENCODE and add type
parameter
Rename
%URLENCODE{...}%
to
%ENCODE{...}%
, but keep URLENCODE as an undocumented feature to be backward compatible. Add a
type
parameter:
type="url"
for URL encode (default),
type="entity"
to encode special characters into
HTML entities.
Example
%ENCODE{ "%PARAM{ "myparam" }%" type="entity" }%
Pros and cons:
--
PeterThoeny - 14 Jan 2004
Discussions
Opinions?
--
PeterThoeny - 14 Jan 2004
I like option 2. However, is there any reason to encode something that is
not from a url parameter where option 1 would be required?
--
SamHasler - 14 Jan 2004
An interesting failure above is that if you enter a closing right angle bracket, for example,
,test>
in above field, the submit button disappears. The vertical bar gets interpreted (into a table cell separator), as are TWiki variables.
--
ThomasWeigert - 14 Jan 2004
At work I got feedback for option 4. I like option 2 and 4, favoring option 4.
Option 2 has the advantage that a Plugin can use it without breaking an older TWiki installation (just fallback of not supporting special chars)
Option 4 has the advantage that content
not received by URL parameter can be encoded as Sam pointed out. It also is extensible for other encoding types added in the future.
--
PeterThoeny - 14 Jan 2004
I implemented option 2 and 4 because it was easy and it does not degrade the performance.
A small change to the parameter parsing of variables was necessary so that double quotes are treated properly: The nameless parameter may now contain double quotes. Example:
%ANYVAR{ "now you can use "quoted text" in the nameless parameter" param="one" more="etc" }%
Change is in
TWikiAlphaRelease and TWiki.org.
--
PeterThoeny - 14 Jan 2004
Using this could you put the simple search and advanced search forms from the
WebSearch page on separate topics (alternatively paramaterised includes could be used to keep the forms on the
WebSearch topic) and have the search results contain the forms for easy re-searching with the search parameters as they were entered for the search?
--
SamHasler - 15 Jan 2004
Sounds like a good idea, split up into
WebSearch and
WebSearchAdvanced should be done.
--
PeterThoeny - 14 Jan 2004