dil: (Default)
Friday, May 25th, 2018 06:30 pm

Моя первая разработка на django – система поиска производителей сетевых адаптеров по MAC-адресам: mac.dil.pp.ru .
А некоторое время назад сайт почему-то перестал работать, выдавал ошибку

uWSGI Error
Python application not found

Программа действительно была запущена через uwsgi, посмотрел в его лог, а там дикая ошибка:

Traceback (most recent call last):
  File "./mac/wsgi.py", line 10, in 
    import os
ImportError: No module named os

Потому веб-сервер и не мог прицепиться к этому неазпускающемуся приложению:

unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***

Запустил питон в консоли, там import os нормально работает. Запустил программу через джанговский manage.py runserver – тоже работает, а в uwsgi почему-то нет..

Почти неделю копался, но толком не мог понять, отчего же стандартный питоновый модуль может не импортироваться.

Ну, похоже, что uwsgi пытался использовать старый python 2.6, а он уже проапдейтился до 2.7. Так что грабельки удалось обойти, вписав в uwsgi’шный ini-файл plugin = python27. Теперь вроде нормально работает.

Оригинал этой записи в личном блоге.

dil: (Default)
Friday, October 6th, 2017 09:22 pm

Не грабельки, просто загадка для специалистов по веб-сайтам:

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

Ну я первым делом запустил wget -S http://сайт/, чтобы посмотреть, куда там перенаправление, а оттуда index.html успешно скачался без всяких перенаправлений.
Потом зашёл туда же браузером, а его и вправду перенаправило на другой сайт..

Подумал, что, может там проверяется User-Agent, и перенаправляются только обычные браузеры, а прочие программы игнорируются.
Посмотрел в конфиг тамошнего Апача, а там ничего такого нету, обычный VirtualHost без всяких Redirect’ов, и никаких особых настроек для директории, которая DocumentRoot этого сайта.
Посмотрел в саму директорию, вдруг там какой-нибудь php’шный скрипт, но нет, там обычный index.html . И никакого .htaccess’а нету. Так как же это перенаправление работает?

Потом ещё посмотрел в сам index.html, может там это javascript’ом сделано, но тоже нет, там вовсе никаких скриптов нету..

Отгадка:

Read the rest of this entry » )

Оригинал этой записи в личном блоге.

dil: (Default)
Monday, June 5th, 2017 05:57 pm

Нет ли среди моих читателей специалистов по TinyMCE?

Мне хочется к стандартному редактору (скорее, 3 версии, включённой в django-tinymce) добавить несколько кнопочек для дополнительных HTML-тэгов, типа <code>, <pre>, <lj-cut> и т.п.
И ещё хочется заменить B, I, U на обычные <b>, <i>, <u>, вместо <span>‘ов с дополнительными опциями, который там вставляются этими кнопками.

Example plugin сам по себе работает, но позволяет вставлять или изменять только текст, а если попробовать в плагине добавить туда тэги, они убиваются нафиг.

А описания внутренних функций tinymce, которые используются в плагинах, я в оригинальной документации вовсе не вижу.
Вот список команд нашёлся, а описания их параметров вовсе нету.

Гуглить тоже пробовал, но ничего толком не нашёл.

Оригинал этой записи в личном блоге.

dil: (Default)
Thursday, September 3rd, 2015 03:07 pm

Когда не хочется заморачиваться загрузкой файла, ибо на серверной стороне из него нужна одна строчка, и вдобавок пользователь может захотеть эту строчку вписать копипастой, потому что у него в локальных файлах её вообще нет, она где-нибудь на другой машине хранится..
Конкретный пример – загрузка публичного ключа от ssh.

Делаем так: в основной форме для этой строчки используем обычный input типа text, который можно заполнить руками. А чтобы прочитать в него строчку из файлика, встраиваем рядышком (или даже прямо внутрь основной формы) дополнительную форму с input типа file и обработчиком на JS, который читает файлик сразу после его выбора в браузере и засовывает нужный контент в поле основной формы:

Read the rest of this entry » )

Оригинал этой записи в личном блоге.

dil: (Default)
Monday, March 17th, 2014 08:43 am

В продолжение https://dil.dreamwidth.org/1301956.html я наваял страничку с тем тестом: https://dil.pp.ru/drug-test.html

Чистый javascript, у меня в FF работает, в других браузерах не проверял за отсутсвием оных. Если найдёте ошибки, сообщайте.

Оригинал этой записи в личном блоге.

dil: (Default)
Wednesday, August 28th, 2013 09:24 am

То ли там какой-то хитрый reverse proxy, который фильтрует по странам, то ли оно закэшировалось в нашей корпоративной проксе, но у меня этот сайт до сих пор выглядит вот так:

Оригинал этой записи в личном блоге.

dil: (Default)
Wednesday, June 5th, 2013 10:21 pm

А что, такая конструкция действительно работает?

