On Jan 8, 2007, at 3:21 PM, Jorge Godoy wrote:
Alberto Valverde <[EMAIL PROTECTED]> writes:
Phew! Then I can't think of a safe way to do that... How can you
trust JS
code to decide which fields should skip validation? I think that
that hidden
There's no way to delegate that to the user side. Not safely.
JavaScript can
be (easily) replaced.
field should only serve as a vehicle to pass state from the
method displaying
the form to the method validating input across requests. Maybe
that JS code
could call server code asyncronously to obtain a new encrypted
hidden field
(letting the server side code decide if it allows changing state)
but I fear
this is getting overly complicated and could be a source of nasty
security
holes if not carefully implemented...
This is why I believe this could be a new class of forms. It is a
requisite
that doesn't apply to most use cases and if someone needs it then
he'll have
to deal with the traffic and the mechanism implemented (or to be
implemented).
Ideas?
Only AJAX for the moment. Then it could set some state on the
client that
would change the validation behaviour for that specific "submit",
i.e., if I
open the same form on two different tabs, change one of them and
submit the
other, then this other would be processed by default rules while
the changed
one would be processed with the new rules.
We'd probably need to have separate schemas and signal which one
should be
used. How to keep this selection stateless is a problem we'll need
to discuss
and solve... Maybe here the HASH with a validation schema name
would be
enough since we'd check a dictionary à la:
@validate(schema = my_schemas['hash']())
or something like that. my_schemas would be a class variable
defined like:
import my_forms # forms and schemas for the app / controller in
question
class MyController(turbogears.Controller):
my_schemas = dict(
'hash1' = my_forms.schema1,
'hash2' = my_forms.schema2,
'hash3' = my_forms.schema3,
)
I was thinking of something more like a a Schema subclass (which
you'd have to subclass if you want this functionallity that did
something like:
class TGSmartSchema(Schema):
def _to_python(self, value, state=None):
disabled_fields = pickle.loads(
self.decrypt(value.pop('form_state'))
)['disabled_fields']
self.disable_fields_for_request(disabled_fields, state)
return super(self, TGSmartSchema)._to_python(value, state)
That should make possible to use the same schema and let the form
decide when being displayed which fields should be disabled or
whatever. Mind, that state could not be changed client-side unless
the code that generates the hash can be called asyncronously to
provide new hashes based on parameters (which could, by the way, make
the implementation less secure as more and more bits of the key could
be computed by watching how the hash varies as parameters change (if
same key is reused)). Phew... not something I'd like to implement
myself... ;)
The problem, then, becomes passing 'kwargs' to the decorator.
(Pardon me for
overly complex design here on this simple thing, I'm with a cold...
Everything hurts.)
Hehe, I thought colds were something you forgot about in when living
in sunny Brazil... ;)
Alberto
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
