Posted by petrelharp on September 8, 2009 at 10:24pm
| Project: | Path Filter |
| Version: | 6.x-2.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
If you use FCKeditor with the "HTML filter" turned on as a security filter in Administer > FCKeditor Settings > (edit profile), then the internal: gets stripped out of the links, hiding them from pathfilter.
Steps to reproduce:
- Enable FCKeditor, and edit the profile that you use so that "HTML Filter" is enabled as a security filter. (under e.g.
/admin/settings/fckeditor/edit/Default - Edit a new page and add internal links using
internal:. Add some links that would break if interpreted as internal links by the browser. - Save the page. At this point the links will not be broken.
- Edit the page again, and save it. (it is not necessary to change anything)
- The links will be now relative links (and probably broken)
- Turn off "HTML Filter", add the
internal:to the links again, and verify that they are no longer deleted as before.
Since FCKeditor renders the HTML it is editing, it allows admins to set "security filters" to pass the HTML through. Unlike the filters usually in Drupal, this permanently changes the text being saved.
This should at least be mentioned in the pathfilter documentation.
Comments
#1
The
internal:gets stripped out byfilter_xss_bad_protocol(). The set of allowed protocols can be extended on line 1182 ofmodules/filter/filter.module:$allowed_protocols = array_flip(variable_get('filter_allowed_protocols', array('http', 'https', 'ftp', 'news', 'nntp', 'telnet', 'mailto', 'irc', 'ssh', 'sftp', 'webcal', 'rtsp')));
However, I'm not familiar enough with Drupal to know the right way to change this.
#2
I can confirm this same problem. Adding "internal" to the list of allowed protocols above fixes the issue.
Maybe we need a hook_allowed_xss_allowed_protocols() or something for modules to implement, that could return additional allowed protocols? Then e.g., path filter would return "internal:" as an additional allowed protocol.
Thanks to author above for rooting this one out, too!
#3
no need to hack core! adding internal and files to the filter_allowed_protocols variable should be enough.
something like this:
$allowed_protocols = variable_get('filter_allowed_protocols', array('http', 'https', 'ftp', 'news', 'nntp', 'telnet', 'mailto', 'irc', 'ssh', 'sftp', 'webcal', 'rtsp'));
$allowed_protocols = array_merge($allowed_protocols, array('internal', 'files'))
variable_set('filter_allowed_protocols', $allowed_protocols)
#4
patch is for D5, but it should work exactly the same in D6 versions etc. (verify default filter configuration please, later versions of drupal might have added additional allowed protocols)
also, i took a shortcut during uninstallation - please review!
#5
(this might help ;) )
#6
#7
Did you notice this in the README.txt:
Did you follow that advice?
#8
the problem here is that FCKeditor renders the HTML it's editing, changing the actual html while going trough filter_xss_bad_protocol() again.
pathfilter is not listed as a security filter on admin/settings/fckeditor/edit/Default (which is good, because we don't want it to run there.) however, a side effect of this is that the html filter runs again on the content we're editing changing the actual source of the page
the 2.x version of pathfilter has fixed this issue on another way already, by not exposing the internal: and files: to the editor.
#9
@alexanderpas: good to hear that this is no longer an issue in the 2.x branch. Can someone else confirm the fix? I don't have FCKEditor installed.
Marked #307212: not working directly with FCKEditor as a duplicate.
#10
Sorry, couldn't confirm alexanderpas's patch, since I'm running Drupal 6, and it doesn't apply to pathfilter 1.0 in Drupal 6. It looks correct...
I did just upgrade to the 6.x-2.0-beta3 version of pathfilter. It appears to no longer have the same problem, but rather, a different one. If as described above, I create a page with an internal link (with protocol to, say, "internal:node/24"), save the page, then open it to edit it again, I find that the link is no longer saved as "internal:node/24" but has been changed to "http://mysite.org/node/24". This still works, of course, but unless there's something behind the scenes going on, is not robust, and conflicts with what the README says should happen:
"The motivation for this filter was to provide a robust way of linking to
internal URLs from within content, so that your links do not break if you
move your site to a different path (e.g. from a development site at
http://example.com/dev/ to a production site at http://example.com/)."
Perhaps I'm missing something?
#11
One of the new features of 6.x-2.x and 5.x-2.x is the ability 'auto internalise'. What this means is that you no longer have to type internal: - pathfilter does it for you. It actually works both ways, and what you are experiencing is the other side of this... When you create the link 'internal:node2', that is exactly how it is saved in the database. However, when you edit the node again, 'internal:node/2' is converted to it's real link 'http://www.example.con/node/2', and when you save again, it is once again converted and saved in it's internal: form. Where this really helps is for referencing files using files: as it will, for example, convert the link files:images/image.jpg' to http://www.example.com/sites/example.com/files/images/image.jpg' when you edit the node, allowing WYSIWYG editors to work with the image. When you save the node again, the link will be internalised once again back to it's files: format.
Rest assured, your links are still saved with the internal: prefix, and the robustness that this module went about to provide is still intact.
You can turn this behaviour off in the configuration page for the filter.
If you want to read more about the change, and the motivation behind it see #148300: [Push #1]: Automatic url conversion to internal links
#12
Ah, great. In this case, I'll confirm that this is not an issue in the 2.x branch.
thanks muchly!
#13
if that's the case, this issue is actually also in the 2.x branch, but only when the automatic behaviour is disabled.
#14
The patch at #4 has been committed to the D5.2 and D6.2 branches in CVS.
http://drupal.org/cvs?commit=294964
http://drupal.org/cvs?commit=294962
Thanks @alexanderpas:
#15
Automatically closed -- issue fixed for 2 weeks with no activity.
#16
This still seem to be an issue for CKEditor (the successor the FCKEditor). However, a straightforward workaround should be to disable "HTML filter" as a security filter for CKEditor and enable it in the relevant input formats instead.