и последняя кратная 10 позиция и есть айдишка последнего

гениально )

@miksir спасибо

ну ты можешь целенаправленно получать на сервере 21 товар... отдавать клиенту 20 и флаг последней страницы (если у тебя не получилось получить на сервере 21 товар, а только 20 или меньше - страница последняя)

еще такой момент. с последней страницы. 21 товар с ценами имеется ввиду ?

если есть 21 а не 20 значит есть и следующая страница, показываете только 20

ну ты можешь целенаправленно получать на сервере 21 товар... отдавать клиенту 20 и флаг последней страницы (если у тебя не получилось получить на сервере 21 товар, а только 20 или меньше - страница последняя)

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

Всем привет! Компания ManyChat приглашает на Meetup "Performance talks", который состоится 12 июля в 18:30. Темой встречи станет производительность бекенда. Мероприятие бесплатное, проходит в Москве. Подробности и форму регистрации легко найти по ссылке: https://manychat.timepad.ru/event/1014343/ Приходите, будем очень рады?

Всем привет! Компания ManyChat приглашает на Meetup "Performance talks", который состоится 12 июля в 18:30. Темой встречи станет производительность бекенда. Мероприятие бесплатное, проходит в Москве. Подробности и форму регистрации легко найти по ссылке: https://manychat.timepad.ru/event/1014343/ Приходите, будем очень рады?

manychot?

Mnepechot

?

Как думаете Intel Core i7-6700 не слабоват для сервера: память 64 GB диск 2x 512GB NVMe SSD сеть 1 Gbps 30TB ?

Хвастаешься?

Хвастаешься?

+

не, подешевке сервер предлагают )

а мне как раз надо много ssd и памяти 25 гб + хороший канал...но вот процессор вызывает сомнения

короче я заказал, бум пробовать

Core i7 конечно не такой крутой как ксеон, но для мини-хайлоада пойдет

мини хайлоад ))) этот как оценка 4 .. мол хорошо но есть куда стараться ))))

кто нибудь знает способ грамотно вести полномочия пользователей сайта/апишки/админки? если написать стандартизированный рест контроллер который работает со всеми таблицами в базе получается что тот у кого есть доступ на апи может к примеру обновить свой заказ и привязать к нему чужие заказы поскольку для базы это всего лишь записи и так можно. можно поставить полномочие orders.update и выдавать его только админам, но тогда юзер в принципе не сможет обновить свой заказ. даже если сделать заказы необновляемыми - есть таблица пользователей куда можно привязать роли. и там такая же ерунда - если апишка дает право обновлять юзера и привязывать к нему связанные модели, то любой у кого есть доступ на обновление юзеров, может привязать себе любую роль. Получается что одни полномочия для входа на апишку, другие для того чтобы узнать что он привязать может, а что - нет. и это все получаются какие-то частные случаи, которые разве что в контроллер вшить... логика кому можно и что можно выглядит слишком гибкой чтобы написать ее единообразно, или я ее не так понимаю можно попробовать в выборку моделей всунуть глобальное условие что юзер не может получить роли которые выше его собственной. но тогда по запросу /get/roles/admin он тоже получит фигу, т.к. это роль выше пользовательской, то есть он даже справку не сможет получить какие роли бывают. таким образом тут получается фильтруются не те данные что я пытаюсь запросить селектом, а прям как-то в момент загрузки связей нужно применить собственную логику, которая для каждой страницы может быть своя - то есть в случае с заказом - проверять айди владельца, в случае с ролью - проверять старшинство ролей и тд как вы бы это сделали?

@mayerstar будет жить. Поприветствуем!

Всем привет! Ищем на стажировку программиста PHP (junior). Нацелены брать людей, которые готовы быстро включаться в проект и не пропадают.  В свою очередь, чем мы интересны? Мы начинаем стартап-проект и планируем привлекать инвестиции. Даем возможность с минимальными начальными навыками стать частью крутой команды по разработке.  У нас будут интересные проекты, которые реально нужны конечному потребителю.  Здесь вы научитесь быть частью команды. Увидите весь процесс создания IT-продукта от начала до конца. За всеми подробностями пишите мне

