Allow Anonymous users to edit Entityform Submissions

You should look at how Flag module handles anonymous flaggings -- it uses the Session API module.

If you do this you might want to add something to the README.txt and hook_requirements staging it is only advisable to use the submodule on a secure site, otherwise the cookie / link could be sniffed. There might also be implications for using reverse proxy caches, e.g. Varnish.

The SID isn't visible: the unflag link, for example, looks like flag/unflag/test_2154251_active/7?destination=node&token=19b1b1f1ff1f500d0df95111e2fd05aa&has_js=1

The 7 is the node ID.

Hi tedbow,

This module looks pretty nice, and I really like where it's heading. Just wanted to mention something I noticed.

When viewing a submission using a link, the anonymous user is shown the local tabs (View and Edit in my case). These tabs however, do not contain the token, and if clicked lead to an access denied page. For my purposes I wanted to have those tabs work for the anonymous users and allow them to edit their submission right from the view link they clicked.

I went about this by adding a hook_menu_local_tasks_alter to the entityforms_anonymous module. I am not sure if this is something you want to occur by default or not, but I figured I would send along the work I did.

I have attached a diff that I hope is helpful, but pasted below is the function I added:

/**
 * Implements hook_menu_local_tasks_alter()
 *
 * Alter the tabs that are presented to anonymous users when viewing/editing
 * their submission. By default these tabs will not have the tokens that allow
 * access to their submission, so we need to append them.
 *
 */
function entityform_anonymous_menu_local_tasks_alter(&$data, $router_item, $router_name){
  //set up a switch on the router name so we can react accordingly
  switch($router_name){
    case 'entityform/%/edit':
    case 'entityform/%':
    case 'entityform/%/delete':
      //check to see if this is an anon user
      if(user_is_anonymous()){
        //now check to be sure we have a fully loaded object
        if(isset($router_item['page_arguments'][0]) && is_object($router_item['page_arguments'][0])){
          //make sure this is an anon submitted form
          $entityform = $router_item['page_arguments'][0];
          if(_entityform_anonymous_user_submitted_form($entityform)){
            //then grab the token from the GET request
            $token = $_GET['token'];
            $query = array(
              'token' => $token
            );
            //loop through our tabs (view/edit/delete)
            //@todo ensure we are only modifying entityform tabs
            foreach($data['tabs'][0]['output'] as $k => &$v){
              $v['#link']['localized_options']['query'] = isset($v['#link']['localized_options']['query']) && is_array($v['#link']['options']['query'])
                ? array_merge($v['#link']['localized_options']['query'],$query)
                : $query;
            }
          }
        }
      }
      break;
  }
}

A couple of things still to do:

• Ensure we are only adding the token to tabs that really require the token, only the edit/view/delete tabs.
• Maybe bring into play the session API option, but at that point, altering the menu wouldn't matter. So this function would need to bail out instead of looking for a token that doesn't exist.

Hope this helps, let me know if you need anything else from me, and keep up the good work.

~ Skadu

Hi tedbow,

Thanks for taking a look, a couple of things:

Both Anonymous Options

I tried turning on both anonymous options and the tabs (without a token) do not allow view/edit access. This is because in the codebase I have:

• version = "7.x-2.0-beta4"
• core = "7.x"
• project = "entityform"
• datestamp = "1405024728"

The function _entityform_anonymous_user_submitted_form, which is called by the access_alter hook only supports the query string token, it doesn't do any checking for session based access:

**
 * Utility function to determine if current user submitted the form.
 *
 * Currently only supports query string token
 * @param $entityform
 * @return bool
 */
function _entityform_anonymous_user_submitted_form($entityform) {
  if (user_is_anonymous()) {
    $entityform_type = entityform_type_load($entityform->type);
    if (!empty($entityform_type->data['anonymous_links']) && !empty($_GET['token'])) {
      if ($_GET['token'] == _entityform_anonymous_get_token($entityform->entityform_id)) {
        return TRUE;
      }
      // @todo Message about bad token/link
    }
  }
}

Is there another codebase somewhere that checks on the session based setting? If so I would happily test and report back.

Permissions Assumption
I was under the impression (and could certainly be wrong) that permissions were handled elsewhere. In my instance, users are not allowed to delete their own entries and the delete tab does not appear on screen, even though it is available during the local_task_alter hook.

I believe this is because of the access_alter function being fired off by entityform_anonymous that checks for user access based on the current operation:

/**
 * Implements hook_entityform_access_alter().
 *
 * If user is anonymous determine if they should have access to submission
 */
function entityform_anonymous_entityform_access_alter(&$access, $op, $context) {
  // Only alter if $access not TRUE

  $account = $context['account'];
  $entityform = $context['entityform'];
  if (!$access && isset($entityform->uid) && $account->uid == 0 && $entityform->uid == 0) {
    if (_entityform_anonymous_user_submitted_form($entityform)) {
      if ($op == 'confirm') {
        $access = TRUE;
      }
      else {
        if (user_access("$op own entityform")) {
          // This is an anonymously submitted and the current user is anonymous

          $access = TRUE;
        }
      }
    }
  }
}

I just ran a quick test where I removed edit permissions, and the tab does not appear to the user. I also tried that with delete permissions being turned on and my delete link appeared, but the edit link did not. I will admit I did not take a look at entityform_access, just the access_alter being used by entityform_anonymous.

I can certainly modify the patch to first check if the user has the correct permissions before modifying the links. It seems like double work to me if the other access check is already going to ensure that the tabs are not visible to those without the correct permissions.

Happy to help debugging further. Did the patch fail to test because I'm coming from the beta version, not 2.x?

Thanks again.

~ Skadu

Hello...

Not sure this is the right place, but this is my input:

I used Rules, Tokens and an email submitted in the entityform to send an anonymous user,
links to view and edit his entityform submission.

The email received, contained full links, but when clicked on, produced:
"Access denied
You are not authorized to access this page."

Any ideas / leads?

Thank you,
Michael.

Hi Michael,

The flow you describe is exactly what I'm doing which works perfectly. Are you sure that the entityform configuration has "Provide Anonymous Links" checked?

Also, was it actually an anonymous individual who submitted the entityform? I've found that if an admin (or anyone signed in actually) fills out a form, the anonymous links are indeed generated, but they don't work for an anonymous user, instead I get the access denied message.

~ skadu

Thank you skadu..
- Yes, the entityform configuration has "Provide Anonymous Links" checked,
otherwise, no links are sent..
- Yes it was an anonymous individual who submitted the entityform, on a different computer,
without any authenticated user or admin logged on from that computer..
Michael.

Michael, have you actually given anonymous users the right permissions? It's not enough to just install the module. You need to give view/edit/delete (whichever ones you want) to the anonymous role on the permission page at:

• /admin/people/permissions#module-entityform

Can you double check those permissions and let me know what you find?

~ Skadu

You are a genius! It is working !!!
Thank you so much...
If you ever come to Israel, you have a tour to The Dead sea credit...


Michael.

Glad to you got it working! I'd love to take a tour if I ever find my way to Israel. Is that what your company does?

~ Skady

Yes...It is caled "In Low Gear" 4x4 tours of Israel..

By the way, I am not sure it is related, but if I use the HTML Mail module instead of the Mime Mail module, I keep getting the
"Access denied
You are not authorized to access this page." message..

Thank you again,
Michael.

What pages (or what action) are you trying to access that's related to the mail modules? The entityforms? Those two things shouldn't have anything to do with each other from a permissions standpoint.

The same one that did work finally with your advice:
I have a rule that sends an email with an "viewlink" to an anonymous entity form submitter.

email message:
test
[entityform:anonymous_submission_view_link]

If I set the system mail
Site-wide default MailSystemInterface class
to
DefaultMailSystem
rather than to
HtmlMailSystem
the email is received correctly (as I reported already), but without HTML features..

Michael.

Dealing with HTML formatting of emails is outside the scope of the entityform_anonymous module. I know that the DefaultMailSystem is plain text. So you have to take additional steps to add HTML.

It sounded like you were telling me that the link stops working if sent in plain text though? is that right? If so, it could be an encoding issue, but that's going to be real hard for me to figure out without digging into by hand, and I'm just not sure I can do that right now.

The plain text is working excelent (thanks to you).
But don't worry about the HTML Mail module. I will keep trying myself..
Thank you, Skadu..
And my offer for Israel is an "open date" (:
Michael.

I see these two tokens as available:

[entityform:anonymous_submission_submit_link]
[entityform:anonymous_submission_token]

I was expecting that they would both create the same random key, but they create different keys for the same submission. Is this the expected behavior?

@toddwoof - Can you confirm that the settings for the entityform in question have the resubmit action set to edit the old submission?

From the module:

$tokens['anonymous_submission_submit_link'] = array(
    'name' => t('Anonymous Submission Submit Link'),
    'description' => t('Link to allow resubmitting anonymous submission, used when resubmit action is edit old submission.'),
  );

I didn't. I'll test again. Thanks!

I don't understand how this module does anything useful.

The link I get from [entity:anonymous_submission_view_link] is http://myurl.com/entityform/2253?token=e8f7e9df9ff8e9d675af29b3618f317f&...

Great, but if I delete everything after 2253 I get the same page and in order for it to work I have to open up read access to all of my entity forms.

What's to stop someone from going through my entityform submissions? I would have no problem with allowing read access to forms if the token was required but it's not. The root http://myurl.com/entityform/2253 url is still valid. How to make the token required?

It sounds like you have granted permission for anyone to view any entityform submission. I'm using this module to handle form submissions, and the token is required to access the form submission as well as edit the form submission. Can you confirm your permissions for entityforms look something like this:

My apologies! I read the instructions on #20 but did not see specific directions on the correct permissions. This works! Thanks

Authenticated users are also contributing form submissions. The anon links for these submissions don't work because of permission issues. Is there any way around this? I'd like to allow anon access to these forms regardless of which users submit them.

Thanks

I found this line in entityform_anonymous.module
(line 108)

if (!$access && isset($entityform->uid) && $account->uid == 0 && $entityform->uid == 0) {

change to:

if (!$access && isset($entityform->uid)) {

If I delete the 2nd && of the statement I can view authenticated submissions with the anon link. As far as I can tell I don't have any other access to submissions without a valid token.

Does this open me up in an unexpected way?

If you submit an entityform while authenticated, that entityform cannot be accessed using anonymous links. The owner of that entityform is automatically assigned to the user account that created it.

I am not the author of this module nor do I claim to fully understand the security impacts of your change....

However, it seems that change will sort of open you up. It will indeed grant you access to the form created by an authenticated user if you are using the anonymous access link which it sounds like is the desired impact for you.

It means that an anonymous visitor could access the entityform of the authenticated user, which feels wrong to me.

Although, I guess it is really no different than if someone else ever gained access to any other anonymous link.