Identity bug: Form field names with dots in the name won't work

[strea...@googlemail.com]

I'm trying to use my own forms for Identity.

As ToscaWidgets concatenates the named of nested form widgets by dots,
the request looks like:

/login?login.user=user&login.pass=pass&login.submit=Login

Unfortunately (at least in this case), TurboGears seems to use
formencode.variabledecode.variable_decode to create a nested dict out
of the request params.
The params therefore are:

{'login': {'user': 'user', 'pass': 'pass', 'submit': 'Login'}}

But Identity cannot handle nested request params.
See turbogears.identity.identity_from_form:

submit= params.pop(self.submit_button_name, None)

That, of course, won't work when self.submit_button_name is
"login.submit", because no such key exists.
Instead the value is found in params['login']['submit'].

A simple fix would be to use this as the first line in
identity_from_form:

params =
formencode.variabledecode.variable_encode(cherrypy.request.params)

I don't think that it should have negative side effects.
What do you think?
Someone wants so issue a bug ticket for that?

[Felix Schwarz]

strea...@googlemail.com wrote:
(...)

> Unfortunately (at least in this case), TurboGears seems to use
> formencode.variabledecode.variable_decode to create a nested dict out
> of the request params.
> The params therefore are:
>
> {'login': {'user': 'user', 'pass': 'pass', 'submit': 'Login'}}

(...)

> A simple fix would be to use this as the first line in
> identity_from_form:
>
> params =
> formencode.variabledecode.variable_encode(cherrypy.request.params)
>
> I don't think that it should have negative side effects.
> What do you think?
> Someone wants so issue a bug ticket for that?

You can file a bug ticket yourself, please go ahead.

IMHO, there should be a possibility to disable the variabledecode on a
by-function basis. Obviously, this is not possible with the current
implementation of NestedVariablesFilter as a CherryPy before_main filter. The
latter causes problems with unit tests too if you use testutils.call.

Therefore I already thought about moving the NestedVariablesFilter into the
expose function (did not investigated that one thoroughly though), making the
variable decoding a keyword parameter for expose (defaults to True in order to
preserve the current behavior). When the current filter is moved into a
decorator, your problem will vanish immediately.

Currently, I don't see any negative effects of doing this. If you file a ticket,
we can move the discussion to the devel list and discuss a solution there.

fs

PS: Please send me a ping after you opened the ticket.

[Paul Johnston]

Hi,

>IMHO, there should be a possibility to disable the variabledecode on a
>by-function basis.
>

I suggest moving the decoding out of a filter and into the @validate
decorator. I don't expect this would break much - usually the decoding
is just to support the validation.

Something for TG 1.1?

Paul

[strea...@googlemail.com]

On Oct 14, 3:39 pm, Felix Schwarz <felix.schw...@web.de> wrote:
> PS: Please send me a ping after you opened the ticket.

The ticked is filed at http://trac.turbogears.org/ticket/1587

[Felix Schwarz]

I would like to talk about this topic in turbogears-trunk, I just opened a
thread there.