Сейчас Response Rules в секции “responseModifications” делают весьма массовые изменения. Например, предлагается менять либо json для всех хостов, либо не трогать его вовсе.
Данный принцип работы, в преддверии отказа от legacy “Serve JSON at the base path”, может не породить желания у пользователей разбираться в предлагаемом для них новом функционале (более того, я убежден что не все знакомы с тем, что Response Rules в целом существуют), из-за чего те будут ограничиваться только текущей GUI настройкой хостов, хотя у самих Response Rules большой потенциал.
Я предлагаю расширить возможности модификации отдаваемых хостов в целях улучшения функционала правил ответа. Вместе с возможной реализацией идеи которую затронул в одном из предыдущих топиков, а именно: единая часть секции Xray Json & Raw для нескольких хостов, но в этот раз без введения GUI мусора в виде папки.
Начнем с дополнений касающихся исключительно responseModifications.
1.Response Rules
[!note]
Прежде всего, необходимо уточнить, что в данном предложении данная секция делится на 2 уровня, общую (что есть сейчас) и отведенную под конкретные хосты.
Как было сказано, мы уже можем менять JSON для всех хостов, но почему бы не сделать возможность менять JSON для конкретного хоста/ов? Например:
"responseModifications": {
"ignoreHostXrayJsonTemplate": false,
"responseRules": [
{
"host": "uuid-хоста-1",
"ignoreHostXrayJsonTemplate": true,
"HostXrayJsonTemplate": "Host-1 Template"
},
{
"host": "uuid-хоста-2",
"ignoreHostXrayJsonTemplate": true,
"HostXrayJsonTemplate": "Host-2 Template"
}
]
}
Так, в данном примере вторая строка указывает что JSON не меняется для всех хостов, кроме хост-1 и хост-2, которым в свою очередь отводится отдельный JSON темплейт. Соответственно этот набор правил можно использовать и для реализации другой ситуации: тронуть все, кроме хост-1 и хост-2, а именно:
"responseModifications": {
"ignoreHostXrayJsonTemplate": true,
"subscriptionTemplate": "Json Other",
"responseRules": [
{
"host": "uuid-хоста-1",
"ignoreHostXrayJsonTemplate": false
},
{
"host": "uuid-хоста-2",
"ignoreHostXrayJsonTemplate": false
}
]
}
Это может быть полезно для сохранения legacy совместимости. Например с помощью “operator”: “REGEX”, если мне не изменяет мой рассудок, можно выбирать не только конкретные приложения, но и их версии, которые могут являются устаревшими и/или не корректно работающими с новыми функциями. Пользователям обычно требуется время для обновления, их может требоваться попросить несколько раз об этом. А в условиях когда единственным средством связи с миром является устаревшее приложение, которое перестало работать после обновления конфигураций администраторами, это может быть очень печально.
Вместе с тем, было бы полезно так же скрывать ряд хостов с определенных устройств. В основном чтобы не путать пользователей. Это полезно для разделения мобильных и компьютерных пользователей, например: ядро xray способно захватить process только на Windows и Linux, следовательно отдавать хост с такой секцией внутри json на другие системы смысла нет в целом. А также, сейчас популярно отдавать хосты, которые предназначены для использования только на мобильных устройствах. Потому предлагается следующее:
"responseModifications": {
"ignoreHostXrayJsonTemplate": true,
"subscriptionTemplate": "Json Other",
"responseRules": [
{
"host": "uuid-хоста-1",
"ignoreHostXrayJsonTemplate": false,
"hideHost": true
},
{
"host": "uuid-хоста-2",
"ignoreHostXrayJsonTemplate": false
}
]
}
Так, можно с помощью отдачи параметра “hideHost”: true скрыть в выдаче для определенных устройств определенный хост. По умолчанию же “hideHost” идет false.
Если же поставить “hideHost”: true выше в правилах чем “responseRules” секцию, то должны скрываться все хосты. С указанием уже внутри “responseRules” тех хостов, у которых будет параметр “hideHost”: false.
2.Изменения параметров Host
Теперь мы переходим к тому о чем я упоминал, об Xray Json & Raw. Вообще в свое время я поднял этот вопрос, так как столкнулся с тем, что на устаревших клиентах finalMask выбивал ошибку, из-за чего его пришлось убрать в целом, у всех клиентов. Сейчас я сам вижу проблемы в том решении которое предлагал ранее, и новый вариант мне кажется более гибким и решающим вопрос практически полностью.
Суть его в следующем: секцию Xray Json & Raw стоит разделить. Потому что это уже никакие не Raw настройки, какими задумывались, теперь там передаются параметры не только для этого транспорта, но и для xHTTP, и это хорошо, это делает панель гибче, но и ведет к тому, что категория не соответствует действительности и ограничена своим названием.
Потому, Xray Json остается на своем законном месте и Mapper двигается ближе к нему, а все остальные настройки (от xHTTP до FinalMask) переводятся в другую секцию, чуть ниже Xray Json and Mapper. Назвать её Additional Parameters (или на своё усмотрение) и сделать её настройки параметром с выплывающим меню (как сейчас вы выбираете Json для хоста, тоже самое). Для этого, соответственно, придется сделать новый раздел Additional Parameters, внутри раздела Subscription и рядом с секцией Hosts. Сам же раздел из себя будет представлять наборы различных темплейтов содержащих те самые Additional Parameters.
Данное изменение необходимо не только по причине “желания дать N хостам одинаковые дополнительные параметры”, но так же по причине того, что иначе изменение FinalMask и пр параметров, невозможно сделать используя Response Rules в текущем состоянии
3.Изменения в Mapper
Теперь поднимается вопрос про Mapper. Mapper должен начать уважать то, что указано в Additional Parameters. По той причине, что Mapper сейчас удаляет кастомные настройки секции mux и прочих, а не только те, что отлетают со стандартным инбаундом. Так, вы можете в один день удалить из стандартного конфига этот раздел mux с помощью функционала Mapper, но потом добавить его в Additional Parameters (или текущий mux), в итоге Mapper будет вырезать и его, но это не дело. А предполагать что настройки каждого маппера администрация будет держать в голове нельзя.
Изменив это поведение, на то чтобы Mapper не изменял параметры Additional Parameters, можно решить две вещи: будут настройки хоста Xray Json and Mapper, а также дополнительные Additional Parameters, стоящие не только выше Json (как сделано сейчас), но и выше чем Mapper. Что позволит сделать не только Xray Json массовым параметром для хостов, но и все входящее внутрь новой категории настройки.
4.Продолжение Response Rules
Теперь мы переходим к тому, чтобы так же позволить в Response Rules изменять темплейт Additional Parameters. Так как теперь это отдельно регулируемый темплейт настроек, которую Mapper не перебивает своими правилами. Соответственно:
"responseModifications": {
"ignoreHostXrayJsonTemplate": true,
"subscriptionTemplate": "Json Other",
"responseRules": [
{
"host": "uuid-хоста-1",
"AP-template": "xHTTP+Finalmask"
},
{
"host": "uuid-хоста-2",
"AP-template": "Finalmask"
}
]
}
"AP-template": "Template name"
Как можно понять, я считаю что смена AP-template должна происходить без указания “ignoreHostXrayJsonTemplate”: true, так как это лишь может породить дополнительные строчки правил, в ситуации когда основной темплейт должен остаться без изменений, и только Additional Parameters должны быть изменены
[!note]
Спасибо большое всем, кто прочитал до конца. А так же всем кто участвует в разработке и поддержке панели, в качестве контрибьютора или донатера.
P.s: я мог предложить не самый идеальный вариант, может есть камни которые я не заметил, но это то как я вижу ситуацию на данный момент