>Собственно по этой сессии мы и узнаём юзера, а благодаря таблице sessions не храним в куках пароль.
>Ведь сессию могут подменить.
Не важно, хранить ты в куке пароль или нет PHP все равно сопоставляет сессию с кукой (по дефолту PHPSESSID). Если ты смог узнать значение этой куки, ты можешь получить сессию тебе не принадлежащую.
Второй аспект наверное в бессмысленности записи данных сессии в базу без изменения механизма сессий.
Ну любой каприз за ваши деньги, это да. Но в данном топике речь немного о другом. Если автор и после моего поста хорошенько еще раз не подумает (или не приведет явную причину переезда) и найдет исполнителей под данную задачу, ну почему нет. Есть много разных вариантов бесполезной траты денег этот будет не лучше и не хуже.
В настоящее время как раз занят тем, что пишу независимый импорт/экспорт (точнее синхронизация) базы товаров в битрикс. Причина банальная — импорт/экспорт через XML работает в нем некорректно. Товары, которых нет в файле, но есть в базе, должны деактивироваться («Действия над элементами, которых нет в файле: деактивировать»). Но этого не происходит.
Импорт инфоблока через XML созданный в битриксе же не работает, пишет что указанный файл не в CommerceML формате. Не в том формате файл созданный самим же битриксом, каково.
Нельзя автоматически загружать сторонние каталоги. Нельзя их миксовать в один каталог и выводить на сайте. Нельзя указать цену зависящую от того, из какого стороннего каталога она была взята. И таких нельзя много. Про скорость работы история вообще отдельная. Обновление каталога через сам битрикс занимает 5-7 минут (банальный каталог в менее чем 2000 позиций). Поэтому пишу свой апдейтер, отрабатывает за 15-20 секунд.
С тем же успехом все это можно было написать и в MODx. Поэтому ни каких профитов от использования битрикса мы не получаем. Продажники от битрикса могут сколько угодно ездить по ушам о том, какая их система хорошая, но при работе с реальным магазином вылезает куча багов которые нужно долго и упорно руками пилить. Того же можно было бы добиться и от MODx, но в отличие от битрикса платить за него не пришлось бы и заводить его на специальном хостинговом тарифе тоже. MODx не самая быстрая система, но требований по ресурсам в нем явно меньше, чем для битрикса.
Поэтому переводить уже работающий проект на битрикс — лишняя трата денег. Подобное желания может возникнуть только у не технических специалистов (менеджер, директор) которые не щупали обе системы и не могут оценить требуемый уровень вложений в подобную авантюрную затею.
Вот кто может повлиять, те законы и соблюдают (собственно поэтому и выносят сервера в другие страны при наличие целевой аудитории в текущей стране). Формально интернет вообще ни под какую либо гос. юрисдикции не попадает. Но это не мешает закрывать сайты пачками в досудебном порядке.
В развитых странах расцениваться как дискриминация (ну разве кроме случаев когда должность — лицо компании и взаимодействует с клиентами). У нас этим не заморачиваются сами работники. Таскаться по судам ни кому не охота.
Да, полностью твоим. См. ссылку на оф. регистраторов ниже. И регистрация идет не «на reg.ru», а через. Домен официально регистрируется на клиента, оф. регистратор просто уполномочен вносить эти данные в реестр.
>Какой самый эффективный алгоритм добавления элемента в дерево
и
>Даже ради небольшого выигрыша в эффективности поиска готов жертвовать медленной инициализацией
Мне тут видится противоречие. Если важна скорость поиска, а скорость инициализации не так критична, то какая разница какой алгоритм добавления? Берите быстрый алгоритм на выборке, а не добавлении.
Если предполагаемая контора связана с вебом, самое разумное ссылкой. На личный сайт, мой.круг или какой другой ресурс. Лично я свои резюме рассылал именно так.
Да пожалуйста. Если честно, когда накидывал думал, что в этой теме, особенно учитывая, что ни кто тут не отписался, нужный порог не собрать. И очень удивился увидев статью уже через несколько часов.
Парсинг логов это не грязный хак, а нормальная сложившиеся практика. По одной простой причине: мы оперируем с двумя независимыми сущностными. Логом и самим сервером. В случае же модуля имеется ПО которое пристыковано к основному коду и еще вопрос, как влияет на стабильную работу последнего.
Дилема логи vs модуль обычно сама отпадает когда продакшен сервер падает на казалось бы ровном месте. Я не к тому, что post_action непременно вот так сразу и упадет, я просто поясняю, почему некоторые админы не использую в продакшене какие-то модули если вопрос можно решить другими методами.
Как «помнящий наше время» скажу, что не проблема. Берем и тащим в проект кучу «костыльного» кода и удорожаем проект на сапорте. Это не проблема, но платить-то кто за это будет? mapron правильно заметил, достаточно вынести вопрос экономической целесообразности такого леганси кода и ретивость заказчика либо убывает (если в реальность оно ему нафиг не нужно) либо он за это платит (если его целевая аудитория в этом реально нуждается).
>Собственно по этой сессии мы и узнаём юзера, а благодаря таблице sessions не храним в куках пароль.
>Ведь сессию могут подменить.
Не важно, хранить ты в куке пароль или нет PHP все равно сопоставляет сессию с кукой (по дефолту PHPSESSID). Если ты смог узнать значение этой куки, ты можешь получить сессию тебе не принадлежащую.
Второй аспект наверное в бессмысленности записи данных сессии в базу без изменения механизма сессий.