1. Главная
  2. vadbars@drupal.org

vadbars@drupal.org: Комментарии

Главные вкладки

10 апреля 2009 в 14:03

они теперь поддерживают русских.
Насколько я знаю, поддержка эта односторонняя - платить можно, получать нельзя. Боятся, видимо, что русская мафия будет отмывать деньги. Smile
Но агитацию за PayPal поддерживаю - система распространенная, к карте виза легко прикрепить, платежи проходят.

10 апреля 2009 в 11:14

Да, спасибо, я тоже заподозрил куки. Хостер молчит.
Пока решил проблему раскомментированием и установкой переменной $cookie_domain в settings.php.
И все же... "Ложки нашлись, но неприятный осадок остался" :). У других хостеров все ведь работало без изменений в settings.php. Следовательно, эта багофича зависит от настроек сервера, а не Drupal.

9 апреля 2009 в 15:52

Впервые ставлю сайт на хостинге Nic.ru.

Возникли какие-то непонятки с синонимами ("сайт.com" и "www.сайт.com"): если залогинился на сайт.com, то на www.сайт.com оказываюсь по-прежнему незалогинен. Или наоборот.

Проверяю на стандартной установке Drupal 6.10. Кеш браузеров очищен. В "Панели управления" хостера синонимы настроены.

Кто уже имел опыт настройки на этом хостинге, подскажите, где может быть проблема?

5 апреля 2009 в 17:42

Вы очень смутно описали проблему. Какой патч вы скопировали? Патч или новую версию модуля?
Телепатически могу предположить, что неверно заданы настройки файловой системы (/admin/settings/file-system).

Если картинки не показываются, посмотрите, какой путь к ним указан.

4 апреля 2009 в 14:25

Жаль, жаль... Хотя бы помечал "подозрительные" фрагменты.

Есть ведь модуль Coder. Сам не пользовал, но он вроде как отлавливает "некошерные" (не соотвествующие стандартам Drupal) куски кода? Или нет?

4 апреля 2009 в 13:26

Александр, возможна ли автоматизированная проверка кода модулей на соответствие описанным вами правилам безопасности?

Если да, насколько это трудно сделать? Может быть, кто-то возьмется за написание такого скрипта? Или уже что-то существует?

Код ядра Drupal достаточно вылизан на предмет безопасности, чего не скажешь про сторонние модули. Основные модули, конечно, периодически смотрит Security team, но не все же.
Если бы сделать скрипт (или он-лайн сервис), через который можно было бы прогнать новый модуль перед установкой - было бы здорово.

3 апреля 2009 в 11:05

Итак. Код, действительно, несколько обфусцирован. Но вполне читаем и даже можно понять в общих чертах, что он делает Smile

Хозяйке на заметку. В сети обнаружилось довольно много статей по расшифровке gzinflate(base64_decode('blabla')); и даже есть несколько сервисов. Мне помог вот этот. Вот исходники декодера.

3 апреля 2009 в 9:13

скрипт можно и не расшифровать на лету, хеш будут подсовывать с удаленного сайта.
Это я не понял. Скрипт лежит не на удаленном сайте, а у меня на сервере. Он что-то делает и хотелось бы знать, что именно.
Я запускал его на локальной машине, по логам вроде бы кто-то ломится слушать порты 443 и 80 и что-то делать с SSL. Но не уверен, что это именно этот скрипт.

25 февраля 2009 в 19:56

Я имел в виду вариант с отказом от субмодуля image_gallery и созданием галерей как видов (views), т.е. фактически специально отфильтрованных списков материалов типа image.