l function let's the user to add some attributes to the link.

The patch improves link_node to handle attributes as function l does.

CommentFileSizeAuthor
#11 link_node_attributes_1.patch2.79 KBjherencia
#5 link_node_attributes.patch2.73 KBjherencia
link_node_attributes.patch2.72 KBjherencia

Comments

TomChiverton’s picture

TomChiverton commented

Thanks for this.
Is it backwardly compatible ? So both syntaxes will work ? What exactly is the new syntax, and how does it differ from link_node's ability to already override things like 'title' ?

Also, you'll need to patch the documentation as well as the code.

jherencia’s picture

jherencia commented

The syntax remains the same so there is no need to update the documentation.

It is a different way to handle the input. With this fix you can set html attributes: class, style, etc using the current syntax.

TomChiverton’s picture

TomChiverton commented

Do you have some examples of how this would work in practice ? What the new raw text would be ?

jherencia’s picture

jherencia commented

[node:1, title="new title", class="class1 class2", style="border-left:1px solid red;"]

jherencia’s picture

jherencia commented
StatusFileSize
new link_node_attributes.patch2.73 KB

I've added the possibility to set html titles: like 

title="H & M" ("H &amp; M) or even title="<span class="blue">ABC</span>".
pluess’s picture

pluess commented

Thanks for the patch.

I had a look at the code which looks fine. Unfortunately I did not get it to work. I tried your example from #4, but the style property did not show up in the final markup. I debugged link_node_filter_link_node_process() which works as expected, but it seams that the attributes do get lost further down the road.

About the second patch: This opens a XXS vulnerability to untrusted users having the right to use the link_node filter. Since setting html=TRUE for the l function just passes on what the users enters. If this is not nice JavaScript code we will have a problem.
I'd say we don't integrate this. If we do we should protect this with a special access right which should only be given to trusted users as it's done for the PHP filter.

pluess’s picture

pluess commented
Status: Needs review » Needs work
TomChiverton’s picture

TomChiverton commented

Do we need to worry about the XSS ? I mean, if the user can create content, they can already right the XSS...

jherencia’s picture

jherencia commented

Maybe we can add some permission to do that.

pluess’s picture

pluess commented

I'd say yes. Think about drupal.org. We can create content, but everything we create is escaped.

It would be fine for me, if there's a permission which must be given to trusted users.

jherencia’s picture

jherencia commented
StatusFileSize
new link_node_attributes_1.patch2.79 KB

I think that we can filter just allowing the reasonable options:

  • span
  • strong
  • img
  • em

I haven't tested it but I think it may work.

TomChiverton’s picture

TomChiverton commented
Status: Needs work » Needs review

Img isn't safe (javascript: URLs spring to mind). Why don't we only allow HTML if the full-HTML input mode is being used ?

jherencia’s picture

jherencia commented

filter_xss checks that no javascript is inserted. Does it not?