кто нибудь знает способ грамотно вести полномочия пользователей сайта/апишки/админки? если написать стандартизированный рест контроллер который работает со всеми таблицами в базе получается что тот у кого есть доступ на апи может к примеру обновить свой заказ и привязать к нему чужие заказы поскольку для базы это всего лишь записи и так можно. можно поставить полномочие orders.update и выдавать его только админам, но тогда юзер в принципе не сможет обновить свой заказ. даже если сделать заказы необновляемыми - есть таблица пользователей куда можно привязать роли. и там такая же ерунда - если апишка дает право обновлять юзера и привязывать к нему связанные модели, то любой у кого есть доступ на обновление юзеров, может привязать себе любую роль. Получается что одни полномочия для входа на апишку, другие для того чтобы узнать что он привязать может, а что - нет. и это все получаются какие-то частные случаи, которые разве что в контроллер вшить... логика кому можно и что можно выглядит слишком гибкой чтобы написать ее единообразно, или я ее не так понимаю можно попробовать в выборку моделей всунуть глобальное условие что юзер не может получить роли которые выше его собственной. но тогда по запросу /get/roles/admin он тоже получит фигу, т.к. это роль выше пользовательской, то есть он даже справку не сможет получить какие роли бывают. таким образом тут получается фильтруются не те данные что я пытаюсь запросить селектом, а прям как-то в момент загрузки связей нужно применить собственную логику, которая для каждой страницы может быть своя - то есть в случае с заказом - проверять айди владельца, в случае с ролью - проверять старшинство ролей и тд как вы бы это сделали?

Есть же RBAC

Есть же RBAC

-1

Всем привет! Ищем на стажировку программиста PHP (junior). Нацелены брать людей, которые готовы быстро включаться в проект и не пропадают.  В свою очередь, чем мы интересны? Мы начинаем стартап-проект и планируем привлекать инвестиции. Даем возможность с минимальными начальными навыками стать частью крутой команды по разработке.  У нас будут интересные проекты, которые реально нужны конечному потребителю.  Здесь вы научитесь быть частью команды. Увидите весь процесс создания IT-продукта от начала до конца. За всеми подробностями пишите мне

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

Чево минус один, используй рбак, не создавай проблемы окружающим разработчикам

Чево минус один, используй рбак, не создавай проблемы окружающим разработчикам

ты создаешь

Если возьмешь abac будет вообще отлично

Если возьмешь abac будет вообще отлично

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

у меня и рбак и абак подключены по-моему. но только мы не придем ни к чему если ты мне будешь доказывать что "у меня неправильный абак"

просто скажи какой правильный. я не враг тебе

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

Вопрос "ты мне покажи как бы ты реализовал" уже стоит денег и выходит за рамки советов в чате

Вопрос "ты мне покажи как бы ты реализовал" уже стоит денег и выходит за рамки советов в чате

ты создаешь. blocked

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

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

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

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

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

Да открой ты гугл и напиши "rbac для тупых" и полюбому найдёшь статью с точным описанием что к чему

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

еще раз. ты меня оскорбил уже дважды. не за хер. просто вот незнакомого человека обозвал дураком и тупым. знаю я что такое рбак и абак. по твоему это значит что ты 1) не знаешь как мне помочь 2) мне не нужна помощь 3) я не знаю что именно ты имеешь в виду 4) я не умею читать 5) я не умею ловить твой авторитет с ходу ... в любом случае не заслуживаю твоей божественной помощи. Гена. ты не помог. ты попытался научить жизни. об этом не просили

Я вот щас перечитал его вопрос в третий раз и понял что он походу касается надстройки над rbac а не самой организации ролей :) В любом случае ответ на него нетривиальный и заморачиваться вникать в задачу врядли кто будет.

Я вот щас перечитал его вопрос в третий раз и понял что он походу касается надстройки над rbac а не самой организации ролей :) В любом случае ответ на него нетривиальный и заморачиваться вникать в задачу врядли кто будет.

спасибо. именно так и есть когда мне задают вопрос - я подключаюсь по дискорду пока не разберемся. и делал так много раз. мне в ответ тем же добром пишут "читай рбак"

справедливо, я считаю кто-то будет работать, а на ком-то поедем

Просто ты себя так ведешь как будто тут все должны стараться вникнуть в задачу разложить все по полочкам и написать тебе код, а ты соблаговолишь принять помощь. Не надо так. Сам раскручивай цепочку объяснений чтобы те кто может помочь поняли все в лучшем виде.

