Posted by rmiddle on January 25, 2008 at 5:14pm
| Project: | Drupal core |
| Version: | 5.x-dev |
| Component: | blogapi.module |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
I have been tiring different off line blogging software with my drupal site. I was using the flock software and there is a line there called Blog ID and it had blog in it I didn't realize what that was attached to so I thought it was a description field for the software. I post my test and it uploads fine then I go to edit it but I can't. The Blog ID field = Content Type so I now have a field with no id type. Inside the DB I saw my description and realized my mistake but there was no way to edit or remove the post without hacking my DB. The Blog API should confirm that to content type both exists and is usable. It should have failed not posted content that is not deletable by anything other then DB hacking.
Thanks
Robert
Comments
#1
#2
deleted
#3
Ops spoke to soon. I went in changed the blog id again and blog type went away and create screwed up entry again. Here is the error when I try and edit it.
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'changeblogtype_node_form' was given in /var/www/html/drupal6/includes/form.inc on line 357.
Since I confirmed this existing in D6 as well I am going to bump this up to 6.
Thanks
Robert
#4
ok, here's the faulty function: http://api.drupal.org/api/function/_blogapi_blogid/6
UNTESTED patch attached.
#5
Is there anyway this can get back ported to 5. It is a problem in 5 as well? So that 5.8 will include a fix as well?
#6
rmiddle - sure backport will be easy, but needs to get fixed in 6.x/HEAD first.
can you test this on 6.x? if not, the 5.x patch should be exactly the same (the patch above applies with 7 lines offset).
#7
pwolanin: the patch does not look good. blogapi has its own setting on the allowed node types. Use _blogapi_get_node_types() to get a list of types allowed with proper permission for the user to create. Otherwise your solution looks right.
#8
Sounds simple enough.
#9
Arancaytar: well, I would upload a patch if it would be that simple :) Unfortunately _blogapi_get_node_types() does not return an array keyed by node type name, so you cannot just check for an item there like this. Either _blogapi_get_node_types() needs to be aligned, or a foreach/while needs to be done in the patch or code from _blogapi_get_node_types() can be copied out and used (unfortunately most of the function would need to be duplicated, so this does not attractive).
#10
#11
Sorry for the bone-headedness. :)
I'll take an actual look at the API now...
#12
Modifying _blogapi_get_node_types to use array keys ($types[$type] = $type) sounds a bit cleaner than a search loop. Is there a Drupal tradition in one way or the other for situations like these?
#13
how about something like this?
#14
pwolanin: Now looks good. Let's get some testing done and we can fix this.
#15
I can't test, unfortunately. My Drupal 6 site inexplicably dies whenever I try to submit admin/settings/blogapi. Premature end of CGI script headers. The other forms on the site work, which kind of stumps me.
#16
After applying the form fix, and this patch, I was able to submit "Story" articles from Windows Live Writer through the Blog API XML-RPC (MovableType). This is without the Blog module enabled. Very nicely done, pwolanin.
#17
oh wait - it's possible to do this without Blog module available? in that case do you want the 'blog' type as the default?
#18
In re: #16
It is already possible to submit articles to Story node through XMLRPC blogging software. The Blog API XMLRPC isn't just for Blog nodes. This is in Drupal 5.
#19
Rob Loach: the purpose of the patch is not to allow you to submit story nodes, but to not allow you to submit node types which were not specifically set up on the blog API admin interface. Please test for that.
#20
Tested this way:
1) Installed RC3, patched and enabled Blog API module
2) Connected via BloGTK
3) Available "blogs" (content types) in BloGTK: blog
4) Went to admin -> settings -> blogapi and enabled page and story
5) Reconnected via BloGTK
6) Available "blogs" in BloGTK: blog, story, page
Works for me, BUT: Is blog content type available as default? I can't do this again, because, "enable for external blogging clients" is a required field. but it was empty after installation...
#21
Oh, after discussion with Gabor, I tested this patch correctly. I used Flock for this, permitted "poll" and "page" content types.
- Set blog id to forum -> saved as "blog" content type
- Set blog id to page -> saved as "page" content type
#22
So meba validated that the patch does what it sets out to do. For whatever invalid types, it returns the blog type. We could simplify the code a bit by removing the is_numeric() check, to have one single place to select a type. However, since this does not guarantee that the user has access to the blog type it still does allow to save blog type nodes without permission to post blog type nodes. (The default blog type node is selected even if all permission checks fail).
So basically, we should just do a blogapi_error() if the node type is not allowed, return the message and return from the caller if blogapi_blogid() returned non-TRUE IMHO. That should give proper indication to the client in what is bogus.
Please test this.
#23
Tested with three clients:
1) Flock - you can't post any node type now, but Flock is buggy in returning an error "Blog API module is not configured to support content type"..., just returns null. When tested with allowed node type, everything is OK.
2) Drivel - buggy at all. Requests xmlrpc.php as anonymous, then as logged in user. This means that "Blog API module is not configured to support content type" is returned two times for it (No allowed types for anonymous user).
3) BloGTK - seems OK, in addition, doesn't allow different Blog ID's.
#24
Thanks for testing. On your suggestion, I also added the type name itself escaped to the error message. Also took the liberty to rename the validation function since its internals changed dramatically anyway. No other changes. Committed this one to 6.x Also RTBC against 7.x.
It would be great if someone could do a deep review of this module in 7.x and clean it up. This code is very old and was rarely touched.
#25
Where does the name 'blogid' come from? Does that come from the official specification? If not, why not call it '$type' (short for 'content type')?
#26
Does this need to be backported to 5.x also?
#27
Dries: Yes, the blogid name is used in both Bloggger API (eg. http://www.blogger.com/developers/api/1_docs/xmlrpc_newPost.html) and MetaWeblog API (http://www.xmlrpc.com/metaWeblogApi) the two most important protocols we support. Drupal maps the blogid to content types.
pwolanin: yes, probably.
#28
Pwolanin,
Yes it is an issue in 5.x that is where I found the issue by mistake I didn't understand what blogid was and changed it. Causing posts that couldn't be edited or changed. I then tested in 6.x to see if it was a continuing issue and it is.
all,
I think this is a security issue since you can bypass roles management so this should be fixed.
Thanks
Robert
#29
rmiddle: No, it is not a security issue. BlogAPI checks permissions for node types, so you can only create specific types of nodes before the fix, if you have permissions to do so (eg. forum type is not set up for blogapi, but you have permission to post forum topics). If you are user #1, then you can create arbitrary types of nodes (even nonexistent), because the node type permission check returns TRUE. The patch checks for types set up for BlogAPI first, so that only if you have permission and the type is existent and set up for blogAPI, you can post that type.
#30
Thanks for the clarifications. Committed to CVS HEAD.
#31
5.x backport?
#32
Automatically closed -- issue fixed for two weeks with no activity.
#33
#34
#35
If anyone should wonder as I did: Yes, this was committed to D6 as well and didn't just go from 7.x to 5.x. :)
Also, attached is a (not tested) port. I'm a bit wary of completely replacing a function (
_blogapi_blogidwith_blogapi_validate_blogid) though. But I guess that's for Drumm'n'Dries to decide whether that's okay. They're both _private functions, and I don't think anything in contribland uses BlogAPI functions at all...#36
Renaming and changing arguments in _-prefixed functions is fine, especially since it was done in 6.x, which is just as stable as 5.x.
This definitely needs testing.
#37
My blogging software confirm the node type of a user/password before the publishing (test).
I choose "Username:blog" or "Username:page" because I configure the APIs blog module available for these two types of content.
But in the process of publication the Blogapi module returns the error "Blog API module is not configured to support the content type, or you don't have sufficient permissions to post this type of content"
I don't understand the mistake. I play with my admin profil which has all the permissions and the blog api is configured to post on blog or page.
Some understand this issue.
Thanks very much for your help
#38
@jojo75000 open a new support issue for your question
#39
A fix for this issue was committed to 6.x and 7.x. The only reason this is still open is for a backport to 5.x.
Since 5.x is no longer supported, I think it's appropriate now to mark this as "won't fix".