cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: [RT] Flowmaps
Date Wed, 19 Jun 2002 18:19:47 GMT
On 6/18/02 12:48 AM, "Christian Haul" <>

> On 18.Jun.2002 -- 12:09 AM, Ovidiu Predescu wrote:
>> On 6/17/02 11:22 PM, "Christian Haul" <>
>> wrote:
>>> On 17.Jun.2002 -- 09:35 PM, Ovidiu Predescu wrote:
>>>> - automatic binding of JavaScript variables to form values. This would
>>>> allow
>>>> you to declare something like:
>>>>   var username, password;
>>>>   // Send a page to collect the user name and the password
>>>>   sendPage("login.html");
>>>>   // When the user fills in the form and presses the submit button, the
>>>>   // script restarts here. The flow engine automatically binds the username
>>>>   // and password to the values submitted in the form.
>>> Don't. It was one of the biggest mistakes PHP did securitywise. Always
>>> access request parameters explicitly.
>> Yes, I read somewhere about this, but don't know the details. Can you
>> explain some more?
> The real problem is that an attacker could provide additional parameters
> that coincidently have the same name as a variable used for other
> purposes in the php script like changing the database connection name,
> path to a file (i.e. /etc/password) or to an include.
> Therefore php now enforces the use of $HTTP_PARAMETERS['name'].

Ah, I remember this problem. No, I wasn't thinking to have this type of
automatic binding, sorry for not explaining the idea better. Instead, what I
was thinking of is a way to specify how to map a form parameter to a
JavaScript variable.

>> I actually like the way variables are automatically bound in WebObjects,
>> where you have to explicitly define the automatic binding, by mapping an
>> instance variable to a form parameter. I was thinking to follow a similar
>> pattern, and have a way to specify that a given local variable in a function
>> is to be bound to a form parameter. In WebObjects this association is
>> totally under the control of the programmer, and the same way should be done
>> in Cocoon.
>> Could this be a potential security problem?
> No, that is absolutely OK since the author controls exactly which
> variables contain unchecked values which are safe to use.
> Anyway, given that we are going to be able to use input modules in
> the sitemap through "{modulename:parameter}" it would be great if it
> would be the same for the flow.

I'm not sure it would be the same thing though. With the mechanism you
mention, you can pass values to functions in the sitemap only when you enter
a function. When you restart an existing continuation, which could restart a
function from the middle, I'd still like to have the ability to specify how
existing request parameters are to be bound to script variables.

> Just another thought (I'm not yet up to speed with the flow so ignore
> if I'm talking rubbish): Is it possible (and would it make sense) to
> call an action like
> result = actions['database']( { 'parameter' -> 'value', 'parameter' ->
> 'value'});
> (I know javascript uses associative arrays, but is there really a
> literal form?)  With the script engine adding the 'usual' parameters
> for the act call and result being an associative array containing the
> returned map. This way we could continue using all the nice actions. :-)

I think it should be possible to do this, as long as we wrap actions as
JavaScript functions. This way an action appears as nothing else as a
function you can call from your script. I haven't looked at it though.


To unsubscribe, e-mail:
For additional commands, email:

View raw message