за исключением того, что токен могут увести.Еще раз - ВСЕ могут увести, все к чему может дотянуться яваскрипт (а он может дотянуться практически до всего что можно отправить в качестве ключа серверу) может быть скомпрометировано на стороне клиента. Это не ваша проблема, и это не проблема сервиса, по крайней мере если сервис обезопасил приложение от внешних вредоносных скриптов ЧЕРЕЗ САЙТ. Ничего не гарантирует защиты пользователя от действия третьих лиц, например левых плагинов в браузере, вирусов, подсмотренных паролей в браузере, просто тупо бумажки с логином и паролем на столе... Но все это не проблемы безопасности сервиса, это персональная защита данных, которую должен обеспечить пользователь самостоятельно. Все проблемы которые вы себе придумали (и в частности короткие сессии, которые кроме того что регулируются программно, еще и могут быть дублированы каким-то ключом в куках, как сделано на многих сайтах, где есть галочка "запомнить меня") в основном к вам как к разработчику никак не относятся.
Вывод только в каталоге (отслеживание по контролеру)
<?php if(MG::get('controller')=="controllers_catalog"): ?>
Этот текст будет выводиться на всех страницах каталога
<?php endif; ?>
подумайте, почему энтерпрайз до сих пор хардкодит в БД?По тому что это в большинстве случаев не так? Я как бы работал с несколькими конторами, поддерживающими весьма крупные проекты, в том числе на оракле + ява, и на С++ + МССкуль, никто уже давно не хранит код в процедурах. Во первых неудобно, во вторых сейчас многие системы имеют не одно хранилище, что делает размазывание кода еще больше при хранении кода в бд. Пару хранимок вполне нормально, там где критично быстродействие. Остальное в коде.
есть приложения которые ПОЛНОСТЬЮ находятся в БД, а клиентское приложение наподобие браузера (тонкий клиент) в нем вообще никакой логики нет, кроме как XML в UI переводить.Есть, и тут имеет смысл хранить все в одном месте. Как бы логично. Но опять же, это не тот случай что у ТС.
код пишут программисты БД и они вовсе не DBAКак ни странно, обычно это именно одно и то же, хотя конечно есть чисто программисты SQL, но в большинстве случаев все они стараются получить и ДБА сертификат. На моей памяти чисто прогеров эскуеля я не встречал, возможно это чисто местная специфика.
почему-то после удаления user_id из бдээ, зачем? Просто можно было поставить его необязательным.
скажите что в этих глобалах такого?Ничего в них, просто чистая/хорошая функция должна выдавать всегда одинаковый результат при любых входных параметрах, а когда она использует кучу глобальных переменных результат слабо предсказуем. Вроде я сказал что читать по этому поводу.
И какую проверку сделать формам и как правильно?Валидация в php тема обширная, есть как нативные средства, так и более навороченные библиотеки.
если так и оставлять дальше, что будет?Ничего не будет, прост со временем будет все сложнее все это обслуживать. Технический долг, легаси и вот это все...
но id все равно не записывает никак,Так он туда не попадает, вам же уже объяснили, переменная $id НЕ ВИДНА ВНУТРИ ФУНКЦИИ. Если хотите чтобы она была видна - либо до использования добавьте ее в $this->id например, или же передайте ее в аргумент функции.
Опыт же приходит на основе проб и ошибок. Вы все делаете правильно?Нет конечно, просто подозреваю что у меня опыта немного больше, по этому с моей точки зрения ваше решение выглядит как плохо проанализированное, с замахом на оптимизацию и так хорошо работающего кода.
Как по-Вашему сделать анализ если нет результата?Анализ он не всегда на основе результата, иногда просто логически надо подойти. Например подумать, "а как вася будет распоряжаться данными на локальной машине?" Основной принцип разработки в модели взаимодействия с клиентом - клиент всегда хитрая жопа, ищущая как вас... обмануть. И код соответственно пишется исходя из этого подхода.