Forum OpenACS Q&A: Re: ad_form and getting around postgres

Posted by Don Baccus on
Though you didn't post the full ad_form declaration it is clear that you've defined "brand_id" as type "key", which means that ad_form is defining its value for you as well as signing and verifying it to guard against malicious code POSTing to the page.

Since it is already set you should be passing it in to your new() proc, that is the whole point of using ad_forms's automatic key generation.  Why generate it if you aren't going to use it???

select foo_new(:brand_id, ...);
update foo set ... where brand_id = :brand_id,

Don't pass null into new as brand_id.  Don't assign the result of new to brand_id.  Use the value of brand_id assigned by the ad_form key management stuff.

Posted by Jade Rubick on
Don, you were exactly right.

Just for everyone else that might find this thread, here's my corrected ad_form declaration:

ad_form -name add_edit -form {


    ... declaration of form elements

} -select_query_name brand_select -on_submit {

    set user_id [ad_conn user_id]
    set peeraddr [ad_conn peeraddr]

} -new_data {

    db_transaction {
      db_exec_plsql new_brand { }
      db_dml brand_update { }

    ad_returnredirect "."

} -edit_data {

    db_dml brand_update { }

    ad_returnredirect "."



The bug was in the add-edit-postgres.xql file. Here is how it was:

<fullquery name="new_brand">
      select brand__new(
          [db_nextval brand_brand_lid_seq],

If you look at the declaration of brand__new, the first parameter is brand_id. I was passing it null, so it wasn't getting the brand_id that was generated by ad_form.

Hopefully, this will help out someone else that makes the same mistake I did.

For the search engine: postgres 16 argument ad_form key changes