newt

Сессия - это Кука с именем PHPSESSID (по умолчанию, его можно изменить) и значением вида 8jae35cosacp2f5qv6g2uqe6i7. Все данные сессии (массив $_SESSION) хранятся на стороне сервера в файле с именем 8jae35cosacp2f5qv6g2uqe6i7 в формате JSON (можно хранить и в БД).
То есть, вам надо не дописывать 1, а угадывать это имя, что нереально.

У Куки можно установить флаг HttpOnly - такие Куки не видны браузерному коду (яваскрипту), а только отправляются на сервер. Внедрённый на страницу вряжеский яваскрипт не сможет получить доступ к такой Куке.

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

- установить заголовок HSTS, это заставит браузер работать только по HTTPS, те Кука будет зашифрована при передаче по сети.

- в самой сессии можно хранить IP адрес(привязка сессии к IP). Тогда даже с правильной Кукой не залогиниться, поскольку не совпадет IP (который хранится в $_SESSION на стороне сервера). Неудобно если провайдер меняет IP при каждом переподключении.

- можно в сессии хранить User Agent (все равно Кука - она только для этого браузера). Но при автоматическим апдейте браузера придётся авторизоваться заново, и у кого хватило ума перехватить Куку - перехватит и имя User Agent-а.

- можно в сессии хранить fingerprint браузера (или даже всего компа), только надо придумать как безопасно передавать его на сервер, чтобы сохранять в сессии (и для сравнения при авторизации). Его же тоже могут перехватить.

- при каждой авторизации по Куке, и через каждые ## секунд можно(и нужно) делать session_regenerate_id (меняется 8jae35cosacp2f5qv6g2uqe6i7 на другое), там по ссылке есть пример как это сделать прямо внутри сессии. То есть, угнанная Кука быстро перестаёт работать.

- можно делать "сессионную" Куку (не указывать её время жизни). Такая Кука живёт до закрытия браузера, но после закрытия браузера придётся заново вводить логин/пароль

Можно добавить своей безопасности - например отправлять email пользователю при каждой авторизации по Куке, если не было активности Пользователя более 12 часов.

PS: Если пользоваться сессиями правильно - они достаточно безопасны, практически вся авторизация в интернетах построена на них.

