Вместо того, чтобы base64_encode() вводить информацию, необходимую для сброса пароля, со всей информацией, доступной всем для base64_decode() ее, см. это:

// this is from your example
$encoded = 'eyJ0b2tlbiI6IiQyeSQxMCRMTlgzU29HdEdOaExsay5yQ1puQ2ZlZ1wvbVNcL09BMDV2SjhcL1wvcHNRNjZaQmRpbWpOdnhGQlciLCJ0aW1lIjoiMjAxNS0xMi0xMVQwOTozOToyOSswMTAwIiwiZW1haWwiOiJsb3JlbS51dC5hbGlxdWFtQGZldWdpYXRwbGFjZXJhdHZlbGl0Lm9yZyJ9';

$data = json_decode(
    base64_decode($encoded), 
    true
);

// array (
//     'token' => '$2y$10$LNX3SoGtGNhLlk.rCZnCfeg/mS/OA05vJ8//psQ66ZBdimjNvxFBW',
//     'time' => '2015-12-11T09:39:29+0100',
//     'email' => '[email protected]',
// )

Сохранять данные в таблице

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

CREATE TABLE `password_reset` (
  `id` char(40) NOT NULL DEFAULT '',
  `token` char(60) NOT NULL DEFAULT '',
  `time` datetime NOT NULL,
  `email` varchar(255) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Идентификатор из SHA-1

Затем сгенерируйте свой идентификатор:

$id = sha1(serialize([
    'token' => '$2y$10$LNX3SoGtGNhLlk.rCZnCfeg/mS/OA05vJ8//psQ66ZBdimjNvxFBW',
    'time' => '2015-12-11T09:39:29+0100',
    'email' => '[email protected]',
    'foo' => microtime(), // for some variation
]);

Сохраните данные в своей таблице, и там у вас будет идентификатор фиксированной длины, а URL-адрес сброса пароля станет

http://example.com/resetPassword/0f4d2541c25ba8edbb3cd6df362d7dbf6317d7a5

Идентификатор как UUID

Вместо того, чтобы использовать sha1() для создания хэша из каких-то входных данных, вероятно, было бы лучше использовать, например, ramsey/uuid для создания основанного на времени UUID (фиксированная длина, 36 символов):

use Ramsey\Uuid\Uuid;

$id = Uuid::uuid1()->toString()

Хотя это не решает вашу проблему разрешения очень длинных URI, но решает проблему лучше и безопаснее.

Бонус

Взгляните на Шпаргалку по забытому паролю OWASP и связанные с ней материалы. Возможно, это поможет сделать ваше приложение более безопасный!

Используйте метод POST вместо get, и это решит вашу проблему.

Но если вы по-прежнему хотите использовать метод «GET» вместо метода «POST», то в Apache значение LimitRequestLine можно изменить на что-то большее, чем значение по умолчанию 8190, если вы хотите поддерживать более длинный URI запроса.

Если вы не можете найти LimitRequestLine в конфигурационном файле apache, просто добавьте строку самостоятельно в любом месте. например: LimitRequestLine 100000

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

Есть как минимум 2 переменные конфигурации, которые могут вызвать ошибку 414.

Директива LimitRequestLine позволяет администратору сервера установить предел допустимого размера строки HTTP-запроса клиента. По умолчанию это 4094.

Директива LimitRequestFieldSize позволяет администратору сервера установить предел допустимого размера поля заголовка HTTP-запроса. По умолчанию это 4094 байта.

Попробуйте увеличить их оба или попробуйте посмотреть, насколько велик запрос, поступающий на сервер. Было бы полезно, если бы вы разместили здесь запрос, который вы отправляете на сервер.

Полезные ссылки:

• https://confluence.atlassian.com/display/JIRAKB/Long+URLs+Are+Rejected+by+Apache+with+'Request-URI+Too+Large'+Error
• http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline
• http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
• Как разрешить запрос HTTP 414 Ошибка слишком длинного URI?

Вы не должны использовать этот шаблон, даже если он работает после изменения образа EC2.

В вашем примере схема + хост, то есть http://example.com, имеет длину 18 байт. Если ваш фактический хост имеет аналогичную длину, ограничение в 275 символов может означать, что к пути применяется ограничение в 255 символов.

Какой бы ни была причина, RFC 2068 не рекомендует использовать более длинные URI (хотя спецификация требует, чтобы серверы могли для обработки любой длины URI):

Серверы должны быть осторожны в зависимости от длины URI выше 255 байт, потому что некоторые старые реализации клиента или прокси-сервера могут не поддерживать эту длину должным образом.

Таким образом, вполне возможно, что почтовый клиент, из которого вы щелкаете, перенаправляет щелчок через какой-то внутренний прокси-сервер (например, антифишинговый), который выдает код 414. Например, так работает Zimbra. Это обычная практика в почтовых клиентах для уменьшения угроз от вредоносных ссылок. В этом случае POST вам не поможет, потому что вы не можете POST из почтового клиента.

Таким образом, единственное решение состоит в том, чтобы сохранить информацию о сбросе на стороне сервера и сделать так, чтобы URI указывал на нее с помощью более короткого токена.