Introduction - mod_ssi_setsplitvars
The mod_ssi_setsplitvars module hooks into apache mod_include and provides a "setsplitvars" directive to split a string composed of value pairs into server-side variables and assigned values. This can be done in mod_include in apache 2 using the PCRE regular expressions captures $0-$9
Parameters
- delimiter
- the character(s) which delimits the var=val value pairs, as in a=23&b=45 the delimiter is &, the default setting for the directive is '&'
- separator
- the character(s) which separates the var=val value pairs, as in a=23&b=45 the separator is '=', the default setting for the directive is '='
- allow
- allow this variable to be set even if it is already set or the name is only made up of characters in [A-Z_] (when in restricted mode, explained below)
- decoding
- takes the values, url, entity, url_entity (ie both), none, default is none - see echo encoding http://httpd.apache.org/docs-2.0/mod/mod_include.html#element.echo
- value
- the string to split
Results
All the variables are set with their corresponding values if the
following restrictions are met:
- variable is not already set*
- variable name contains [a-z]*
( * these can be set using allow as above)
Examples
The following sets the variable "hello" to "world" and "foo" to "bar":
<!--#setsplitvars value="hello=world&foo=bar" -->
It can be used to separate the Query String
<!--#setsplitvars value="$QUERY_STRING" -->
or the user cookie string for postcoder information
<!--#setsplitvars delimiter="; " separator=":" value="$HTTP_COOKIE" -->
Warning (/explanation of the allow parameter)
SetSplitVars is a shortcut to put server variables on a page quickly from a string, such as the query string. As such there is a potential security gap of allowing the query string to set variables in the page and this being open to user input as part of the url. If we were to use SetSplitVars on the following url:
http://foo.bar.com/test.shtml?foo=bar&bar=foo
We would in this caes be wanting to pass those variables to the page. But if someone came along and entered:
http://foo.bar.com/test.shtml?foo=bar&bar=foo&PATH=/my/new/path/
They could potentially alter other environment level server variables which we would not want them to have access to.
Our solution to this is to limit, as above, to not allow variables that are formed of only uppercase letters, or ones that are already set on the page, unless specifically 'allow'ed in the html code of the page.
The 'limit', as described, has to be enabled in the server conf. The default as compiled is to have to allow each and every variable. The restricted version is as described above. The other option is to allow anything to be set without restriction in 'allow'ing.
Each allow must be set separately, e.g.
<!--#setsplitvars delimiter="; " separator=":" allow="foo" allow="bar" value="$HTTP_COOKIE" -->
Configuration
The following should be entered in the server conf file.
- SSI_SetSplitVars none
- This requires any varible you wish to split using this functionality to be explicitly 'allowed'. This is the default setting.
- SSI_SetSplitVars restricted
- This 'allows' any variable to be split with the restrictions laid out above, ie must not contain only uppercase and underscores.
- SSI_SetSplitVars all
- This 'allows' any variable to be split without restriction
Requirement
The ordering of the parameters as set out in the examples is important, ordering these differently will result in the function not working.
|