Allow simplenews cron to send nodes that anonymous users cannot access

The problem is here:

Since cron runs as an anonymous user, the above sql statement will never allow it to send nodes that anonymous users cannot access.

I believe this limits Simplenews unnecessarily. It is possible that users will want to restrict a newsletter to a private group, but by definition any newsletter sent by cron must be public.

Seems like we could remove the problem by getting rid of the db_rewrite_sql part of the statement. I don't see any reason why we would want to add any access control queries to this one. Or, am I missing something here?

I did look at the 'send newsletter' permission, but I don't believe it as any effect here as there doesn't appear to be any node_grants given as a result of this permission.

The cause of the problem is, as you mention, the access restriction to the node. This is not solved by only leaving out the db_rewrite_sql here.
I found a solution in the mailhandler module. It switches the user when collecting data with restricted access. When simplenews sends emails we need to switch to the author user, load the node and switch the user back. But, this requires some caution not to create any security holes.

Please try the attached patch to see if it fixes the problem.

Attachment	Size
simplenews.256795.patch	3.16 KB

This patch fixed the problem for me. Will this be rolled into a future release?

I consider it. Please explain how you have restricted the access to the newsletter. I still need to understand the problem, before I decide for this solution. And I want more people to test this patch.

Ah ok I guess someone should have explained this. :) I don't know the situation for others, but for us newsletter access is being restricted using the Nodeaccess module.

For example, in Access Control the simplenews module is set for *no* anonymous users to have access to newsletters, then we use Nodeaccess to control who can receive certain types of Newsletters (using the Simplenews Template module to create templates for registered, paid, etc.).

Updating to the version we are using.

This is the kind of situation where the patch is intended for.
1. try so send using cron and see if the nodes appear in the email.
2. if the nodes do not get through, try the #3 patch and pls report the results.

I'm sorry, I thought my comment in #4 answered it? The patch in #3 worked for us. That's why I was asking if it would be rolled into a future release.

I like to see more test-result before rolling the patch.

My problem is when using simplenews with relatedcontent and taxonomyaccess.
I have some nodes with restricted access using taxonomy; when I send test all the nodes get inserted in the newsletter, but when they are send using cron, the restricted ones aren't included in the newsletter.

I think it is a great idea to save the user, switch to another user, and then restore the initial user; but I would rather switch to the uid=1 user than the author of the node.

@enboig: please test the #3 patch. I want to see more test before this gets in. And, please explain why you want to switch to user/1? I assumed that the node author has full access to the node.

Well, it should work with the node author; but I think its simplier to use always the user 1 than look always for the node author.

I will test the patch now.

after applying the patch I recive this error:

Following #1 I changed:

to

And now It appear to work. Does this modification has security issues?

The patch does exactly change this code (and more) perhaps you had errors during patching. It is very likely that the patch does not apply cleanly anymore.

I applied manually the patch, the version of simplenews I am using is a little different of this one; what I don't understand is why cron.php fails when calling a function ("session_save_session") that is in api.drupal.org (version 5).

doesn't cron.php do a full bootstrap?

