Laravel и X-Real-IP header
Mar. 28th, 2023 02:24 pmПодробное описание, как заставить Laravel использовать адрес клиента из HTTP заголовка X-Real-IP вместо X-Forwarded-*, на форуме.
Excalidraw
Sep. 16th, 2022 10:32 amЗабавная online рисовалка https://excalidraw.com/
https://www.draw.io/ богаче по возможностям, но сабж проще.
https://www.draw.io/ богаче по возможностям, но сабж проще.
Поисковик DuckDuckGo продолжает радовать
Feb. 20th, 2021 12:29 pmпоисковой страницей на чистом HTML: https://html.duckduckgo.com/
Опубликовать документ в формате markdown
Mar. 31st, 2020 09:25 pmhttp://strapdownjs.com/ - гениально! Нужен только статический web-сервер, а рендеринг будет происходить в браузере.
Пример выложенного документа: http://admin.sibptus.ru/~vas/CA.html
Пример выложенного документа: http://admin.sibptus.ru/~vas/CA.html
read.amazon.com
Apr. 14th, 2019 03:29 pmОказывается существует такая замечательная вещь, как https://read.amazon.com/ - все купленные на Амазоне (и хранящиеся в облаке) книги можно читать прямо из браузера, без установки Kindle и т.п.
Вот бы ещё придумать, как при этом свой основной амазоновский логин/пароль не светить.
Вот бы ещё придумать, как при этом свой основной амазоновский логин/пароль не светить.
Реакция на мусор в исходном коде
Apr. 14th, 2019 12:47 amИнтересно, как должен поступать уважающий себя компилятор или интерпретатор, если в исходном коде уже после окончания текста программы встретится мусор? Должен ли он игнорировать его и выполнить программу, или выдать сообщение об ошибке?
В одной конторе не работало автоопределение прокси. Уже и "ping wpad" проверяли, и "http://wpad/wpad.dat" вручную скачивали - всё работает, в access.log веб-сервера видно, что браузеры скачивают этот wpad.dat при запуске, но к прокси потом не обращаются. Оказывается, в wpad.dat уже после закрытия всех скобок оказался мусор, попавший туда скорее всего при копипасте в этот wpad.dat через PuTTY. Заметили этот мусор только hex редактором, уже от отчаяния.
Вот как это называется? Ты уж или сообщение выдай об ошибке в коде, или выполни то, что в коде корректно. Но молчаливое игнорирование?!
В одной конторе не работало автоопределение прокси. Уже и "ping wpad" проверяли, и "http://wpad/wpad.dat" вручную скачивали - всё работает, в access.log веб-сервера видно, что браузеры скачивают этот wpad.dat при запуске, но к прокси потом не обращаются. Оказывается, в wpad.dat уже после закрытия всех скобок оказался мусор, попавший туда скорее всего при копипасте в этот wpad.dat через PuTTY. Заметили этот мусор только hex редактором, уже от отчаяния.
Вот как это называется? Ты уж или сообщение выдай об ошибке в коде, или выполни то, что в коде корректно. Но молчаливое игнорирование?!
1. При попытке загрузить в Drupal 8 модули или темы через админский веб-интерфейс возникает приглашение ввести учетные данные для доступа к коду сайта по FTP (!).
Решение (при условии, что пул php-fpm работает от пользователя www):
2. При попытке загрузить в Drupal 8 модули или темы через админский веб-интерфейс возникает "AJAX HTTP ошибка, полученный код HTTP 403" с невнятным упоминанием "/core/authorize.php/core/authorize.php?batch=1...". Это значит, вы делали настройку связки drupal+nginx+php-fpm по статье https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/ , но натолкнулись на баг, описанный в https://pantheon.io/blog/update-your-nginx-config-drupal-8. Но решение в тексте статьи описано неправильно, правильное решение есть в комментах, и заключается в строчке
Решение (при условии, что пул php-fpm работает от пользователя www):
chown -R www:www /usr/local/www/drupal8/modules /usr/local/www/drupal8/themes
2. При попытке загрузить в Drupal 8 модули или темы через админский веб-интерфейс возникает "AJAX HTTP ошибка, полученный код HTTP 403" с невнятным упоминанием "/core/authorize.php/core/authorize.php?batch=1...". Это значит, вы делали настройку связки drupal+nginx+php-fpm по статье https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/ , но натолкнулись на баг, описанный в https://pantheon.io/blog/update-your-nginx-config-drupal-8. Но решение в тексте статьи описано неправильно, правильное решение есть в комментах, и заключается в строчке
rewrite ^/core/authorize.php/core/authorize.php(.*)$ /core/authorize.php$1;
прямо в блоке server{} перед
location ~ \..*/.*\.php$ {
return 403;
}nginx и CGI скрипты
Jan. 24th, 2019 09:44 pmnginx, в отличие например от Apache httpd, не умеет сам запускать CGI-скрипты, ему нужен внешний сервер приложений, с которым nginx будет общаться по протоколу FastCGI или другому.
Если не нужна высокая производительность или фичи, а просто хочется эмулировать функционал апачевского mod_cgi, то проще всего поставить из портов демон www/fcgiwrap и передавать ему запросы через Unix socket. При запуске демона очень желательно указывать fcgiwrap_flags="-f", иначе ошибки fcgiwrap будут уходить в никуда (а при -f будут видны в nginx/error.log). И при необходимости перезапустить его вручную надо не забывать очистить переменные среды (например "env -i /usr/local/etc/rc.d/fcgiwrap restart"), иначе весь environment рута станет виден в CGI-скриптах).
Если CGI-скрипты планируется держать в /usr/local/www/cgi-bin/, а сокет для обмена между nginx и fcgiwrap в /tmp/fcgiwrap.socket, то секция nginx.conf должна выглядеть так:
Обратите внимание, что в директиве root отсутствует "cgi-bin", хотя это реальный каталог на диске, в котором хранятся скрипты. Почему так?
Дело в том, что путь к скрипту задаётся (передаётся в fcgiwrap) склеиванием двух переменных: DOCUMENT_ROOT и SCRIPT_NAME, в которые мапятся (в fastcgi_params) nginx-овские переменные $document_root и $fastcgi_script_name соответственно. По умолчанию $fastcgi_script_name=$request_uri, то есть при обращении к
Отлаживать скрипты вообще без веб-сервера можно как показано ниже, заодно это помогает лучше понять протокол обмена:
Если не нужна высокая производительность или фичи, а просто хочется эмулировать функционал апачевского mod_cgi, то проще всего поставить из портов демон www/fcgiwrap и передавать ему запросы через Unix socket. При запуске демона очень желательно указывать fcgiwrap_flags="-f", иначе ошибки fcgiwrap будут уходить в никуда (а при -f будут видны в nginx/error.log). И при необходимости перезапустить его вручную надо не забывать очистить переменные среды (например "env -i /usr/local/etc/rc.d/fcgiwrap restart"), иначе весь environment рута станет виден в CGI-скриптах).
Если CGI-скрипты планируется держать в /usr/local/www/cgi-bin/, а сокет для обмена между nginx и fcgiwrap в /tmp/fcgiwrap.socket, то секция nginx.conf должна выглядеть так:
location /cgi-bin/ {
root /usr/local/www;
include /usr/local/etc/nginx/fastcgi_params;
fastcgi_pass unix:/tmp/fcgiwrap.socket;
}
Обратите внимание, что в директиве root отсутствует "cgi-bin", хотя это реальный каталог на диске, в котором хранятся скрипты. Почему так?
Дело в том, что путь к скрипту задаётся (передаётся в fcgiwrap) склеиванием двух переменных: DOCUMENT_ROOT и SCRIPT_NAME, в которые мапятся (в fastcgi_params) nginx-овские переменные $document_root и $fastcgi_script_name соответственно. По умолчанию $fastcgi_script_name=$request_uri, то есть при обращении к
http://myserver.example/cgi-bin/myscriptfcgiwrap получит команду найти на диске и выполнить "/usr/local/www"+"/cgi-bin/myscript". Естественно $fastcgi_script_name можно переопределить, например с помощью $fastcgi_split_path_info, но для простейшей эмуляции mod_cgi это не нужно.
Отлаживать скрипты вообще без веб-сервера можно как показано ниже, заодно это помогает лучше понять протокол обмена:
#!/bin/sh -x DOCUMENT_ROOT=/usr/local/www/ ; export DOCUMENT_ROOT REQUEST_URI=/cgi-bin/myscript ; export REQUEST_URI SCRIPT_NAME=$REQUEST_URI; export SCRIPT_NAME REQUEST_METHOD=GET ; export REQUEST_METHOD su -m www -c '/usr/local/bin/cgi-fcgi -bind -connect /tmp/fcgiwrap.socket'
Техническое задание на создание сайта
Dec. 30th, 2018 06:22 pmДавно хочу заказать себе персональный сайт. Интересно, сколько примерно может стоить такая работа, согласно нижеприведенному ТЗ, и кому её можно заказать?
UPD отредактировано с учётом замечаний![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
veefore
UPD отредактировано с учётом замечаний
veefore- Сайт должен строиться полностью на статическом HTML, без «движков» на стороне Web-сервера. Ничего не должно отдаваться из СУБД. Допускается использование СУБД sqlite для сохранения промежуточных результатов.
- Сайт должен быть полностью автономным (не подгружать в браузер стилей и библиотек из Интернет) и работоспособным на локальной машине без доступа в Интернет. Использование JavaScript на стороне браузера допускается.
- Сайт должен быть полностью работоспособен при просмотре браузером с локальной файловой системы без Web-сервера, а также при размещении на Web-сервере, поддерживающем только статический контент.
- Дерево сайта должно быть рассчитано на хранение в системе контроля версий, предпочтительно Mercurial.
- Сайт должен строиться скриптом на распространенном языке (Python, Perl, PHP и т.п.) с использованием интерпретаторов и библиотек, доступных во FreeBSD ports collection.
- Должна быть предусмотрена возможность изменять внешний вид сайта (шрифты, цвета, элементы оформления) с помощью отдельного стилевого (конфигурационного) файла или скина.
- Скрипт должен строить сайт из материалов, опубликованных в блоге https://victor-sudakov.dreamwidth.org/ и https://victor-sudakov.livejournal.com/ .
- Должна быть предусмотрена возможность зеркалирования «подзамочных» записей при задании в скрипте логина/пароля.
- При наличии в блоге embedded изображений, видео и других встроенных объектов, они должны скачиваться на локальную машину и становиться частью статического сайта.
- Внешние ссылки должны оставаться как есть, но их валидность должна проверяться (можно не при каждом запуске скрипта, а предусмотреть отдельный ключ запуска «проверить ссылки»).
- Скрипт должен поддерживать инкрементальное обновление сайта при появлении новых записей и комментариев в блоге.
- Скрипт должен быть неинтерактивным и поддерживать работу из-под cron.
- «Тэги» должны быть преобразованы в тематические разделы. Навигация по сайту должна предусматривать просмотр по темам и по дате публикации материала в прямом и обратном порядке, а также иметь раздел «Карта сайта».
- Для записей без тэгов предусмотреть тематический раздел «Разное». Изменение/добавление/удаление тэгов в уже скопированных статьях должно отслеживаться, статья должна перемещаться по разделам в сооветствии с актуальным набором тэгов.
- Каждая статья должна содержать гиперссылку на соответствующую страницу в DW или LJ, откуда она была импортирована.
- Каждый импортированный комментарий должен содержать гиперссылку на автора комментария.
- Должны быть предусмотрены специальные страницы «Все статьи по данной теме», «Все статьи за выбранный год» и «Все статьи сайта» без ограничения на длину страницы и разбиения на страницы (для поиска нужного заголовка по Ctrl+F в браузере)
- Должно быть предусмотрено представление любой статьи в формате «для печати» и всего сайта в виде книги формата PDF.
