1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
Wapp Parameters
===============
When a Wapp application runs, its purpose is to answer an HTTP request.
The value of parameter whose key is _NAME_ is retrieved
using a call to [wapp-param _NAME_]. If there is no parameter with the
key _NAME_, then the wapp-param function returns an empty string.
argument is returned if no parameter with a key of _NAME_ exists.
1.0 Parameter Types
-------------------
Each request has four different kinds or sources of parameters:
1. **CGI Parameters**
|
|
|
|
>
|
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
Wapp Parameters
===============
The purpose of a Wapp invocation is to answer an HTTP request.
That HTTP request is described by various "parameters".
Each parameter has a key and a value.
The Wapp application retrieves the value for the parameter with
key _NAME_ using a call to [wapp-param _NAME_].
If there is no parameter with the key _NAME_, then the wapp-param
function returns an empty string.
Or, if wapp-param is given a second argument, the value of the second
argument is returned if there exists no parameter with a key of _NAME_.
1.0 Parameter Types
-------------------
Each request has four different kinds or sources of parameters:
1. **CGI Parameters**
|
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
parameters to see how this affects the Wapp parameters.
Notice in particular how query parameters are decoded and added to the
set of Wapp parameters.
2.0 Security By Default
-----------------------
For security reasons, the automatic decoding of Query and POST parameters
only occurs if the inbound request is from the "same origin" or if the
special "wapp-allow-xorigin-params" interface is called. An inbound
request is from the same origin if it is in response to clicking on a
hyperlink or form on a page that was generated by the same website.
Manually typing in a URL does not constitute the "same origin". Hence,
in the example above the "wapp-allow-xorigin-params" interface is used
so that you can manually extend the URL to add new query parameters.
If query parameters can have side effects, then you should omit the
wapp-allow-xorigin-params call. Only invoke wapp-allow-xorigin-params
for web pages that only query information. Do not invoke
wapp-allow-xorigin-params on pages where the parameters can be used
to change server-side state.
|
>
>
>
>
>
|
|
|
|
|
>
|
|
|
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
parameters to see how this affects the Wapp parameters.
Notice in particular how query parameters are decoded and added to the
set of Wapp parameters.
2.0 Security By Default
-----------------------
Parameter values in the original HTTP request may be encoded in various
ways. Wapp decodes parameter values before returning them to the
application. Application developers never see the encoded values.
There is never an opportunity to miss a decoding step.
For security reasons, Query and POST parameters are only added to the
Wapp parameter set if the inbound request is from the "same origin" or
if the special "wapp-allow-xorigin-params" interface is called.
An inbound request is from the same origin if it is in response to
clicking on a hyperlink or form on a page that was generated by the
same website.
Manually typing in a URL does not constitute the "same origin". Hence,
in the "env.tcl" example above the "wapp-allow-xorigin-params" interface
is used so that you can manually extend the URL to add new query parameters.
If query parameters can have side effects, then you should omit the
wapp-allow-xorigin-params call. Only invoke wapp-allow-xorigin-params
for web pages that only query information. Do not invoke
wapp-allow-xorigin-params on pages where the parameters can be used
to change server-side state.
|