Support » Plugin: Loushou: ACF for WooCommerce » Previous form entry visible on next form view

  • This is a fairly critical bug, as it causes unexpected data disclosure!

    I am using a form to collect personal details on the checkout.

    The previous values entered into the checkout (by the previous customer) are presented in the form for the next customer!

    I’ve verified that it is not a cached copy of the page.

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter nickbreen


    ACF version is 5.3.1, as of writing 5.4.7 is current.

    I’ve debugged and isolated the issue down to the storage of checkout values as WP Options due to the order not existing yet when at the checkout. The “fake” post_id used to store the checkout fields is "checkout_" . $post_id which is always checkout_0 as there is no post/order yet.

    When anyone goes to the checkout, if there are checkout_0_* options then they get loaded!

    • This reply was modified 5 years, 1 month ago by nickbreen.
    Thread Starter nickbreen


    Found this support ticket

    Relevant answer:

    Can you check your wp_options table for any rows where the option_name starts with ‘new_’ or ‘options_new_’.

    It is possible that during testing, your code saved it’s values with a post_id of ‘new’ and now your post is loading from ‘new’.

    If the rows exist in the DB. Please remove them, and your form should clear out.

    It’s a mystery why those options persisted, but deleting solved the problem, though I’m not confident that the problem won’t happen again.

    Thread Starter nickbreen


    The issue keeps re-occurring with checkout_0_* and _checkout_0_* options persisting in the DB. E.g.

    $ wp option list --search=*checkout_0_*
    | option_name                                       | option_value             |
    | checkout_0_passenger_0_name                       | [REDACTED]               |
    | _checkout_0_passenger_0_name                      | field_57f87d67f77e7      |
    | checkout_0_passenger_0_dob                        | [REDACTED]               |
    | _checkout_0_passenger_0_dob                       | field_57f87d76f77e8      |
    | checkout_0_passenger_0_age                        | [REDACTED]               |
    | _checkout_0_passenger_0_age                       | field_57f87d88f77e9      |
    | checkout_0_passenger_0_gender                     | [REDACTED]               |
    | _checkout_0_passenger_0_gender                    | field_57f87d98f77ea      |
    | checkout_0_passenger_0_nationality                | [REDACTED]               |
    | _checkout_0_passenger_0_nationality               | field_57f87daaf77eb      |
    | checkout_0_passenger_0_address                    | [REDACTED]               |
    | _checkout_0_passenger_0_address                   | field_57f87dc6f77ec      |
    | checkout_0_passenger                              | 1                        |
    | _checkout_0_passenger                             | field_57f87d40e2864      |

    * It’d be safe to use transients rather than ordinary options, so they also get an expiry.
    * The event(s) that clear these values do not seem to fire consistently.

    • This reply was modified 5 years, 1 month ago by nickbreen. Reason: formatting
    • This reply was modified 5 years, 1 month ago by nickbreen. Reason: formatting

    Any news on this? Facing the same issue.

    Thread Starter nickbreen


    Hmm, I’d thought I’d posted a suggestion for this a month ago… apparently not.

    The core of the problem is that prior to checkout submission there is no post ID to store the custom field data against and the implementation temporarily stores the data in wp_options with a _non-unique_ key.

    The simplest change to make is to randomise the storage of the data in options. Perhaps by:
    # use a nonce value,
    # Use this value to generate the name of the wp_options record
    # Reconstruct the data from the option on form submission.

    Alternatively store the data against an actual CPT entry and substitute for the order afterwards.

    Thread Starter nickbreen


    Any update on this issue?

    The issue makes this plugin fundamentally unusable on a woocommerce installations with concurrent orders and/or sensitive data collection.

    I’m assuming that no one has heard from @loushou about this?

    I’ve just hit the same issue and it’s a real problem; the client was using it to collect sensitive data.

    A wild guess here, but would an action to remove the checkout_0_ options every time the checkout is loaded help?

    I made a quick tool to remove the extra fields from the admin tools.

    Feel free to use if it helps you.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Previous form entry visible on next form view’ is closed to new replies.