<!--[if !IE]><body><![endif]-->
<!--[if IE 9]><body class="ie9"><![endif]-->
<!--[if IE 8]><body class="ie8"><![endif]-->
<!--[if IE 7]><body class="ie7"><![endif]-->
<!--[if lt IE 7]><body><![endif]-->

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

Оригинал этой записи в личном блоге.

dil: (Default)
Thursday, December 29th, 2011 12:25 am

Написал простенькую искалку по мак-адресам.
coffer.com был хорош, но очень давно не обновлял базу, я неоднократно натыкался на адреса, которых он не знает.

Если кто заметит ошибки, или, может, какую дополнительную функциональность захочет, типа списков префиксов по организациям или организаций по странам, или, например, ссылки на поиск в Гугле названия компании, как на coffer.com, пишите свои пожелания.

Оригинал этой записи в личном блоге.

dil: (Default)
Wednesday, July 20th, 2011 12:22 pm

выношу из комментов обсуждения у Арканоида своё резюме:

на сайте Мегафона сложилась комбинация нескольких факторов, которые _совместно_ привели к утечке конфиденциальной информации. Каждый отдельный фактор существовал (или, по крайней мере, мог существовать) гораздо дольше, но в отсутствие остальных не приводил к фатальным последствиям.

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

Итак:
1. Существование страниц статуса отправки SMS, содержащих тексты и номера телефонов, с уникальными адресами.
2. Возможность неавторизованного доступа к этим страницам.
3. Утечка адресов этих страниц в поисковые системы.
4. Отсутствие запрета на индексирование этих страниц.

При этом обвинять поисковые системы в том, что они сделали публично доступной информацию, которая и так была публично доступна — значит выставлять себя идиотами.

Под катом, если кому интересно, мысли о том, как этого можно было бы избежать.

Read the rest of this entry » )

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

dil: (Default)
Tuesday, July 19th, 2011 07:13 am

Это мог написать кто угодно, не всем же разбираться в тонкостях работы веба. Но написал _веб-разработчик_. Якобы. С PHP вместо головы. А потом мы удивляемся, откуда берутся ТАКИЕ сайты.

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

dil: (Default)
Tuesday, July 5th, 2011 10:13 pm

Большинство веб-разработчиков знают Правило Правой Руки для HTTP: если запрос меняет состояние сервера, его надо отправлять методом POST, если не меняет — можно использовать GET.

Веб-форма при отправке на сервер меняла его состояние, поэтому разработчки совершенно справедливо указали method=”POST”.

Но если обработчик обнаружил ошибки, форму надо показать снова. И признак хорошего тона — не заставлять пользователя при этом вбивать всё заново, а подставить ранее введённые им значения и показать пальцем, в каких полях ошибки. Разработчики так и сделали. Но форму у них обрабатывает один скрипт, а показывает другой, поэтому при обнаружении ошибок возврат к странице с формой делается редиректом. А POST при этом, как известно, не работает, поэтому умные разработчики передают все введённые параметры GET’ом. Попросту говоря, прямо в URL’е.

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

Казалось бы… если бы не одна мелочь: в форме передаются данные про кредитные карты. Номер, CVV, срок действия, держатель… Весь набор в одном флаконе. И, естественно, при последующей отправке формы весь этот набор оседает в логах веб-сервера в виде реферера. Хуже того, особо умные пользователи могут сохранить всю эту ссылку в закладках браузера. Чтоб не набивать потом данные лишний раз.

В общем, ситуация типа “да вы здесь все молодцы…” ©.

P.S. Если кто случайно не знает прописных истин: надо либо использовать для показа формы и её обработки один и тот же скрипт (тогда редирект не понадобится), либо, если уж по каким-то причинам скриптов два, хранить параметры в сессии на сервере, а клиенту передавать только её идентификатор, да и тот лучше не в URL’е, а в куке.

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

dil: (Default)
Monday, February 22nd, 2010 04:55 pm

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

Сегодня один товарищ в одном совершенно непрофильном сообществе задал интересный вопрос: как сделать, чтобы колёсико мышки осуществляло  на широком сайте _горизонтальный_ скроллинг?

Я немножко погуглил и сделал так. Может, это как-то проще делается?

На фотографии можно внимания не обращать, я взял первые попавшиеся.

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

dil: (Default)
Thursday, October 22nd, 2009 09:38 pm

радует очередным вопросом и ответами:

Как сделать так, чтобы один скрипт редиректил на другой с одновременным POST-запросом?

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

dil: (Default)
Thursday, September 24th, 2009 01:23 pm

Тут вот [ljuser]dinozavr[/ljuser] написал заметочку о потере культуры информационной безопасности. Общий смысл её в том, что все эти проблемы профессиональной деградации вызваны минимизацией расходов на оплату труда разработчиков и админов, и вследствие этого – качества работы.

С одной стороны да, “вы всегда получаете то, за что заплатили”. Меньше зарплата – меньше квалификация человека, который пойдёт за эту зарплату работать, ну и результат он, естественно, выдаст в соответствии со своей квалификацией.

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