The attached patch is the D6 version of the same functionality.
(it does not address the #14 error)

Attachment	Size
simplenews.d6_256795.patch	5.23 KB

Any updates in this issue? I am using Drupal5 and I couldn't apply the patch provided.

Thanks

Are the patches applied to the dev version so I could test them?

no, patches are not committed.
How to patch: http://drupal.org/patch/apply

I could apply the patch "manually". My problem was because old versions of Drupal5 session_save_session(); updated the whole site and now it works ok.

Thanks.

Change version to HEAD, new functionality will now only be added to HEAD.
Patch requires minor rework.

Patch reworked for HEAD.
Changes:
- changed comment
- select element changed to radios

Attachment	Size
simplenews.256795_1.patch	15.56 KB

oops, mixed up with other patch.

Attachment	Size
simplenews.256795_2.patch	4.34 KB

I was thinking that maybe the user which should be used to create the mail should be the "receiver" and not the creator of the newsletter.
In my association I have multiple users with different role and access to different content using "Taxonomy access". The way mails are generated now I understand some users could get a mail where they cannot click on "Read more" to read the full article.

Tried the patch on the latest rc, where it applies with fuzz.

When cron runs, I get this:

I suspect this is because the newsletter is made by uid 1 and I've not bothered to give the superuser any roles.

I'm not sure about the use of the 'cron user' setting -- why woud you want to send as the cron anonymous user? It just adds a complication because the way the newsletter is send is different depending on whether cron is being used or not.

Also -- how do I reproduce this anyway?
Does running cron with devel module run it as superuser? In which case that's no good for testing.
I've reversed the patch and emails are getting through, running cron on the command line with curl. Totally confused now!!!

While the function simplenews_switch_user in the patches above is declared as
function simplenews_switch_user($uid = NULL) {
it is called from simplenews_mail_mail for the user switch with
simplenews_switch_user($node->nid, $node->vid);

This will obviously not work. The single parameter should be $uid.

In addition, I support #26. This would open up the publication of a "public" and a "internal" version of the same newsletter, where one user sees some nodes, and the other not. Also, if someone who has received a newsletter with one role and now gets another role or additional rights, he could get the same newsletter in another version without having to unsubribe from the old and subscribing to a new series. (Think of a chronological list of events with public and internal events intermixed)

This patch is re-rolled for the current HEAD and has the error found by ccprog corrected.

Attachment	Size
simplenews.256795_3.patch	4.32 KB

Patch reworked for the current DRUPAL-6--1 branch.

Attachment	Size
simplenews.d6_256795_2.patch	4.84 KB

The simplenews.d6_256795_2.patch had the same issue pointed out by ccprog. I am attaching a modified version with this issue fixed.

Attachment	Size
simplenews.d6_256795_3.patch	4.83 KB

I'm having the same issue. I've applied the patch in #31, and tried setting the cron user to be the newsletter author, but at cron time it doesn't send, it's still permanently pending. When I run cron manually, it sends immediately, although it's sending it twice. Does the patch work for others - am I missing something in set up?

All my content, and therefore the newsletter, is private.

The current 6.x-1.x-dev branch has simplenews.module revision 1.76.2.136, but the patch applies correctly only on 1.76.2.134. With the latest branch I got the same error as you.

I'm actually using the latest stable release 6.x-1.0-rc6 rather than dev. This has simplenews.module revision 1.76.2.129. Is it worth updating to dev if it's still not solved the cron issue?

@Kweeks, sgabe: Try testing without Mime mail or other mail back-end like SMTP. Try debugging the code to see why the emails are not sent by cron.

Attachment	Size
simplenews.d6_256795_4.patch	4.92 KB

Thanks for the revised patch Sutharsan.

I'm just using plain not MIME emails. My limited cron debugging skills seem to show:

• module_invoke_all in includes/module.inc shows that simplenews_cron is being called at the 10 minute cron run
• But the watchdog I put in simplenews_cron itself is not being called (which makes no sense to me?!)
• Running cron.php manually calls the watchdog I put in simplenews_cron though, and the emails are sent

So it seems to me that the cron run is not calling hook_cron properly but the manual cron is. I can't see how that can be the case?!

Make sure you logout before callin cron.php manually; to ensure it is not a permission problem.

I've managed to solve my problem now and the patch works great, thanks Sutharsan.

@enboig, thanks for that reminder, I hadn't tried that. It worked even when logged out so wasn't a permission problem at least not that side.

I eventually tracked it down to my crontab - it was in root's crontab and needed to be in apache's to run properly. So actually cron on the site had not been running at all for any hook_crons, and it was only simplenews that alerted me to the fact. (the emails being sent twice was a silly oversight on my part - two test subscribers with the same address :-))

@Kweeks: Thanks very much for reporting the cause of your problem! (believe it or not, but not many people report back once their problem is fixed.) Can you explain a bit more on "it was in root's crontab and needed to be in apache's to run properly." Was cron triggered by user 'root' instead of user 'apache'? How did you notice and how did you solve? Perhaps you want to add a description to the (simplenews) handbook.

It's exactly as you said. The cron was in the crontab of the Linux root user, when it needed to be in the crontab for the user 'apache' in order to run with the way our web servers are set up.

I added a watchdog into module_invoke_all in includes/module.inc to see what hook_crons were being called at cron time (a very useful tip from a DrupalCon Paris session, Debugging Drupal).

From that I could see that no cron functions were being called on the scheduled run, only when I ran it manually - meaning there's probably something wrong with the crontab. I hadn't even realised it wasn't running properly. Also because the emails sent manually (because that was the user 'apache' calling it) it wasn't a problem with cron just crashing on some module.

The cron log files (usually in /var/log/cron) show who's running the cron tab - it was root so I changed the crontabs and it worked.

Good idea I'll add something to the handbook - it might help someone else debug their cron problems even if it's not the same issue.