потому что я сам бы так сделал. и потом я задал вопрос. полный и исчерпывающий на три абзаца. получил 10 обвинений в тупости и научение жизни. но не ответ

сейчас тебе хочется обьяснить что я не хороший и поэтому ты мне не помогаешь. но у меня нет хороших и плохих. есть другие. и есть проблема. хороший и плохой это про деньги

@serhii_cho будет жить. Поприветствуем!

Исчерпывающий он будет если будет полная UML диаграмма, описание предметной области, стек технологий и доступ к исходникам с проектной документацией. А так это просто поток сознания.

Исчерпывающий он будет если будет полная UML диаграмма, описание предметной области, стек технологий и доступ к исходникам с проектной документацией. А так это просто поток сознания.

да, после прочтения трех абзацев люди сказали "я не понял". после прочтения доклада в 20 листов они скажут "ну что, здесь все понятно. ему нужен рбак"

опять учите. ну что за...

Поэтому я и резюмировал что реально никто не будет вникать )

Смотри, я тебе посоветовал вникнуть глубже в рбак. Почему? - да потому что если ты вникнешь, то у тебя и вопросы сразу отбросятся. Привожу пример с твоими ордерами и апдейтом. Пользователь может апдейтить только СВОИ ордера, а админ может править все.

Та же история и с апдейтом юзера. Юзер может править только свой профиль, а админ - все

Смотри, я тебе посоветовал вникнуть глубже в рбак. Почему? - да потому что если ты вникнешь, то у тебя и вопросы сразу отбросятся. Привожу пример с твоими ордерами и апдейтом. Пользователь может апдейтить только СВОИ ордера, а админ может править все.

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

Та же история и с апдейтом юзера. Юзер может править только свой профиль, а админ - все

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

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

не просто тем что это ифы. а тем что когда я буду писать админку и её контроллеры, то мне придется повторить это полотно ифов

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

Куда положить код - зависит от структуры проекта, используется ли эта логика только в апи или есть еще web морда, используются ли сервисы, менеджеры, rich domain model и так далее

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

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

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

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

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

Все зависит от архитектуры твоего приложения. Мне удобно создать три модульных файла AdminModule, OfficeModule и WebModule. В них прописываю основные доступы. А потом уже части приложения наследую от этих модулей.

Все зависит от архитектуры твоего приложения. Мне удобно создать три модульных файла AdminModule, OfficeModule и WebModule. В них прописываю основные доступы. А потом уже части приложения наследую от этих модулей.

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

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

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

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

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

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

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

Смотри. Есть модуль admin-orders. Его входной Module.php файл наследуешь от AdminModule.php. в AdminModule у тебя прописано, что дотуп подьзователям только с ролью админ. То есть, если пользователь с ролью ниже админа попробует стукануться на любой роут модуля admin-orders, то получит ошибку доступа.

Смотри. Есть модуль admin-orders. Его входной Module.php файл наследуешь от AdminModule.php. в AdminModule у тебя прописано, что дотуп подьзователям только с ролью админ. То есть, если пользователь с ролью ниже админа попробует стукануться на любой роут модуля admin-orders, то получит ошибку доступа.

да, я это прописал в одной строке. if (user->canOrFail('admin-orders-read')); но в данном случае юзеру можно на роут. но нельзя присваивать записи не принадлежащие ему. а вот просматривать не принадлежащие ему - можно. но только некоторые поля

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

Смотри, делай по принципу " вначале всё запрещаегь, а потом посиепенно разрешаешь". То есть, в модулях админки просто запрешаешь заходить всем, кто не админ.

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

потому что в пяти экшенах вошью проверки - придется в шить еще в 20

Ты не должен пускать в админку простых пользователей . Для просмотра и правки заказов - создай модуль кабинета и выбирай уже заказы только этого пользователя.

да. в админку и не пускаю. интересует следующий этап. где пускать можно, но делать можно не всё. в ордерах у меня есть фильтр wherePermissionOrOwnedBy() который чекает пермишен, если не прошел - добавляет фильтр where('users_id'). Но дальше вопрос - куда его всандалить

т.к. он получается иногда нужен а иногда нет

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

В админ-панели свои поисковые модели, в личном кабинете - свои.