Bug #23984
closedtx_felogin: forgot password-mails links not clickable
100%
Description
E-Mails containing the text "to set a new password please visit the following link:" have a link to the page to reset the password. This link contains unmasked square brackets and is not clickable up to the end.
The solution is used already by tx_srfeuserregister
http://bugs.typo3.org/view.php?id=12892
File pi1/class.tx_felogin_pi1.php
// link
$link = ($isAbsRelPrefix ? '' : $this->conf['linkPrefix']) . $this->pi_getPageLink($GLOBALS['TSFE']->id, '', array(
$this->prefixId . '[user]' => $user['uid'],
$this->prefixId . '[forgothash]' => $randHash
));
//add:
$link = preg_replace(
array('/\[/', '/\]/'),
array('%5B', '%5D'),
$link
);
(issue imported from #M16300)
Files
Updated by Administrator Admin about 14 years ago
The problem cannot be reproduced with TYPO3 4.4.4
It's also working fine with the latest stable release of 4.3 and the trunk.
Updated by Stefan Mielke almost 14 years ago
I can reproduce this with TYPO3 4.4.6
the problem with unmasked square brackets not fully clickable however appears only in some email clients like thunderbird, roundcubemail (webmail)
Updated by Steffen Gebert almost 14 years ago
Instead of replacing the strings, urlencode() should be used. Could you please try this and attach a patch against SVN, which does this change?
Updated by Jigal van Hemert almost 14 years ago
Solution for Thunderbird is simpler: put link inside <> pair.
This can be changed in the language strings (needs to be < and > in XML).
Can anyone test this for other email clients?
Updated by Stefan Mielke almost 14 years ago
the solution with <> pair works in thunderbird but not in webmail (roundcubemail)
urlencode seems to mess up the link.
i.e. http://example.com/index.php%3Fid%3D45%26tx_felogin_pi1%5Buser%5D%3D5%26tx_felogin_pi1%5Bforgothash%5D%3D1294345262%257C8c296a8c9c73336d2e0f385e6266f960
so i think the best solution is maybe the preg_replace suggested by Susanna Kuenzl and used with success in sr_feuser_register
this solution also works in thunderbird, webmail, apple mail, outlook and outlook express
see attached file 'patch-felogin.diff'
Updated by Steffen Gebert almost 14 years ago
Ah okay, sorry.. only the QUERY_STRING has to be urlencoded, of course!
Square brackets have to be escaped, Susanna only escapes a subset of the to-be-escaped chracters. urlencode() encodes all of them and thus has to be used. preg_replace is not readable and only a bad hack.
Updated by Steffen Gebert almost 14 years ago
Please try the attached patch (EDIT: against 4.4)
Updated by Jigal van Hemert almost 14 years ago
@Steffen: What about calling tslib_cObj::typolink() with the prepared parameters, just like tslib_cObj::getTypoLink() does?
Seems nicer than building a URL yourself...
Updated by Stefan Mielke almost 14 years ago
@Steffen: the attached patch unfortunately doesn't fix the problem
@Jigal van Hemert: I also tried with tslib_cObj::typolink_URL() which doesn't fix it either.
in both cases the link still has unmasked square brackets.
Updated by Jigal van Hemert almost 14 years ago
According to http://www.ietf.org/rfc/rfc3986.txt square brackets are allowed in URLs (they are listed as gen-delims).
The same RFC (Appendix C) tells us that:
----------
In practice, URIs are delimited in a variety of ways, but usually
within double-quotes "http://example.com/", angle brackets
<http://example.com/>, or just by using whitespace:
http://example.com/
These wrappers do not form part of the URI.
---------
The discussion in the Thunderbird forums points to RFC 2396 to claim that square brackets are illegal, but this RFC is obsoleted by 3986.
implodeArrayForUrl uses raw_urlencode() and as of PHP 5.3.0 that complies with RFC3986, which allows square brackets. So that won't help here.
It seems that email clients have some fixing up to do...
Updated by Stefan Galinski about 13 years ago
- Status changed from Needs Feedback to Accepted
- Target version deleted (
0) - TYPO3 Version set to 4.5
Updated by Jigal van Hemert almost 12 years ago
- Assignee set to Jigal van Hemert
- Target version set to 4.5.23
Testing in various mail clients showed that wrapping URIs with <> or "" does not solve the problem in all cases. It also seems that many mail clients do not comply to RFC 3986 and that they have no intention to do that in the near future.
Although it's strictly speaking wrong to fix something that is not broken, the most practical solution is to output URLs which are properly understood by mail clients.
Updated by Gerrit Code Review almost 12 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/17176
Updated by Gerrit Code Review almost 12 years ago
Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/17176
Updated by Gerrit Code Review almost 12 years ago
Patch set 3 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/17176
Updated by Gerrit Code Review almost 11 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/17176
Updated by Gerrit Code Review almost 11 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/17176
Updated by Gerrit Code Review almost 11 years ago
Patch set 1 for branch TYPO3_6-1 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/27826
Updated by Gerrit Code Review almost 11 years ago
Patch set 1 for branch TYPO3_6-0 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/27827
Updated by Gerrit Code Review almost 11 years ago
Patch set 1 for branch TYPO3_4-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/27828
Updated by Jigal van Hemert almost 11 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 8c2179f0e58ad948505636e12335b3134a5d6b0d.
Updated by Riccardo De Contardi about 7 years ago
- Status changed from Resolved to Closed