1. Yii мёртв. Устарел лет на 10 по подходам и кодовой базе, и не развивается.
2. Плохой дизайн. Глобальное состояние для всего, наследование от базового класса модели, валидация через массивы там же, наследование для расширения всего и вся и прочая чушь. Отсутствие многих удобных фич типа нормального DI/аргумент резолверов, чего только стоит гибкость конфигурации сервисов в Симфе.
3. Свои велосипеды вместо чего-нибудь готового
4. Все компоненты прибиты гвоздями и не заменяются своими. Это делает код на нём нерасширяемым и нетестируемым(Ну то есть в теории переписав пол фреймворка и 100500 своих адаптеров можно писать нормально, но те кто хочет писать нормально просто уходят с Yii).
5. Слабое комьюнити которое сидит на нём потому что не осилило ничего другого / генерирует CRUD`ы через Gii(Заменить бы их уже не postgrest и прочие обёртки над базой) / инертные кодеры которым без разницы чего делать лишь бы на хлеб хватало.
6. Все фреймворки далеки(очень) от идеала, но Yii сильно отстаёт от прочих.

Сделайте общий метод getUsersQuery(), который просто возвращает пользователей без какой либо сортировки. Свой метод getUsers() измените так, что бы он использовал первый метод. Плюс, добавьте метод getUsersSorted(), где будете возвращать данные, отсортированные в нужном виде. Не зная структуры проекта сложно написать какие то примеры кода, но я бы сделал примерно так:

function getUsersQuery() {
    // ...
}
function getUsers() {
    return getUsersQuery()->orderBy('id');
}
function getUsersSorted() {
    return getUsersQuery()->orderBy('name');
}

На самом деле, такая оптимизация не будет иметь смысла - если мы между контроллером и вью добавим слой, который будет преобразовывать объект, с которым работал контроллер, в массив, с которым будет работать вью, это только ухудшит производительность. Для оптимизации нужно будет вообще отказаться от объектов и работать только с массивами. И этот шаг ни в коем случае нельзя делать, пока вы не будете на 146% уверены, что он необходим.

Вдобавок, такая "оптимизация" может даже ухудшить дело, потому что не получится реализовать ленивый подсчет данных. Простой пример - если заказ не подтвержден, то не нужно выводить сумму его товаров, а если подтвержден - нужно. Представим, что сумма нигде не хранится и считается на лету из товаров в корзине заказа. При использовании объекта, подсчет суммы не выполнялся бы вообще для неподтвержденных заказов, потому что метод getTotal() не будет вызван в шаблоне. А при конвертации в массив нужно будет высчитывать всё, ведь неизвестно, что пригодится в шаблоне, а что - нет.

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

Так я и подумал, может стоит сразу приучать вьюхи использовать только ассоц. массивы?

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

А так вьюха навязывает логику контроллерам и моделям, что та или другая переменная должна быть именно объектом.

Наоборот, это контроллеры отдают данные и по определению именно они навязывают шаблону логику его работы. И это нормально.

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

Да, можно во все классы запилить поддержку ArrayAccess, но какой в этом смысл? Если вью будет работать с объектом, то это только трата времени. Если вью будет работать с массивом, то ArrayAccess тут ничем не поможет - никакого объекта уже нет. Я не вижу смысла делать такой hot swap.

Это как делать framework-агностик приложение, чтобы в любой момент можно было заменить Симфони на Ларавел - идея прикольная и дизайн в итоге, возможно, будет лучше (но далеко не факт, потому что такое усложнение может сделать всё только хуже), но на практике такие переезды происходят очень редко и даже когда происходят, безболезненно они не проходят.

Гораздо эффективнее сделать минимально необходимый дизайн, а потом, если уж припрет, потратить дополнительное время на перенос. По большому счету, то, что вы предлагаете, это Big Upfront Design и я не сторонник такого подхода. Лучше вносить изменения итеративно, исходя из текущих потребностей бизнеса, оплачивающего работу, и не заглядывать далеко в будущее. Есть ненулевая вероятность, что пока вы будете имплементировать в классах ArrayAccessable Interface, заказчик разорится и ваш красивый, расширяемый, поддерживаемый код окажется никому не нужным.

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

P.S. Я это всё написал как альтернативную точку зрения для всех, кто будет читать этот вопрос впоследствии. Используйте whatever floats your boat, как говорится, в вопросах архитектуры нет серебряной пули.

эйфория от новых возможностей прошла и вскрылись недостатки, на мой взгляд основные их них:
— Слабая производительность на 1-серверной БД. Особенно заметно на map-reduce по данным, которые полностью влезли в память.
— Особенности документо-ориентированной структуры. Многие переходили с табличных БД и тут понеслась: сначала радость, что не надо возиться со структурой, а потом расплата — в одной коллекции куча разных объектов и приложение регулярно читает из вроде бы известной коллекции что-то для себя неожиданное (очень старые объекты, некорректно измененные и т.п.).
— Целостность данных. Кто-то привык, что БД контролирует этот вопрос, вешают констрейнты и ловят ошибки в логе в случае какой промашки по части бизнес-логики. Монга же ничего такого сама не контролирует, ну и получаются внутри БД ссылки на объекты, которых нет.
— Отсутствие полноценных транзакций. Те, кто бросились все хранить в монге с ужасом поняли, что для биллинга нужно что-то другое. (должен оговориться, что не все пока поняли)

По моему мнению отказаться от классической реляционной БД в пользу монги может позволить далеко не каждый проект. Если перетаскивать какой-нибудь небольшой интернет-магазин, то с бОльшей вероятностью это принесет боль и страдание нежели ожидаемый профит. Эффективным решением будет параллельное использование монги и реляционной БД, но чтобы это имело смысл — проект должен быть соответствующих размеров. Для небольшого проекта городить такой огород контрпродуктивно.

PS Мое мнение основано на годичном опыте неплотной работы с монгой, опыт работы с реляционными БД — примерно 10 лет.