Ярослав

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

Если речь идет про защиту от копирования - я бы просто вставил какую-то сетевую функцию в код, чтобы что-то выполнялось по сети, с вашего сервера (и этого кода не было на клиентской части). Если нужно будет отключить - просто на сервере отключаете. Это обойти будет очень сложно.

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

def x():
    print("x called")
fname="x"
globals()[fname]()

Ответ со словарем (выше) хороший. А еще есть встроенный словарь символов, который выдает globals().
И eval() - тоже вариант. Но если fname у вас идет из ненадежного источника (пользователя) - то это опасно (через globals() - тоже опасно). Например:

globals()['os'].system("clear")
Вызовет clear, а может вызвать и rm -rf / .

Если нужен безопасный eval - советую посмотреть на evalidate (disclaimer: этой мой пакет), и там по ссылкам еще альтернативы есть - asteval и simleeval. Через них можно (если аккуратно) сделать безопасный eval и проверить его популярным джейлбрейками (в evalidate они есть, и есть в тестах к нему).

Сам себе отвечу.
1. В том браузере, который (как у меня) кодирует скобки-кавычки - проэксплойтить эту уязвимость нельзя. Кодирование есть на стороне браузера.
2. Это "хороший тон", RFC3986, секция 2.2 https://datatracker.ietf.org/doc/html/rfc3986#sect... обязывает кодировать только некоторые другие символы:

If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed.

reserved = gen-delims / sub-delims

gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"

sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="

Никакого другого требования кодировать я не нашел. То есть, curl, когда не кодирует двойные кавычки и угловые скобки - действует строго по RFC, а вот httpie или браузер - сами кодируют "лишние" символы, но они не обязаны делать это.

Ну и главное тут - это происходит на стороне клиента, следовательно: 1) на стороне клиента может быть что-то поломаное, работающее с ошибкой. Может быть какой-то новый (новорожденный) браузер с этими проблемами. Может быть старый очень браузер. Могут быть какие-то особые настройки, сочетания настроек и дополнений, из-за которых он не делает так. и 2) Браузер вполне может исполнять только требования RFC, но не более. Защищать дырявое приложение от XSS атак он не обязан.

3. Включать REQUEST_URI в ответ неправильно. Лучше так не делать. Но, тем не менее, есть такой тонкий и негарантированный слой защиты в популярных браузерах, который защищает от этого. Но никто не дает никаких гарантий, положиться на это нельзя.

Предполагаю, что никак. Вероятно, вы берете данные (музыку) с чужого сервера? Современные браузеры требуют, чтобы тот сервер (не ваш, и не ваше фронтенд-приложение) отдавал вместе с файлом еще и заголовок Access-Control-Allow-Origin (с адресом вашего сайта. Мол, "да, по запросам с этого сайта можно отдавать этот файл"), а если вы устанавливаете еще какой-то заголовок в запросе - то этот заголовок тот сервер должен сам от вас хотеть принять и упомянуть его в Access-Control-Allow-Headers в ответе.

Сейчас я вижу, что у вас играет музыка. Вы удалили какой-то проблемный источник и оставили только те, которые позволяют доступ с любых Origin?

XSS - это не атака на сервер, а атака на пользователей.
Допустим, есть огромная XSS уязвимость на сайте. Мы можем заманить пользователя на нужный "хитрый" урл на том сайте ("нажмите на эту ссылку" или даже через JS на нашем сайте перенаправить его), или отправить на тот сайт сабмит формы. В итоге пользователь оказывается на уязвимом сайте с "вредным" запросом, и, например (уже в браузере пользователя!) исполняется код (с полномочиями пользователя на этом сайте).

Например, если банковское веб-приложение (его JS код) позволяет делать переводы, то и внедренный через XSS JS код тоже сможет сделать такие же запросы на перевод к серверу.

А запуск просто 20 раз даст то, что вам нужно? Не требуется никакая коммуникация между процессами?
Тогда однозначно запускайте просто 20 копий программы, можно через parallel (стандартная утилита, есть наверное, везде) или просто своим шелл-скриптом. Будет быстрее и надежнее.

В пайтоне есть GIL и это сильно влияет на производительность в многопоточном режиме. Да и вообще, зачем усложнять? Один изолированный процесс, который делает какую-то простую функцию - это богоугодно. А если вы делаете монстра, который внутри себя запускает потоки/процессы то только в идеале вы приблизитесь к рекомендуемому варианту. А не в идеале - будете иметь проблемы с производительностью или какие-то сложноуловимые глюки и race conditions.

Многопоточность оправдана только если без нее никак, например, нужна коммуникация между процессами, работа с общими данными.

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

