Сообщений в теме: 19

[SoVA]

Доброе время суток всем.

Сегодня внезапно ShopCMS 3.1.2 vip отказала в авторизации. Еще позавчера вечером ковырялся в админке, вчера весь день не подходил к сайту и компам вообще, и сегодня с утра он отказывается пускать меня в админку и через admin.php, и через общую форму авторизации. В хроме просто тишина - перезагружается главная страница и все, ослик при попытке авторизоваться на главной странице тоже никуда дальше не переходит, оставаясь на главной, но выдает ошибку:
Line: 21
Char: 2
Error: Object doesn't support this property or method
Code: 0
URL: http://www.greenfish...ser_details=yes

Ту же ошибку, кстати, выдает уже просто при загрузке главной.

Почистил кэш на сайте через FTP, обновил клиентскую часть в браузере - всё ровно, на своих местах, не видно, чтоб кто-то похакал, да и пароль такой, что с полпинка не подберешь. Полез в phpMyadmin - пользователь root присутствует, пароль в MD5 имеется (хотя на глаз определить не смогу - тот же или нет, а предварительно его прям в виде MD5 никуда не бэкапил). Попробовал создать нового юзера с админскими правами прямо через phpMyadmin, но мне отказали в такой шалости.
Ладно, связался с пользователем-покупателем, попросил его авторизоваться - его тоже ShopCMS в аккаунт не пустила. Таблица с пользователями в БД присутствует, товары на страницах отображаются, дополнительные созданные вручную страницы грузятся, новотси отображаются - т.е. связь с БД в порядке. А авторизация нихт арбайтен. Выходит, что-то именно с авторизацией? Что могло случиться, если еще позавчера все работало, при этом рабочие файлы, шаблоны уже довольно давно не менялись?
При этом в субдомене 3 уровня на этом же сайте есть еще небольшой сайтик для общения - там авторизация в порядке.

Что делать, кто может подсказать?

[R.Sergey]

1. Пароль не шифруется в МД5 в ShopCMS, если конечно Вы это не переделывали.
2.

Попробовал создать нового юзера с админскими правами прямо через phpMyadmin, но мне отказали в такой шалости.

Кто и каким это образом? если есть доступ к phpmyadmin то запретить добавить сроку в таблицу просто невозможно.

[SoVA]

1. Пароль не шифруется в МД5 в ShopCMS, если конечно Вы это не переделывали.

Ну, он там хранится явно в зашифрованном виде, я по аналогии с InstantCMS подумал, что это MD5. Перемудрил, выходит.
Не переделывал, ибо руки коротки у меня для этого.

2.

Попробовал создать нового юзера с админскими правами прямо через phpMyadmin, но мне отказали в такой шалости.

Кто и каким это образом? если есть доступ к phpmyadmin то запретить добавить сроку в таблицу просто невозможно.

Я сам удивился. Опять же, в Instant CMS такой фокус в свое время сработал. А здесь - отказ. Может, конечно, что не так задал в форме - юзера создавал не запросом вручную, а через форму phpmyadmin, все параметры задавал по аналогии пользователя root.
Вот что получил на выходе:

Ошибка
SQL-запрос: 

INSERT INTO  `greenfish_su`.`yyvu_customers` (

`customerID` ,
`Login` ,
`cust_password` ,
`Email` ,
`first_name` ,
`last_name` ,
`subscribed4news` ,
`custgroupID` ,
`addressID` ,
`reg_datetime` ,
`ActivationCode` ,
`CID` ,
`affiliateID` ,
`affiliateEmailOrders` ,
`affiliateEmailPayments` ,
`actions`
)
VALUES (
'135',  'admin',  'bc6853d7d174532ac6aca2191ffa8b0c',  'sova-2002@mail.ru',  'Владимир',  'Соловей',  '1',  '1',  '1',  '2013-06-26 10:25:01',  '',  '3',  '0',  '1',  '1', 'a:35:{i:0;s:1:"1";i:1;s:1:"2";i:2;s:1:"3";i:3;s:1:"4";i:4;s:1:"5";i:5;s:1:"6";i:6;s:1:"7";i:7;s:1:"8";i:8;s:1:"9";i:9;s:2:"10";i:10;s:2:"11";i:11;s:2:"12";i:12;s:2:"13";i:13;s:2:"14";i:14;s:2:"15";i:15;s:2:"16";i:16;s:2:"17";i:17;s:2:"18";i:18;s:2:"19";i:19;s:2:"20";i:20;s:2:"21";i:21;s:2:"22";i:22;s:2:"23";i:23;s:2:"24";i:24;s:2:"25";i:25;s:2:"26";i:26;s:2:"27";i:27;s:2:"28";i:28;s:2:"29";i:29;s:2:"30";i:30;s:2:"31";i:31;s:2:"32";i:32;s:2:"33";i:33;s:2:"34";i:34;s:3:"100";}'
), (
NULL ,  '',  '',  '',  '',  '',  '',  '',  '',  '',  '',  '',  '',  '1',  '1',  ''
)
Ответ MySQL: 

