Access control for tokens is based on logged in user, not subscribing user

No, it can't be the logged-in user. Access is evaluated during cron.php, when the notifications are created and sent, and there's no logged-in user at that point.

If you run cron.php manually while being logged in, the result may be different, which would admittedly be a bug, but it's not the normal situation.

How exactly are you using [field_*-formatted] tokens? Subscription's mechanism for accessing fields is !cckvalue1_<fieldname>...

Please try to boil this down to a concrete test case, something like

1. UserA (who has access no access to FieldB) subscribes to content type 'story'.
2. UserB with role RoleB (with access to text field FieldB) creates a 'story' and fills in FieldB

etc.

Avoid using Anonymous (for the test) if possible, because the discussion is clearer if we can refer to specific users. Be sure to check and report how you're running cron.php.

"Immediate sending" is impossible to get right, as you've found out. That's why Subscriptions doesn't have that misfeature...

@akhaef,
I guess you may be right, access for fields is not checked anywhere AFAIK. However I also don't know how it should be checked (where is that access restricted?)

Also @salvis comments on #1 apply to Notifications.

So I wouldn't label it as a critical security issue as access control to nodes is checked and the admin should know which tokens to add to the templates. But anyway this needs some more research.

So, which module adds that 'field permissions' to start with?

So, do that modules apply permissions during node loading?

If so, as we have all these objects statically cached (for all users), I guess the best option would be to load everything as user 1 so we get all fields.

The fields that are displayed are the ones defined by the site admin with tokens, no per-role tokens here. So the best fix we could do for this is some warning message.

Tokens are cached too so I don't think we can do anything here unless we rewrite tokens, which is not an option.

Open questions here:
- Which ones are these modules?
- How do they apply permissions?

Reworking the title a bit and throwing this back in to the Notifications queue, since this isn't specific to the add-ons module. Here's some further information:

CCK tokens are basically generated by doing a node view (see content_token_values() in cck/includes/content.token.inc). Since it's a view operation, they perform their normal access control on the fields, which means that whether you see them or not is based on the current user.

The way most sites are likely to be set up, Notifications will be sent via cron, which will mean that Anonymous will be the user determining whether the fields get rendered for the tokens. So any fields you haven't granted view access to the anonymous role for won't be showing up in the emails being sent out.

On the flip side of that coin, you can potentially expose information you shouldn't if you process the queue via the UI. A user who has access to do this is likely an admin, which means they probably have access to view a bunch more CCK fields than most users. When they process Notifications via the UI, those tokens get rendered because the admin has access, so even though subscriber A can't view those fields on the node, they may get them in a Notification they receive.

Here's a patch that goes with akhaef's idea of masquerading as the user that the notification is being sent to.

Upon further inspection, my patch in #9 doesn't really work like I wanted it to. The token module caches the values per-object, so you really only get the values appropriate for the first subscription's user.