Closed (fixed)
Project:
FeedAPI
Version:
6.x-1.x-dev
Component:
Code (general)
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
5 May 2008 at 22:01 UTC
Updated:
3 Jul 2009 at 15:50 UTC
Jump to comment: Most recent file
I have a site that is using FeedAPI, FeedAPI Node and the Common Syndication Parser to pull RSS feed items in as nodes.
We want to moderate the actual publication of those nodes, so we're also using Actions & Workflow -- when items are first aggregated, they're supposed to go from (creation) to the "Unpublished" Workflow state. Then an editor goes into the items we want, switches it to the "Published" Workflow state, and that change allows them to show up in the View that serves as the main page for this "metablog."
Everything works great when I go to /admin/content/feed and manually refresh a feed to check for new items.
When it updates via cron, however, it seems as though items never get kicked into the actions/workflow process at all. Nodes are created, and the workflow tab is there, but it shows a "Current state: (creation)," and doesn't even offer the option of changing the state to "Unpublished" or "Published." It's as though the cron-generated nodes are created differently that those produced by refreshing a feed manually.
Here are the versions of the various relevant Modules we have active and in use right now:
FeedAPI 5.x-1.0
FeedAPI Node 5.x-1.0
Common syndication parser 5.x-1.0
FeedAPI Inherit 5.x-1.0
FeedAPI Node Views 5.x-1.0
Actions 5.x-1.x-dev
Workflow 5.x-1.0
I'm more than happy to upgrade to 5.x-2.0 for all the FeedAPI stuff -- just saw that it was available. But I wanted to log this before ditching 5.x-1.0, in case it was helpful "leave the evidence in place."
Any ideas? Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 255059_cron_impersonating_feed_author.patch | 1.9 KB | aron novak |
| #4 | feedapi_1_0_run_cron_feed_owners.patch | 1.92 KB | aron novak |
| #4 | feedapi_1_x_dev_run_cron_feed_owners.patch | 1.92 KB | aron novak |
Comments
Comment #1
TKS commentedOne additional piece of info -- it appears the problem may be due to the fact that when cron runs, it doesn't have the adequate permissions.
When I hit cron.php while logged in as User 1, new aggregated items feed into the workflow just as they should. When I log out of the site and hit cron.php manually, they feed in with the problem I described above.
Thanks in advance... to the Actions/Workflow issue queue instead of here (or in addition to), please let me know.
TKS
Comment #2
TKS commentedJust editing the title to be a bit more accurate...
Comment #3
aron novakI installed Actions 5.x-1.x-dev and Workflow 5.x-1.0 modules. I used the latest CVS version of FeedAPI, but the FeedAPI 1.0 uses exactly the same node creating mechanism. I created a workflow with two states. I created a user who has permission only to create a feed node. I logged in with this user and created a new feed.
The cron was executed anonymously.
I went to the newly created nodes and I found out that i can change the state at the workflow tab.
So in short: i could not reproduce the problem yet.
What I need to know in addition:
I'm not familiar with Actions and Workflow modules, so please describe here how to setup that "when items are first aggregated, they're supposed to go from (creation) to the "Unpublished" Workflow state" . Also please share here the workflow transition permissions.
Comment #4
aron novakWell, I could reproduce the problem now. I see that by default the node should be set to the first state of the workflow.
The patch does the following:
- only at cron run, it changes the current user to the feed owner user ID.
I have not committed yet because it's not sure this is generally a good idea but it definitely fixes the problem what you've faced.
Comment #5
TKS commentedThanks Aron! I'll throw this on our devsite and see how it works. (And if it creates any unanticipated wrinkles that I can see...)
Will update here later today.
TKS
Comment #6
TKS commentedSorry for the slow follow-up on this. Cron was hanging on our site for some reason (unrelated to the patch), so we had to sort that out before I could see for sure that this was working. Everything seems to be running smoothly, though -- thanks again!
As to whether changing the user in cron is "the Drupal way" to deal with this... I don't know enough about core to say. I DO remember a thread last year about other problems with cron running as Anonymous -- it was related to search-indexing, I think -- but I don't recall how it was resolved, and can't find it now on Drupal.org.
So I'm changing the status to Patch (code needs review). It works fine for me, but it'd be great to have it tested more broadly.
TKS
Comment #7
sila80 commentedAnd what I need to know in addition?
Comment #8
alexkessler commentedI had similar problems getting feedapi and cron run together with ekes feedapi workflow module http://drupal.org/node/248912. I could aggregate feed items but they never get published via cron. This patch fixed it for me. Thanx Aron!
Comment #9
aron novakWell, the problem: generally it's not a good idea to create the feed items in the name of the feed owner username.
I'm glad that this is helpful for some of you, but i do not plan to commit this into FeedAPI yet.
Comment #10
TKS commentedAron:
Thanks for the followup. You wrote that "generally it's not a good idea to create the feed items in the name of the feed owner username." What would be preferred approach? I think I'm missing something...
Thanks,
TKS
Comment #11
jrabeemer commentedMake the feed owner a non-admin user with a role who can create the feed item node ex: Editors. You don't want to give away your admin (user 1).
Comment #12
chrisschaub commentedI'm not sure if this will help, but you could use the securesite module to secure access to /cron.php to any authenticated user. Then, just run cron using a url like
http://user:pass@www.example.com/cron.php-- change to your domain. The user you specify should have access to do the node operations required. I haven't tested this, but it should work. I don't think there are any issues with running cron as an authenticated user vs anon.Comment #13
adub commented[deleted] see http://drupal.org/node/247194
Comment #14
adub commentedComment #15
alex_b commentedThe patch in #4 actually poses a severe security risk.
If a malicious user hits Drupal cron, Drupal cron expires and FeedAPI dies after a feed user has been loaded and before the user has been switched back to the previous user, the malicious user is logged in as the feed user.
People who maintain a site with this patch applied should immediately undo it.
The right way to impersonate users is outlined here: #218104: Safely Impersonating Another User .
Comment #16
alex_b commentedThere are 2 issues that are at least related, if not duplicates: #419588: Feedapi not refreshing feed via anonymous cron but works with cron by authed user and #350788: Feeds not refreshing on cron
Comment #17
aron novakThis patch follows the safe impersonating way.
Comment #18
aron novakFixed for 6.x