А какая-нибудь тильда вам не подойдет? Я так понимаю, высоких требований у вас нет - не проще ли это бесплатно где-то захостить?
И еще, если будет интересно - можно подумать в сторону jamstack сайтов (статических). Многие блоги, например, очень хорошо реализуются как статические сайты. (Современный статический сайт - совсем не так, как было в 90-ых, он может иметь JS, может пользоваться разными API, например, статичные блоги имеют комменты от disqus или других подобных сервисов). Потребуется сделать небольшую learning curve. Но у вас, мне кажется, типичный блог - каждое новое появившееся животное - это новый пост в этом блоге.

Из SSG (генераторов статичных сайтов) я предпочитаю hugo, но тут на вкус и цвет (я просто не люблю те, что написаны на JS).

Какие плюсы вы получите, если сайт будет статичным:
1. Он будет очень быстрым, это приятно пользователям и может хорошо индексироваться поисковиками (я для теста выжимал 100/100/100/100 web vitals по google lighthouse - оценка для десктопов, и 98/100/100/100 для мобил)
2. Его можно хостить бесплатно на куче хостингов типа netlify, cloudflare pages, github, gitlab, ...
3. Очень высокий аптайм, эти сервисы оочень редко ломаются.

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

Я бы все-таки предпочел wireguard и пока что не слишком волновался насчет того, что его блокируют - это все легко обходится. Раз у вас свой сервер, то решается все легко.

Думать о том, как там будет через 3 года, и готовиться обязательно к самому худшему сценарию пока не нужно. А то потратите силы на подготовку к самому худшему, а он не случится - обидно будет. Но даже если случится, через три года если что и переставите, а там может или шах или ишак. А все это время лучше жить с быстрым VPN, пользоваться которым одно удовольствие. И ставится он "красиво", системным способом, а не как Outline.

У wg очень простая сигнатура для DPI, поэтому легко его детектят и блочат. Но для этой проблемы несколько вариантов решений.

Решение 1 от ValdikSS : Сначала с того же клиентского порта и на тот же серверный "пробить" соединение другим пакетом (без сигнатуры). Так как для DPI этот пакет - часть соединения, то оно уже не похоже на wg. А вот wg сервер просто проигнорирует первый мусорный пакет, выбросит, а на второй ответит.

wg0.conf: ListenPort = 56789

sudo nping --udp --count 1 --data-length 16 --source-port 56789 --dest-port DEST_PORT DEST_IP

Как проверить, что wireguard не заблокирован?
https://ntc.party/t/wireguard/4968/6
(обратите внимание на то, что на клиенте нужно зафиксировать ListenPort)

2. Тот же самый эффект, но без ручного запуска nping каждый раз (просто автоматизируем то же решение):
в конфиг wg (wg0.conf или какой у вас) просто пишем:

[Interface]
PrivateKey = ....
Address = 10.9.0.2/24
ListenPort = 12345

PreUp = nping --udp --count 1 --data-length 16 --source-port 12345 --dest-port 12345 123.123.123.123

3. Можно чуть больше заморочиться, и замаскировать (обфусцировать) wg трафик через netfilter - если на клиенте и сервере закодировать его с одинаковым ключом (и самым простым шифрованием) - DPI его не видит.
https://github.com/infinet/xt_wgobfs

В общем, wireguard сам по себе искаропки не умеет "прятаться" (это и не его задача), но если нужно его спрятать - это делается в две минуты. (Ну первый раз подольше, пока разбираешься). Силы зла и негетеросексуализма и так уже вынуждены применять дорогой и тяжелый DPI для блокировки очень простого VPN. Блокировать обфусцированный, как в этих примерах - на порядок (порядки) сложнее (если вообще возможно) и точно неэффективно - огромные затраты, чтоб заблочить VPN всего паре десятков тысяч ITшников, которые тут же как-то иначе наладят себе VPNы (в крайнем случае перейдут на Outline или что-то еще) - бессмысленно, поэтому, думаю, никогда и не случится.

Если очень хочется поиграться с амазоном: https://aws.amazon.com/free/ - вообще бесплатно, но это только на 12 месяцев. Для поиграться, чтоб немного получить опыта и строчку в резюме - может быть нормально. Но хоститься там будет дороже, чем на дешевом VPS вроде hetzner.

И в гугле есть бесплатная VPS если сможете привязать карту к ним. (привязка нужна и у меня почему-то снимают все-таки пару центов изредка). Получается и дешево и вполне себе "облачные технологии".

Но у вас парадоксальная ситуация, что вам облачность-то реально не нужна, нужна чисто "облачность ради облачности". Как по мне, облака - это либо для "больших мальчиков" (ну типа какого-нибудь м-видео или леруа), либо для модных стартапов, которые хотят сейчас запуститься и может быть через месяц быстро размножиться на тысячи серверов про большом успехе. Для большинства даже крупных (но не гиганстких) компаний достаточно обычных серверов (впски или дедики) - это гораздо дешевле. Но это если сумма за хостинг вам важна и ощутима. Если переплатить не страшно - тогда да, можно сразу в облака - некоторые вещи там могут оказаться удобнее (но никогда не дешевле).

Я считаю себя скорее бэкэндщиком, и да - много раз пришлось фронт заново повторять, вспоминать очевидное, потому что тяжело решать какую-то простую "фронтовую" задачу раз в 2-3 года. За это время все забываешь, да.
Точно так же забывается golang, если долго программируешь на python, и вообще любые неиспользуемые знания пропадают - так уж мозг устроен.

Но две важных вещи:
1. Вспоминать забытое - просто и быстро, это не учиться с нуля. Скорее всего какой-нибудь cheatsheet поможет из сети или самодельный. Они не пропадают совсем.
2. Это все равно надо. Хороший специалист в любой сфере должен иметь некоторое представление и о смежных вещах. Бекэндщику никуда без хотя бы базовых знаний по фронтенду. Фронтендщику бэк, наверное, нужен немного меньше, но если хочется быть ценным специалистом - то все равно нужно.

Вот обзор аж девяти сервисов https://woorkup.com/email-forwarding-service/ включая cloudflare. (которому я очень симпатизирую и который надежен). Почта остается на том же сервисе (например, бесплатная username@ya.ru или @gmail.com, да какая хотите!) но на этот ящик будет валиться почта на ваш @domain.com.

Одна тонкость. Когда пробуете их и получаете письмо - попробуйте ответить и посмотрите, на какой адрес идет ответ. На яндексе у меня бывает глюк, что по кнопке ответа, ответ пишется не отправителю, а мне же на "доменный" адрес.

Немного поздновато, наверное, но может кому-то еще потребуется (я же как-то попал на этот древний вопрос):

Homed (Дашбоард с интеграцией в authelia):
https://github.com/mwalters/homed

Homepage:
https://github.com/benphelps/homepage
https://youtu.be/dk3Cp5ck8mY
https://blog.unixhost.pro/ru/2023/03/homepage-glav...

mail.ru вроде уже тоже нет.

есть чуть более сложный (но вполне работоспособный) вариант с improvmx.com лишь cloudflare.com (email routes)

подробнее:
https://qna.habr.com/q/1182558

Мой совет - для хранения, чтения, фильтрации почты и всего прочего (если хотите бесплатно) - используете любой почтовый сервис, который вам нравится (gmail, yandex, все что хотите). Проблема только в том, чтобы использовать свой домен. А это решается иначе.

1. ImprovMX.com
Регаетесь там, и настраиваете пробросы адресов (в том числе можно и catch-all) на любые другие почтовые адреса, например, на яндексе. Так что, у вас получается @yourdomain.com но бесплатно

2. Cloudflare email routing
Если DNS для домена хостится на Cloudflare - то же самое можно сделать средствами Cloudflare, бесплатно и вроде безлимитно. Читать: так же, на яндексе-мейле-гмейле, где хотите.

В общем, мы используем доп сервис (cloudflare/improvmx) для "своедоменификации", а в остальном живем как и раньше, на удобном-бесплатном сервисе.

Отправлять - вроде бы большинство сервисов (gmail точно) позволяет отправлять с чужого домена, только SPF надо подправить. Так что в исходящих письмах тоже будет ваш собственный домен, но отправляться через сервера яндекса-гмейла-...

Из минусов - лишняя точка отказа (но в SMTP с этим хорошо, протокол надежный), минута тратится на доставку, есть какие-то ограничения.

Лимиты у ImprovMX - 500 входящих в день. Размер аттача не знаю.
Cloudflare: 25Mb на сообщение (аттач). Не знаю, это именно на чистый разме файла, или на размер сообщения. По количеству лимитов вроде бы нет.

Почему мне нравится такой вариант:
- У нас есть выбор для почтового роутера (cloudflare/improvmx/....). Если что-то не нравится - выберем другой (не меняя ящика)
- У есть есть практически неограниченный выбор бесплатных почтовых сервисов с их щедрыми лимитами.
- Все бесплатно и не зависит от сложностей с оплатой.

Еще по теме (больше аналогичных вариантов): https://woorkup.com/email-forwarding-service/

cross site request forgery (наиболее вероятно и достаточно опасно)
clickjacking (хотя он тут не кажется опасным)
возможность забить ваш диск большим количеством файлов (если на виртуалке 20 гигов, то передать 20 гиг скриптом можно быстро)
возможность залить какой-то ненастоящий CSV
если (самое ужасное) имя и-или путь к файлу как-то зависит от пользователя (от данных в форме) - возможность перезаписать другие доступные файлы