Forum OpenACS Development: Re: What's wrong with forms

Posted by Don Baccus on
Generating a random external name for the form would be simple enough to add to either ad_form or a meta-data based form generator.  It would be simple to do this to for elements as well.

I would be surprised if people would prefer to go back to the "call a procedure to create the form, call a procedure to create each form element one by one" approach, which after all is the form builder approach that people found so annoying and which *most* (not all, particularly not you) find much less convenient than the declarative approach ad_form takes.

You mention signed values in ad_form (actually just a form builder feature ad_form exposes).  For object generation, or actually for any table with an integer primary key, ad_form signs and verifies the key it automatically generates.

Do you (or anyone else) have any comment to make about what level of security this provides?  I'm not trying to be provacative, it's a serious question.

In addition, if we used your example above, the random external name for a form could be passed as ad_sign'd "secret" parameter, and being valid only for that submission would be impossible to guess, no?

Which doesn't stop a program from maliciously changing HIDDEN variables which aren't signed ... perhaps -export {} should sign and verify the exported values (the preferred way to pass hidden values using ad_form)?

Posted by Jeff Davis on
Don, signed variables suffice to insure that the values are not corrupted by the client but anyone malicious could fairly easily forge signed variables, it just came up recently.
Posted by Bart Teeuwisse on

my limitted experience with ad_form hasn't been all that good and hence I prefer to use the form builder procs directly. I'm working on support in Emacs OACS to reduce the amount of typing to declare form elements.


Posted by Tom Jackson on

Don, you are right, I'm not suggesting going back to the one procedure call per form and element, at least on the level used by developers. I'm just guessing that somewhere inside ad_form this is what happens. At that point, you could add the features I'm suggesting.

I think it should be easy to do with the existing tools, or the upcoming meta-data tool. In fact this is the reason I am mentioning it now. My query-writer has lots of metadata information, but is very lacking in security for preventing xxs, etc. But it also lacks enough information to help the user correct errors, and to eliminate needless updates. Also, the metadata is about objects and attributes, good for filters, help messages, etc., but it lacks metadata for a specific form submission. Certain metadata would be very helpful to have around, mostly the original values selected for update, but for auto generated forms, you would need auto generated form-handlers, I guess. These might need the types of information I outlined in my original post: operation, object, attribute, id.

I think signed variables are relatively secure, the same process would go into creating a form name. In that case, I guess what would be signed would be a combination of the session_id, a server secret and whatever other information might be useful in creating a unique token to hash.

One question I haven't resolved is if the form could be used only once. Maybe once the form was used it could be either invalidated, or reset? For new data input forms would it be useful to be able to back up and make a few changes to create new data? I don't think ad_form supports this, but it will probably still be the job of the form processor to invalidate the form before it expires with the session.

But this process probably would not be much more secure than what we have now if forms are allowed to use GET. POSTed data will be more difficult to fake, and a script might still be able to work around the difficulties by requesting the form first to set things up. The final step may still require action that only a human could perform. But security is not the only goal, and not even the main one.