#1142 - INSERT command denied to user 'h_greenfish_su'@'localhost' for table 'yyvu_customers' 

[R.Sergey]

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

[SoVA]

Я заранее прошу прощения, но я не особо разбираюсь в БД, SQL, и в, частности, в управлении через phpmyadmin. Но мне при регистрации домена хост-провайдер nsr.ru предоставил логин-пароль для доступа к БД, и это именно пользователь h_greenfish_su, эти же данные я вводил и при установке ShopCMS на хостинг. То есть я банально не имею представления, как еще я могу подключиться к БД моей CMS.
Сама панель управления phpmyadmin у прова находится по адресу https://myadmin.hgc.nsr.ru/ и войти я могу только по этому логину.

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

А, в сущности, хоть бы я и добавлю нового пользователя через phpmyadmin - что мне это даст, если CMS никого в себя не пускает?

Насколько я понимаю, саппорт провайдера по этой проблеме теребить вообще бессмысленно? С их стороны ведь все в порядке, база цела.

[R.Sergey]

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

[eugene_wb]

Насколько я понимаю, саппорт провайдера по этой проблеме теребить вообще бессмысленно? С их стороны ведь все в порядке, база цела.

наоборот нужно теребить суппорт, так как возможных причин вероятнее всего 2
1) неправильное время на сервере, и из-за этого не работает привязка сесий по времени
2) неправильно работает механизм сессий

обе проблемы относятся к провайдеру

UPD совсем забыл, может быть неправильное время на компе, из-за этого тоже может не работать

[SoVA]

Ок, напишу в саппорт.

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

[R.Sergey]

А и еще неправильные команды в htaccess - совсем недавно столкнулся с подобной фигней.

[SoVA]

Получил ответ от саппорта:

Здравствуйте, Владимир,

Возможно, это из-за превышения дисковой квоты:

Maximum: 314572800 bytes (300.0 MB)
DB: 140640256 bytes (134.125 MB)
FTP: 440713216 bytes (420.296875 MB)
Mail boxes: 0 bytes (0.0 MB)
Total: 581353472 bytes (554.421875 MB)

Если на сервере есть ненужные файлы (накопились бэкапы, например)
почистите. Или попробуйте изменить тарифный план:

1. http://www.nameserve...omains/MainMenu
2. По ссылке "Изменение тарифного плана"

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

Полез в папку /core/backup - там 303 файла, каждый объемом около 1 Мб (в распакованном виде - 5,5 Мб), из них 6 датированы 20, 21, ... 25 июня, а оставшиеся 297 - за 26 июня, начиная с 05:00 и до текущего момента с интервалом в 2-5 минут.
Понятно, что загадило такой объем, непонятно - почему. А еще, правда не совсем понятно, как это может повлиять на авторизацию - разве что сервер не дает CMS писать лог, и из-за этого авторизация сбивается?

Насколько понимаю, я могу безболезненно прибить все, кроме последнего, ну и, может, еще того, что на 24.06?
Но остается вопрос: откуда столько дампов базы, с чего вдруг ShopCMS надумала так обильно скидывать бэкапы?

Кстати, где ShopCMS хранит логи? Неужто только в БД, должны же быть файлы с логами? В папках ничего особо похожего не нашел, поиск в нете тоже ничего не дал.

P.S. htaccess уже довольно давно вообще не трогал - последний раз только менял путь для 404, но это было с месяц назад, и после того все продолжало работать.

[eugene_wb]

Понятно, что загадило такой объем, непонятно - почему

потому что на хостинге неправильно ( или вобще не ) настроена ротация логов и архивов

А еще, правда не совсем понятно, как это может повлиять на авторизацию

