There seems to be a validation error if you use a form saved from another session.

I've only tried on a highly customised form, but to replicate:

1) Edit a node and let autosave save the form
2) In another window / tab, log out then log back in
3) Refresh the page and select view / keep
4) Save

I'm getting: "Validation error, please try again. If this error persists, please contact the site administrator."

Which translates to this line in orm.inc:

  if (isset($form['#token'])) {
    if (!drupal_valid_token($form_state['values']['form_token'], $form['#token'])) {
      // Setting this error will cause the form to fail validation.
      form_set_error('form_token', t('Validation error, please try again. If this error persists, please contact the site administrator.'));
    }
  }

So somehow the module needs to update this.

IE: (Drupal 6 version)

    $form['#token'] = $form_id;
    $form['form_token']['#default_value'] = drupal_get_token($form_id);
CommentFileSizeAuthor
#8 autosave-invalid_token-1400764-8.patch2.17 KBsumthief
#7 autosave-invalid-token-1400764-6-against-7.x-2.2.patch1.7 KBmsmithcti
#6 autosave-invalid-token-1400764-6.patch1.87 KBmsmithcti

Comments

ferrum’s picture

ferrum commented

This problem often occurs in combination with module autologout. In case of inactivity the user is automatically logged out. The next login creates a new session with new session token and the autosaved forms never match the necessary form token.

To avoid this change autosave_form_alter
from

      if ($autosaved_form = autosave_get_autosaved_form($form_id, $path, $user->uid)) {
        //$autosaved_form_id = $form['type']['#value'] ? $form['type']['#value'] .'_node_form' : 'node_form';
        $settings['autosave'] = array_merge($settings['autosave'], array(
          'serialized' => unserialize($autosaved_form['serialized']),
          'saved_date' => format_date($autosaved_form['timestamp'], 'medium'),
        ));
      }

to

      if ($autosaved_form = autosave_get_autosaved_form($form_id, $path, $user->uid)) {
        //$autosaved_form_id = $form['type']['#value'] ? $form['type']['#value'] .'_node_form' : 'node_form';
        $settings['autosave'] = array_merge($settings['autosave'], array(
          'serialized' => unserialize($autosaved_form['serialized']),
          'saved_date' => format_date($autosaved_form['timestamp'], 'medium'),
        ));
        $settings['autosave']['serialized']['form_token'] = $token;
      }
quicksketch’s picture

quicksketch
he/him
commented

I'm not sure this is entirely a bug. I don't think this module is made to persist changes between sessions. On a lot of sites, one user account (typically User #1) may be shared between multiple users. If autosave was not session-specific, multiple users creating the same type of content would have their auto-saving changes wiping each other out. Perhaps we can make this module handle the error more gracefully, but I think this behavior may be by design.

alan d.’s picture

alan d. commented

The behavior is right at the base of the Forms API, (form token validation), but the regeneration of the token by ferrum looks like it may work. Maybe this coupled with an big warning message, "This form was retrieved from a saved session on 2:35 pm, xx July. It may be possible that this content has been changed since. Saving here would overwrite those changes." or something along those lines, would do nicely :)

I know Views admin area has a lock notice warning about potential stale data, that may have a better base message?

We ended up dropping this and autolog out due to the associated issues related to the forms. These were student assignments done online, and some pages had multiple long text sections and other form elements (about 60 on one page of the 9 page multistep form).

quicksketch’s picture

quicksketch
he/him
commented

We ended up dropping this and autolog out due to the associated issues related to the forms.

What solution did you end up using then? Or do your users just have no autosaving at all now?

I know Views admin area has a lock notice warning about potential stale data, that may have a better base message?

Yep, I'd definitely like this to be the behavior when editing an existing node. It doesn't make any sense to allow multiple users to edit the same node anyway, since Drupal will throw an error if two users try to save. However as far as *new* nodes go, there shouldn't be any limit on the number of nodes that can be created of the same type by multiple different users. So something like ferrum's approach would be good for existing nodes but new nodes should still be per-session, IMO.

alan d.’s picture

alan d. commented

Regarding #1, no autosaving. It was an hourly rate project and the client didn't want to budget any time looking into it.

Big wow, if you can find the time for an autosaving locking feature for content. This could end up as a default module added to all sites. :)

(Global thoughts, I can't remember if the module is locked to node forms)

Changing the token for new content forms that are autosaved would mean that you would still have the same form / same data, so if the user hits save there would be no issues. Duplicate content can be deleted with 2 clicks, recovery of a lost form data could mean hours of work.

I would go as far as to say, that if the form has a primary id field and this is empty, then the autosave should automatically populate with the saved details the next time a user visited this page where there is a corresponding saved form, with a dismiss option to reload with a empty form.

If the form has a populated id, then the autosave works around the purposed locking system.

Just my 2c, as we are not actually using this currently nor can I find time to help out other than throw out random ideas. My time is being spent trying to refactor the Diff module atm, to make it a global API for any content: entities, webform submissions, .... so I think that this will take up the next few weeks (or more).

msmithcti’s picture

msmithcti commented
Version: 6.x-2.x-dev » 7.x-2.x-dev
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new autosave-invalid-token-1400764-6.patch1.87 KB

I have had the same problem as described in the issue summary where a form is available to be restored across sessions even though the token is invalid across sessions. This causes the "form outdated" message on attempting to then save a restored form.

The attached patch checks that the form token is still valid before offering the option to restore.

msmithcti’s picture

msmithcti commented
StatusFileSize
new autosave-invalid-token-1400764-6-against-7.x-2.2.patch1.7 KB

Incase it is useful to anyone, here is the patch again, but against the stable (7.x-2.2) release.

sumthief’s picture

sumthief commented
StatusFileSize
new autosave-invalid_token-1400764-8.patch2.17 KB

Hello

Here is my vision of this problem (and small codestyle changes).