Mailto subject parameters
emdalton - June 22, 2007 - 19:40
| Project: | SpamSpan filter |
| Version: | 6.x-1.4 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
Here's yet another format those crazy users want supported:
<a href="mailto:wsbe.alumni@unh.edu?subject=Class%20Notes">Submit a class note</a>
This sets the subject line when the mail application is launched with a new message. While I can certainly appreciate that this starts to push the boundaries of what this relatively simple module was originally intended to do, what can I say -- it's a feature of mailto links, my users keep pasting them in from other websites, and so then we see ugly text like this:
user@domain.edu?subject=Class%20Notes instead of a nice link.
#1
Hello
+1 for this feature request!
We could need this functionality too - on Drupal 6 site
#2
+1 for this. Currently, mailto links with subject parameter break the filter. I'm bumping the version to 6.x since that's what I'm using, and I don't think you are supposed to have two different issues (one for each version).
#3
What do you mean by "mailto links with subject parameter break the filter"? Are you using the most recent release? It shouldn't break with subject parameters, though it will ignore them.
#4
I mean that if you have a ?subject parameter in the mailto link the code has an extra span tag that is part of the visible text and the link is broken. I am using the latest version. Note that I am also using the HTML Purifier filter, so it might be an interaction between the two.
#5
Evan,
Please can you post (wrapping in
tags as necessary) precisely what html code is output by the spamspan module on your setup, and I'll look into it. If possible, please could you also try with HTML purifier disabled, and tell me what happens then.#6
Ok, thanks, I'll try to do this soon. Have a lot of other things to do at work right now :)
#7
+1 for this request, and I'm having a similar issue to EvanDonovan.
HTML in:
<a href="mailto:this.person@example.com?subject=test%20subject">Email link</a>HTML out:
<a href="mailto:<span class="spamspan"><span class="u">this [dot] person</span><img alt="at" width="10" src="/sites/default/modules/spamspan/image.gif" /><span class="d">example [dot] com</span></span>?subject=test%20subject">Email link</a>Filters being used:
SpamSpan, URL Filter
Should I try a different combination of filters to see if it gives a similar result?
#8
Having similar issues as well with ?subject=
Would be nice to have some more support for the options you have with mailto:
?subject=SpamSpan&body=Please%20support%20more%features&cc=info@mydomain.comCheers
#9
I am having a similar issue as well:
HTML in:
<a href="mailto:fcmit@arizona.edu?subject=Website%20Feedback">fcmit@arizona.edu</a>HTML out:
<span class="u">fcmit</span><img alt="at" width="10" src="/sites/all/modules/spamspan/image.gif" /><span class="d">arizona [dot] edu</span>?subject=Website%20Feedback"><span class="spamspan"><span class="u">fcmit</span><img alt="at" width="10" src="/sites/all/modules/spamspan/image.gif" /><span class="d">arizona [dot] edu</span></span></a>Filters used and order:
Hide email addresses
URL filter
HTML filter
HTML corrector
GMap macro expander
Thanks!
#10
As mailto parameters are a standard and also easy to implement with WYSIWYG editors like FCK editor I'm changing this to critical...
This is my markup from node/edit
<p><strong>Per email:</strong><br /><a href="mailto:mail@domain.com?subject=subjectline&body=bodytext">mail@domain.com</a><br />
</p>
I've only enabled the 'Hide email addresses' filter for the content-type.
This is the source markup that's outputted;
<p><strong>Per email:</strong><br /><a href="mailto:<span class="spamspan"><span class="u">mail</span><img alt="at" width="10" src="/sites/all/modules/spamspan/image.gif" /><span class="d">domain [dot] com</span></span>?subject=subjectline&body=bodytext"><span class="spamspan"><span class="u">mail</span><img alt="at" width="10" src="/sites/all/modules/spamspan/image.gif" /><span class="d">domain [dot] com</span></span></a><br />
</p> </div>
Whichs shows itself as
Per email:maildomain [dot] com?subject=subjectline&body=bodytext">mail@domain.com
Hope this helps fixing the bug!
Cheers
#11
This is fixed, in part, by release 1.4 of the module. Mailto: parameters are now silently ignored, and should not break links.
I would appreciate feedback about what markup should be generated from a mailto: link with a subject parameter, and then I'll have a think about how to implement it.
Turning this into a feature request for the time being ...
#12
subscribe
#13
How about
<span class="spamspan"><span class="u">mail</span><img alt="at" width="10" src="/sites/all/modules/spamspan/image.gif" /><span class="d">domain[dot] com</span><span class="s">this%20is%20the%20subject</span><span class="b">this%20is%20the%20body</span></span>And then make the module add CSS to hide classes
.spamspan span.s, .spamspan span.b {display:none;
}
Cheers
#14
Another big +1 for this feature request.
This is a key feature that we would like to utlilize. There are so many occasions when we need to use the subject function for an email link. Any word on this, possibly building off of Bartezz's suggestion?
Thanks so much for the hard work that has gone/is going into this extremely useful module!
-Pete
#15
OK. You asked for it. Please try version 1.5beta. Mailto: URI parameters should now work. Feedback please
#16
Thanks. I'll try this in the next week, I hope.
#17
Thanx mate, will try monday!
Cheers
#18
Hey Lakka,
Not sure what you mean by 'URI parameters should now work'.
My findings are that they now don't result in buggy markup anymore;
<span class="spamspan"><span class="u">info</span><span class="d">mydomain[dot] com</span><span class="h"> (subject: subject, amp, body: bodytext) </span></span>But clicking a link does not utilize the parameters when opening the email window, is this by design?
Also 'Use a graphical replacement for "@"' doesn't work anymore (see code above). It does work with this option disabled.
Cheers
PS. There aren't settings available for the classname of the new span, nothing big but thought I'd mention it.
#19
I meant that they should work! They do for me.
Please can you let me know exactly what the original input is, and precisely what markup is generated by the filter.
The best way might be for you to upload a text attachment, so that the Drupal issue reporting system does not mangle your html.
Do you mean that "subject" shows up in your email program when you don't use a graphical @, but not when you do? Or do you mean that "subject" never shows up, and also that the graphical @ doesn't work?
#20
Hey lakka,
Will post this tomorrow, the exact markup is in the code above!
The graphical markup doesn't work for me at all, and is of no further influence. It's just not being shown (with Javascript turned off).
Subject just never works.
I will try to remove and uninstall and reinistall the module tomorrow and see if that fixes things!
Will post back!
Cheers
#21
Ok, still not working :'(
- Uninstalled and removed module. Downloaded again and reinstalled
- Went to admin/settings/filters and set the Full HTML filter to use the Spamspan filter (Hide email addresses using the SpamSpan technique)
- Went to admin/settings/filters/2/configure and checked 'Use a graphical replacement for "@"'
- Set the weights of the filters as followed;
+ Linebreak-converter -10
+ URL-filter -9
+ HTML-corrector -8
+ Hide email addresses using the SpamSpan technique -7
Created a node with the body set to Full HTML and with the following link in the html markup;
<a href="mailto:info@domain.com?subject=subject">info@domain.com</a>This results in the following output;
<span class="spamspan"><span class="u">info</span><span class="d">domain [dot] com</span><span class="h"> (subject: subject) </span></span>The Javascript generated output is;
<a class="spamspan" href="mailto:info@domain.com">info@domain.com</a>Now I've tried unchecking 'Use a graphical replacement for "@"' and also tried disabling all other filters...
Cleared cache, reasved node each time I changed a setting... nothing!
Using latest D6 release...
Thanx for looking into this!
Cheers
#22
FFS! :)
Should have looked at this earlier.... you've forgotten to update the Javascript file...
The compressed version is the old one... I copied the contents of spamspan.js to spamspan.compressed.js and now it works :)
Attached a good newly compressed version of spamspan.compressed.js
Also the next line just might cause the graphical replacement not to work as img tags are filtered out ;)
$output = filter_xss($output, $allowed_tags = array('em', 'strong', 'cite', 'b', 'i', 'code', 'span'));I've created a patch to fix it and also added this in the patch
$output .= "<span class=\"h\"> (". urldecode(implode(', ', $temp_headers)) .") </span>";I know a mailto link should normally be url encoded, yet with Javascript off (the way Google looks at your code) it isn't a link anyway, it's just a series of . Might as well make these look good ;)
Otherwhise your output (not source code) looks like this (with Javascript turned off)
info [at] domain [dot] com (subject: A%20lot%20of%20spaces%just%20look%20crap%20when%20url%20encoded)Cheers
#23
Thanks Bartezz. I have committed the right js file this time, and fixed the over-enthusiastic xss filter. I have not used your urldecode patch. I think it is likely to open up a security hole.
All comments on 1.5beta2 are welcome.
#24
Hey Lakka,
Thanx for the commit. I would like to see the urldecode patch committed as well tho. It's so ugly to have those %20 and other url encoded stuff on your page or showing up in Google! And I don't see how this can open a security hole when the only thing it does is echoing it to the browser. Maybe we should urldecode and check_plain it... That way it's safe to use and no %20ies will show up... both happy :)
Idea? Then I'll whip up a patch!
Cheers
#25
Nice work, big progress!
On my test page I got the following testcase work properly now:
<a href="mailto:somebody@example.com?subject=Try It">Email w subj</a>However, these two do not work in respect to the subject part (subject part is printed in the text, and URL in the link has no subject):
<p>billgates@microsoft.com?subject=Bite Me!</p><p>mailto:bg@microsoft.com?subject=Bing Cherry</p>
#26
@iva2k: That's because the first example is not a valid mailto: URI in accordance with RFC 2368. 'Subject' and other headers can only be specified in conjunction with a mailto: URI, and not a normal email address.
The second example is a valid mailto: URI, but you cannot just put a mailto: URI on its own into a document. To make a clickable link, you need to use the mailto: URI as the value of an href attribute. That is certainly my reading of the standards.
#27
How about my comment #24 Lakka?
Cheers
#28
@lakka
Thanks for the response, but I think you are missing the point. I gave the text as entered into the body (not using any wysiwyg editors), not SpamSpan's resulting output.
SpamSpan is a filter that takes email text and obfuscates it. My examples are from the node body, which is processed by input filters, including SpamSpan. SpamSpan's output is supposed to be compliant with RFC 2368, not its input, which by the way is handled OK for all 3 examples. The filters allow non-html or non-compliant html to be entered/input into the node, and filters translate/convert/cleanup all input into a valid output HTML.
The first example works as supposed to - SpamSpan formats it in an obfuscated way. So it is check here. It even converts all spaces into %20
The second and third examples are also formatted by SpamSpan, and the results are obfuscated. It is just the "subject" part that is dropped.
>The second example is a valid mailto: URI, but you cannot just put a mailto: URI on its own into a document
Yes I can. The "mailto:URI" is converted to "<a href=URI>..." just fine. And it is one of the reasons I like SpamSpan. It is the case of URI?subject=... that breaks it.
Fortunately, latest changes to handle subject made big improvement in the 2nd & 3rd examples - the resulting links are functional and readable now. They were badly broken before, so it is a huge improvement already. All I point out is that there are some more tweaks needed to make it perfect.
#29
@Bartezz - still thinking! The problem is that the filter is not "just echoing to the browser". With your patch, it is decoding the text first, and then outputting it. Code should never output user input without check_plaining it. So it certainly should not output it having doen exactly the reverse! I can't see how using both urldecode and check_plain would help, but I haven't had a chance to try it yet.