Конечно, с быдлокодера, освоившего PHP/Java/C#/whatever по книжке “Нейрохирургия для чайников за 21 день”, или пионэра, первый раз поставившего линукс вчера вечером, спроса никакого.

Но в приличные компании таких не берут, там есть некоторый пороговый уровень интеллекта, который предполагает, что человек а) действительно разбирается в том, чем занимается и б) в некоторой степени разбирается в смежных областях. Веб-программист – в том, как работает HTTP, CSS и база данных, администратор веб-сервера – в том, как работает тот же PHP и C#, DBA – в том, чтО за данные напихали программисты в базу, и как они используются в приложениях, и т.п.

И вот тут в полный рост встаёт вопрос: будет ли человек эти свои знания использовать, глядя чуть шире, чем в спущенное ему менеджером задание? Сообщит ли разработчик менеджеру, что задание поставлено некорректно, потому что если копнуть чуть глубже, то окажется, что задача решается гораздо проще и эффективнее? Начнёт ли бить тревогу из-за того, что в используемом протоколе есть очевидные проблемы с безопасностью? Заметит ли, что вместе с выкладываемым кодом на сервер попадают лишние файлы – тот самый .svn/ – и проверит конфиг сервера?

Или будет делать ровно то, что ему сказали? Качественно, в соответствии со своими знаниями и компетенцией, но – совершенно не оглядываясь по сторонам, потому что “мне такого задания никто не давал, это не моё дело, оно ж и так работает, и вообще – пусть менеджер думает, он за это зарплату получает”. Менеджер-то да, получает, но он специалист по организации производства, а не по таким тонкостям. И в результате получится давно известная картина “К пуговицам претензии есть?”

Конечно, бывают компании с военной  дисциплиной. “Командир сказал, что бурундучок птичка, значит, бурундучок – птичка”, и нечего высовываться и считать, что ты умнее начальника. Вот дорастёшь до его поста – тогда будет считаться, что ты умный, а пока сиди молча и делай, что сказали.

Но таких компаний в области разработки относительно мало. А подход “моя хата с краю”  наблюдается всё больше и больше, даже у крутых профессионалов, получающих за свою работу очень немаленькие деньги. И это очень печально.

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

dil: (Default)
Wednesday, August 26th, 2009 09:19 am

Со вчерашнего дня народ угорает над политкорректным Макйрософтом, который в польской версии картинки зачем-то заменил голову негра на голову белого человека. Голову азиатского человека, что интересно, оставили.

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

Это ж не просто ужас, а УЖАС-УЖАС-УЖАС.

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

dil: (Default)
Friday, June 19th, 2009 08:31 am

Это для веб-девелоперов, остальным неинтересно будет.

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

Вот в файловой системе как – приложение, конечно, может и само проверять, надо ли позволять  текущему пользователю выполнять ту или иную операцию с файлом или директорией, но администратор системы дополнительно устанавливает права на чтение/запись/…, которые приложение обойти не может.

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

Вопрос: а что мешает веб-приложению, работающему в “режиме обычного пользователя” и в “режиме администратора сайта” подключаться к базе от имени разных пользователей, которым назначены разные привилегии – первому поменьше, второму побольше? Чтобы хакер, работающий с приложением в первом режиме, в принципе не имел возможности поменять “системные” данные.

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

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

P.S. Про Windows Integrated Authentication в IIS я в курсе, но у него область применения довольно узкая. Если его включить, то придётся всех пользователей заводить на уровне ОС. Для публичных веб-приложений с большим количеством пользователей это неприемлемо.

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

dil: (Default)
Monday, June 8th, 2009 10:54 am

Гугль опубликовал полезный инструмент для оценки и оптимизации скорости загрузки страниц: Page Speed.

Ставится как плагин к Firebug.

Будучи напущенным на ya.ru, сказал несколько интересных вещей:

  1. The following resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers. Specify an expiration at least one month in the future for resources that should be cached, and an expiration in the past for resources that should not be cached: http://ya.ru/logo.png
  2. The following domains only serve one resource each. If possible, avoid the extra DNS lookups by serving these resources from existing domains.
    img.yandex.net
    www.tns-counter.ru
    export.yandex.ru
    clck.yandex.ru
  3. (inline block #1) has 3 very inefficient and 4 inefficient rules of 26 total rules.
  4. (inline block #2) has 1 very inefficient and 0 inefficient rules of 5 total rules.

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

Про google.com он ничего такого, понятное дело, не сказал.

Оригинал этой записи в личном блоге.

dil: (Default)
Saturday, May 23rd, 2009 07:43 pm

А что, этот вот масон – хорошая штука? Стоит тратить время на изучение, или с тех пор прогрессивное человечество придумало что-нибудь принципиально лучшее в области фреймворков для веба на перле?

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

dil: (Default)
Monday, May 18th, 2009 04:14 pm

Вопрос к залу: есть ли в природе бесплатный флеш-плеер, наподобие imeem’овского, который можно приделывать к mp3-файлам, находящимся на моём собственном сайте?

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме