Программирование, т. 3

Ну когда у меня в проекте ролей было всего 2, то никаких проблем.

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

Ну когда у меня в проекте ролей было всего 2, то никаких проблем.

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

ну тогда придётся bre какой-то писать, который будет инкапсулировать в себе эту логику, но от ролей в контроллере ты никуда не денешься, ведь читать контекст запроса из сервисов или репозитория - это вообще бред

Посмотрел код 2роя, это блять филиал говнокод.ру, что за пиздец Кто в здравом уме делает статическую авторизацию? А если у тебя будет меняться стратегия авторизации или логика самой авторизации? Ты будешь сотню иф/элсе внутри своего Ауторизейшен лепить? И нахуя эти паленые if/else на каждый чих? Если не авторизирован ебани AuthorizationException, будь мужиком, блеать! И вообще, если у тебя авторизация отвечает за какую-то логику, то это треш и содомия, прямой путь в ад.

 

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

Там основная авторизация на стороне вордпресса. Моя авторизация по сути ждля большей безопасности и доступа к внутренней секции. В том классе очень много инкапсулированно, поэтому я решил вынести это в отдельный класс.

сотни if/else покрывают все возможные варианты.

Да я запутал лоику, и от того класса меня тошнит.

Но я его дописал. Он работает. Испытания прошел.

Все. Больше я его не трогаю. Забыл.

 

На счет второго можно подумать. Но уже поздно менять.

Ну когда у меня в проекте ролей было всего 2, то никаких проблем.

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

ну тогда придётся bre какой-то писать, который будет инкапсулировать в себе эту логику, но от ролей в контроллере ты никуда не денешься, ведь читать контекст запроса из сервисов или репозитория - это вообще бред

Как раз-таки не бред. Ты его один раз читаешь, кешируешь и каждый раз используешь. Если политика изменилась, то делаешь сброс кеша. А вот городить иф/элсе это пиздец полный. Особенно если у тебя динамические роли пользователей и ты можешь сам создавать собственные роли с определенным набором доступов и прав.

Как раз-таки не бред. Ты его один раз читаешь, кешируешь и каждый раз используешь. Если политика изменилась, то делаешь сброс кеша. А вот городить иф/элсе это пиздец полный. Особенно если у тебя динамические роли пользователей и ты можешь сам создавать собственные роли с определенным набором доступов и прав.

что значит кешируешь? стейтлес приложение ведь

Как раз-таки не бред. Ты его один раз читаешь, кешируешь и каждый раз используешь. Если политика изменилась, то делаешь сброс кеша. А вот городить иф/элсе это пиздец полный. Особенно если у тебя динамические роли пользователей и ты можешь сам создавать собственные роли с определенным набором доступов и прав.

что значит кешируешь? стейтлес приложение ведь

Приложение то пускай стейтлесс, но гранты то стейтфулл, или у тебя гранты у пользователей каждый раз вычисляются? В таком случае во всех нормальных системах используются лисенеры на какие-то кастомные вещи.

Приложение то пускай стейтлесс, но гранты то стейтфулл, или у тебя гранты у пользователей каждый раз вычисляются? В таком случае во всех нормальных системах используются лисенеры на какие-то кастомные вещи.

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

Щитать по кукам роль юзера, это не круто

Приложение то пускай стейтлесс, но гранты то стейтфулл, или у тебя гранты у пользователей каждый раз вычисляются? В таком случае во всех нормальных системах используются лисенеры на какие-то кастомные вещи.

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

По кукам роль? Ты чушь то не пори.

Приложение то пускай стейтлесс, но гранты то стейтфулл, или у тебя гранты у пользователей каждый раз вычисляются? В таком случае во всех нормальных системах используются лисенеры на какие-то кастомные вещи.

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

По кукам роль? Ты чушь то не пори.

а как еще ты определишь пользователя?

В сессии хранить идентификатор пользователя. Подменить SESSION_ID невозможно, он генерируется для конкретной сессии браузера, закрыл браузер, открыл, прошлая сессия протухнет по таймауту и ты уже к ней не вернешься, нужно заново логиниться. Вообще, что либо хранить в куках в корпоративном ПО, это полный провал. В тоже время пихать в сессию гранты пользователя тоже хреново, ибо она будет распухать для каждого пользователя.

В сессии хранить идентификатор пользователя. Подменить SESSION_ID невозможно, он генерируется для конкретной сессии браузера, закрыл браузер, открыл, прошлая сессия протухнет по таймауту и ты уже к ней не вернешься, нужно заново логиниться. Вообще, что либо хранить в куках в корпоративном ПО, это полный провал. В тоже время пихать в сессию гранты пользователя тоже хреново, ибо она будет распухать для каждого пользователя.

а как ты думаешь аппликейшн сервер определяет какой объект сессии загружать для конкретного запроса?

