Entries tagged with web

Entry tags:

Laravel и X-Real-IP header

Подробное описание, как заставить Laravel использовать адрес клиента из HTTP заголовка X-Real-IP вместо X-Forwarded-*, на форуме.

Entry tags:

Excalidraw

Забавная online рисовалка https://excalidraw.com/

https://www.draw.io/ богаче по возможностям, но сабж проще.

Crossposts: https://victor-sudakov.livejournal.com/478829.html

Entry tags:

Поисковик DuckDuckGo продолжает радовать

поисковой страницей на чистом HTML: https://html.duckduckgo.com/

Crossposts: https://victor-sudakov.livejournal.com/459009.html

Entry tags:

Опубликовать документ в формате markdown

http://strapdownjs.com/ - гениально! Нужен только статический web-сервер, а рендеринг будет происходить в браузере.

Пример выложенного документа: http://admin.sibptus.ru/~vas/CA.html

Crossposts: https://victor-sudakov.livejournal.com/440253.html

Entry tags:

books,
web

Оказывается существует такая замечательная вещь, как https://read.amazon.com/ - все купленные на Амазоне (и хранящиеся в облаке) книги можно читать прямо из браузера, без установки Kindle и т.п.

Вот бы ещё придумать, как при этом свой основной амазоновский логин/пароль не светить.

Crossposts: https://victor-sudakov.livejournal.com/440063.html

Entry tags:

Реакция на мусор в исходном коде

Интересно, как должен поступать уважающий себя компилятор или интерпретатор, если в исходном коде уже после окончания текста программы встретится мусор? Должен ли он игнорировать его и выполнить программу, или выдать сообщение об ошибке?

В одной конторе не работало автоопределение прокси. Уже и "ping wpad" проверяли, и "http://wpad/wpad.dat" вручную скачивали - всё работает, в access.log веб-сервера видно, что браузеры скачивают этот wpad.dat при запуске, но к прокси потом не обращаются. Оказывается, в wpad.dat уже после закрытия всех скобок оказался мусор, попавший туда скорее всего при копипасте в этот wpad.dat через PuTTY. Заметили этот мусор только hex редактором, уже от отчаяния.

Вот как это называется? Ты уж или сообщение выдай об ошибке в коде, или выполни то, что в коде корректно. Но молчаливое игнорирование?!

Crossposts: https://victor-sudakov.livejournal.com/437938.html

Entry tags:

Проблемы с загрузкой модулей и тем в Drupal через Web-интерфейс

1. При попытке загрузить в Drupal 8 модули или темы через админский веб-интерфейс возникает приглашение ввести учетные данные для доступа к коду сайта по FTP (!).

Решение (при условии, что пул 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;
    }

Crossposts: https://victor-sudakov.livejournal.com/434658.html

Entry tags:

nginx и CGI скрипты

nginx, в отличие например от 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 должна выглядеть так:

        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/myscript

fcgiwrap получит команду найти на диске и выполнить "/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'

Crossposts: https://victor-sudakov.livejournal.com/432741.html

Entry tags:

Техническое задание на создание сайта

Давно хочу заказать себе персональный сайт. Интересно, сколько примерно может стоить такая работа, согласно нижеприведенному ТЗ, и кому её можно заказать?

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.