потому что видимо сессии хранятся в фаловом варианте и соответсвенно при переполнении дисковой квоты записатся не могут, и опять же это минус хостингу, так как намного выгоднее хранить сессии в memcached

Кстати, где ShopCMS хранит логи? Неужто только в БД

движок хранит логи только в БД, остальные логи сервера в зависимости от настроек хостинга

[R.Sergey]

SoVA, так проблема этим решилась?

[SoVA]

R.Sergey, я пока не проверял - пришлось отвлечься на другие рабочие вопросы. Сейчас полезу, зачищу лишнее - отпишусь. Самому интересно, но вероятно, вопрос решится.
А почему объем БД по данным хостера DB: 140640256 bytes (134.125 MB), а дамп весит всего 5,5 Мб?

eugene_wb, спасибо!

Так а куда теперь копать с этими стихийно размножающимися дампами? С чего вдруг они стали плодиться с такой частотой? Отключить совсем бэкап в админке?

[R.Sergey]

А почему объем БД по данным хостера DB: 140640256 bytes (134.125 MB), а дамп весит всего 5,5 Мб?

Ого...... 134 метра база.

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

[badisoft]

потому что на хостинге неправильно ( или вобще не ) настроена ротация логов и архивов

Это ж не хостинговый архив, а "встроенный" в ShopCMS. Который - если включен - то при каждой загрузке страницы (шедулера-то нет!) проверяет, не прошли ли сутки с предыдущего бэкапа. И если прошли, то делает очередной бэкап.
core/includes/check.php

  $result = db_query( "select last_update from ".DUMP_TABLE." where type=1" );
  $results = db_fetch_row($result);
  $last_update = $results["last_update"];
  if ((time()-$last_update) > ($interval_update*3600))
  {
  $querys = "update ".DUMP_TABLE." set last_update = '".time()."' where type=1";
......

думаю, при определенном стечении обстоятельств между запросом select и сменой даты по update можно словить весьма не один заход на сайт. И на каждый заход будет делаться бэкап.

Отключить совсем бэкап в админке?

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

[SoVA]

Не сработал фокус
Удалил все дампы, кроме тех, что до 25 июня (на всякий случай). Почистил кэш в браузере и даже на всякий случай на сайте - результат прежний.
Написал саппорту, вот очередной ответ:

Сейчас уже лучше, но на пределе:

Maximum: 314572800 bytes (300.0 MB)
DB: 140640256 bytes (134.125 MB)
FTP: 168120320 bytes (160.33203125 MB)
Mail boxes: 0 bytes (0.0 MB)
Total: 308760576 bytes (294.45703125 MB)

Может, следующий тарифный план? Или сразу восстанавливать?

R.Sergey,
Вот и я думаю - что там такого может быть. Спросил вот у саппорта - что там такого.
Ну, правда, в этой же БД хранятся еще и данные InstantCMS, что крутится на субдомене, но там не так много инфы, и сайт тот почти пустой.

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

[R.Sergey]

Может, следующий тарифный план? Или сразу восстанавливать?

))))))))))))) может это Вас хостер разводит на больший тариф )))))))))

[SoVA]

badisoft, ок, спасибо, выключу.

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

R.Sergey, меня тоже насторожило настойчиво повторяющееся предложение повысить тариф

R.Sergey, кстати, если интересно, могу дать в личку ключи к phpmyadmin - посмотреть, что там в базе такого.
Это, конечно, легкомысленно - делиться ключами к БД, но администратору vsupport я доверяю, вряд ли Вам удастся сделать что-то хуже, чем мне

[R.Sergey]

Мне кажется мне доступ Вы уже давали когда-то что-то делал Вам.
Да что мне там смотреть собственно?!?!... я не думаю что это из-за размера БД. Может у них просто счетчик глючит.

[SoVA]

R.Sergey, да смотреть особо нечего, на всякий случай предложил - вдруг исследовательский интерес
В общем-то, я сам уже взглянул на БД получше и нашел таблицу со спамом на 110 Мб
Почистил ее, поудалял еще ненужных картинок, места свободного заметно прибавилось, но авторизация по-прежнему не проходит.
Снова написал в суп.
Вечерело...

Все, заработало.
Хотя саппорт отвалился на отметке 13:54 и больше не отозвался.
Непосредственно после чистки свободного места ожидаемой реакции не было, но вот сейчас все работает.