It appears as though anonymous users are getting access to transition states which should be available only to authenticated users. In addition, anonymous users are not getting access to transitions which they are explicitly set for.

I'm not submitting this as a bug report because I haven't tested the problem against a default installation. So, I'm hoping someone can help me further my troubleshooting efforts as I seem to have run into a dead end.

We're running:
Drupal 5.8-dev
Workflow 2.2
Workflow Access 2.2
php 5.2.5
MySQL 5.0.45

We've got a relatively complicated publishing model we're using, which allows members of the site to access content by other members while restricting anonymous viewing until something has been made public (set to a state viewable by anonymous users). We also allow anonymous users to create content and have two states set up for them to choose from, one explicitly set for the anonymous role, the other granted by the author setting. We had this running just fine, then I believe it happened after we upgraded from workflow 1 to workflow 2 (can't say it was the upgrade that did it, but it was sometime after and I can't guarantee it was functioning perfectly right after the upgrade).

Expected behavior:

Anonymous creates new content, has a choice for:
State 1 (available to anonymous at creation)
State 2 (available to author at creation)

Actual behavior:

State 2 (available to author at creation)
State 3 (available to authenticated at creation)
State 4 (available to authenticated at creation)
State 5 (available to authenticated at creation)

I've checked the workflow_transitions table, and role 1 (anonymous) is available in exactly one transition, the one I set it for.

Things I've tried:

  • Empty cache
  • Truncate sessions table
  • Rebuild permissions on access_node
  • Deselecting the anonymous role under the states on the creation row at admin/build/workflow/edit/wid, saving, then creating content still exposes the states from "Actual behavior" above

More info:

  • workflow_access is working fine. Anonymous users cannot access content that is restricted to members.
  • This happens on two different servers running the same codebase but different versions of php, mysql, etc (same major versions, different minors)
  • Other permissions seem to be working fine, including OG-based permissions.
  • The settings show properly on the admin/build/workflow/edit/wid page:

    The role anonymous user may do these transitions:
    From To
    (creation) → State 1

    The role authenticated user may do these transitions:
    From To
    (creation) → State 3
    (creation) → State 4
    (creation) → State 5

I'm not sure I see where to go from here. Any help would be greatly appreciated.

CommentFileSizeAuthor
#2 workflow_correct_anonymous_rights.patch703 bytespieterdc

Comments

p_alexander’s picture

p_alexander commented
Status: Active » Fixed

This actually ended up being an incorrect response when workflow_node_current_state was processed. Let me try to describe the behavior. Here's the corresponding code:

 function workflow_node_current_state($node) {
  $sid = db_result(db_query('SELECT sid FROM {workflow_node} WHERE nid = %d', $node->nid));

  if (!$sid) {
    $wid = workflow_get_workflow_for_type($node->type);
    $sid = _workflow_creation_state($wid);
  }
  return $sid;
}

This problem was showing on the node/add/contenttype screen, and so there isn't a node id. However, somehow there was an entry in the workflow_node table as follows:

nid = 0
sid = 10
uid = 98
stamp = 0

Since MySQL treats the numeric value of an empty string as zero, I think it was getting this entry from the table as a result of the select and then we get the current state as 10 rather than null. So when the "if (!$sid)" was hit, it didn't process ($sid wasn't null). I have no clue how an entry into workflow_nodes with an nid of zero was made, but there it is. There is no corresponding node zero in the node table. Deleting the entry from workflow_node corrected the problem.

Since the error was due to a record and a nearly-impossible situation, I'm not sure whether to submit this as a bug. I'm thinking you could add an additional condition to the SQL query:
AND nid != \'\'
This would prevent an empty string from returning anything.

As a final note, this still doesn't really explain why anonymous users had access to transitions that were explicitly denied them. I'm guessing there was an error somewhere because anonymous isn't allowed to set to or from sid 10, and so we got wonky results due to that. Not sure what should happen when roles end up editing/creating a node they don't have workflow/transition permissions for, but getting the transitions from another role seems like an odd result.

pieterdc’s picture

pieterdc
Primary language Dutch
Location Ghent
commented
StatusFileSize
new workflow_correct_anonymous_rights.patch703 bytes

I had roughly the same problem, being: anonymous users having to much rights.

Your solution wasn't the solution for me. So I had to search for another solution.
Removing || ($t->tid == $t->state_id) from function workflow_allowable_transitions( did the trick.
And while I was on it, I did a little code-cleanup in that function.

I honestly don't understand why $t->tid == $t->state_id makes a 'transition' appropriate?
As if if transition id and state id are equal, than anyone has the rights to execute this transition. An easter egg? :)

Or maybe I just don't fully understand the module.

If anyone knows more about this, please don't hesitate to inform me/us.

jvandyk’s picture

jvandyk commented

PieterDC, I think you might be using an older version of workflow; the code you cite was fixed here.

pieterdc’s picture

pieterdc
Primary language Dutch
Location Ghent
commented

Thanks jvandyk for hinting.
My fault, I am using version 5.x-1.2, while this (original) support request concerns 5.x-2.2

Apparently, 5.x-1.x is not supported any more, so I won't submit this patch in another thread and I will upgrade to 5.x-2.x

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.