В сессии хранить идентификатор пользователя. Подменить SESSION_ID невозможно, он генерируется для конкретной сессии браузера, закрыл браузер, открыл, прошлая сессия протухнет по таймауту и ты уже к ней не вернешься, нужно заново логиниться. Вообще, что либо хранить в куках в корпоративном ПО, это полный провал. В тоже время пихать в сессию гранты пользователя тоже хреново, ибо она будет распухать для каждого пользователя.

а как ты думаешь аппликейшн сервер определяет какой объект сессии загружать для конкретного запроса?

на клиенте в виде куки сессии

в сессии хранить айди

из айди получать данные на юзера

 

 

3333 сообщение

грац меня

Изменено 19 февраля 2013 пользователем 2poy_nyasha

В сессии хранить идентификатор пользователя. Подменить SESSION_ID невозможно, он генерируется для конкретной сессии браузера, закрыл браузер, открыл, прошлая сессия протухнет по таймауту и ты уже к ней не вернешься, нужно заново логиниться. Вообще, что либо хранить в куках в корпоративном ПО, это полный провал. В тоже время пихать в сессию гранты пользователя тоже хреново, ибо она будет распухать для каждого пользователя.

а как ты думаешь аппликейшн сервер определяет какой объект сессии загружать для конкретного запроса?

Я не думаю, я знаю как он это делает, по крайней мере в JAVA. В любой момент времени ты можешь получить ссылку на текущую сессию, если сессии нет, то она автоматом создастся (есть исключительные случаи когда этого делать не надо), в сессии лежит мапа параметров, необходимое условие чтобы все объекты которые в ней лежат были сериализуемые. Таким образом все что тебе нужно сделать после логина пользователя на сайте, взять сессию (если её не было, автоматом создастся) и положить под каким-то ключом пользователя в неё как объект. Если пользователь закроет браузер и заново откроет, сессия будет потеряна, нужно заново логиниться, если же нажмет кнопку логаут, можно принудительно завершить и очистить сессию. В пхп очень похожий механизм, но только сессии в пхп, это файлики на диске, он не умеет ин мемори хранить, так что надо быть осторожнее чтобы не спиздили (на говнохостингах они обычно на уровень выше апликейшена лежат чтобы криворукие уёбки не просрали все на свете).

Я не думаю, я знаю как он это делает, по крайней мере в JAVA. В любой момент времени ты можешь получить ссылку на текущую сессию, если сессии нет, то она автоматом создастся (есть исключительные случаи когда этого делать не надо), в сессии лежит мапа параметров, необходимое условие чтобы все объекты которые в ней лежат были сериализуемые. Таким образом все что тебе нужно сделать после логина пользователя на сайте, взять сессию (если её не было, автоматом создастся) и положить под каким-то ключом пользователя в неё как объект. Если пользователь закроет браузер и заново откроет, сессия будет потеряна, нужно заново логиниться, если же нажмет кнопку логаут, можно принудительно завершить и очистить сессию. В пхп очень похожий механизм, но только сессии в пхп, это файлики на диске, он не умеет ин мемори хранить, так что надо быть осторожнее чтобы не спиздили (на говнохостингах они обычно на уровень выше апликейшена лежат чтобы криворукие уёбки не просрали все на свете).

ну ты так и не ответил как аппликейшн сервер определяет какой инстанс сессии разворачивать для конкретного запроса

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

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

ну я в общем-то это и хотел услышать от димана тим менеджера.

ид сессии хранится в куке. Ну и использовать сессию считается плохим тоном

Хочу попробывать попитонить. С чего начать?

Хочу попробывать попитонить. С чего начать?

с погружения в питон офк

 

Я не думаю, я знаю как он это делает, по крайней мере в JAVA. В любой момент времени ты можешь получить ссылку на текущую сессию, если сессии нет, то она автоматом создастся (есть исключительные случаи когда этого делать не надо), в сессии лежит мапа параметров, необходимое условие чтобы все объекты которые в ней лежат были сериализуемые. Таким образом все что тебе нужно сделать после логина пользователя на сайте, взять сессию (если её не было, автоматом создастся) и положить под каким-то ключом пользователя в неё как объект. Если пользователь закроет браузер и заново откроет, сессия будет потеряна, нужно заново логиниться, если же нажмет кнопку логаут, можно принудительно завершить и очистить сессию. В пхп очень похожий механизм, но только сессии в пхп, это файлики на диске, он не умеет ин мемори хранить, так что надо быть осторожнее чтобы не спиздили (на говнохостингах они обычно на уровень выше апликейшена лежат чтобы криворукие уёбки не просрали все на свете).

ну ты так и не ответил как аппликейшн сервер определяет какой инстанс сессии разворачивать для конкретного запроса

В кукисах хранится SESSIONID, но ты зная его, ничего не сможешь вытащить с сервера и каждый раз при закрытии/открытии браузера он будет новый генерироваться.

 

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

Что ты блять за хуйню написал? Хранится ссылка на серверную сессию для конкретной сессии браузера.

Изменено 19 февраля 2013 пользователем DIMAN123456789