почтовые клиенты удаляют часть углового URL-адреса

Я отправляю электронное письмо с активацией регистрации, содержащее URL-адрес подтверждения регистрации с токеном подтверждения, который указывает на внешнее приложение angular:

... <a href="https://domain.com/#/confirm-signup?token=1234...">Activate</a> ...

Обратите внимание, что токен представляет собой JWT и имеет довольно большую длину.

Это работает для большинства пользователей, но для некоторых, нажав на ссылку, они переходят на https://domain/com только без confirm-signup?token=...

Кажется, что почтовый клиент может удалять все после #, но я не могу найти никаких доказательств того, что у других есть эта проблема, и я не могу ее воспроизвести.

Мое лучшее предположение на данный момент состоит в том, что некоторые почтовые клиенты видят # и каким-то образом обрабатывают замыкающую часть как внутреннюю привязку и удаляют ее...?

Кто-нибудь еще сталкивался с такой проблемой? Если да, нашли ли вы какое-либо решение, кроме замены всего механизма на что-то другое?


angularjs html-email
person Peter Whitfield    schedule 19.10.2015    source источник
comment
Да, я сталкивался с этой проблемой раньше из-за #, когда мы пытались сделать ссылку на якорь на целевой странице.   -  person Bidstrup    schedule 19.10.2015

Ответы (3)


arrow_upward
1
arrow_downward

Некоторые клиенты нормально относятся к хэш-ссылке. Другие этого не делают. Здесь есть разговор о том, что Outlook грязен по этому поводу: Outlook удаляет хэш URL-адреса из электронной почты

Что мы сделали, чтобы решить эту проблему в нашей компании, так это просто создали обработчик на нашем сервере, который перенаправляет. Ваша ссылка электронной почты станет http://domain.com/email-link?url=https%3A%2F%2Fdomain.com%2F%23%2Fconfirm-signup%3Ftoken%3D1234, а ваш скрипт на стороне сервера получит параметр запроса url и немедленно вызовет перенаправление.

Вам нужно убедиться, что вы нашли все ссылки в своих электронных письмах и заменили их. Вот функция PHP для этого, но вы можете сделать это на любом языке бэкэнда, который вы используете. По крайней мере, здесь может быть полезно регулярное выражение.

function replaceLinks($html,$hash) {
    return preg_replace_callback('/<a [^>]*href=[\"\']{1}(.+?)[\"\\\']{1}/', function($matches) use ($hash) {
        return str_replace($matches[1],"http://domain.com/email-link?url=".rawurlencode($matches[1]),$matches[0]);
  }, $html);
}
person David Boskovic    schedule 20.10.2015
comment
Подозреваю, что это самое надежное решение. В краткосрочной перспективе мы использовали укороченную ссылку, но это приносит свои собственные проблемы с точки зрения того, что Gmail не одобряет и т. Д. Наше текущее приложение angular не имеет серверного компонента, поэтому это решение было бы немного боли для нас, чтобы реализовать. - person Peter Whitfield; 21.10.2015
comment
@PeterWhitfield, на самом деле вы могли бы довольно легко настроить сценарий перенаправления на веб-интерфейсе, просто просмотрев параметры запроса, а затем перенаправив с помощью window.location - person David Boskovic; 21.10.2015

arrow_upward
0
arrow_downward

Да, я сталкивался с этой проблемой раньше из-за #, я пытался сделать ссылку на якорь на целевой странице. Мое решение закончилось использованием службы short.url для «скрытия» # из html, например. https://goo.gl/

person Bidstrup    schedule 19.10.2015
comment
вы использовали только локальный якорь (т.е.: href="#...")? В Campaign Monitor есть сообщение о поведении переменных в этом случае, и я подозреваю, что для некоторых клиентов это выходит за рамки просто привязок, начинающихся с #, и иногда включает абсолютные URL-адреса, которые включают # где-то в строке. - person Peter Whitfield; 19.10.2015

arrow_upward
0
arrow_downward

Похоже, вам нужно процентное кодирование!

Много раз, когда ваш href анализируется (в данном случае с помощью angular), он неправильно обрабатывает специальные символы или удаляет их. Найдите проблемные символы и замените их на %3F вместо ?, %26 вместо & и %23 вместо #. Остальное в таблице по ссылке.

Как только закодированный адрес попадает в браузер, URL-адрес будет декодирован в вашей адресной строке.

person zazzyzeph    schedule 20.10.2015