I*
Как в php поменять max_redirects в curl? Сейчас максимально 10 установлено, а нужно больше(
Size: a a a
2020 December 19
🎃
Как в php поменять max_redirects в curl? Сейчас максимально 10 установлено, а нужно больше(
рекурсией
I*
рекурсией
да, уже вот делаю) Спасибо)
🎃
да, уже вот делаю) Спасибо)
EG
За теми кто на пхп делает прокси демонов - сразу санитары выезжают :)
Ага и котёл отдельный
I*
Кто работал с Unirest? Сталкивались ли с тем что не сохраняются cookies в файл (Request::cookieFile('file.txt'))?
Когда авторизовываюсь в ВК по cookies, и меняется ip - то ВК несколько раз редиректит формируя новые кукисы, но они почему то не пишутся в файл
Когда авторизовываюсь в ВК по cookies, и меняется ip - то ВК несколько раз редиректит формируя новые кукисы, но они почему то не пишутся в файл
🎃
Кто работал с Unirest? Сталкивались ли с тем что не сохраняются cookies в файл (Request::cookieFile('file.txt'))?
Когда авторизовываюсь в ВК по cookies, и меняется ip - то ВК несколько раз редиректит формируя новые кукисы, но они почему то не пишутся в файл
Когда авторизовываюсь в ВК по cookies, и меняется ip - то ВК несколько раз редиректит формируя новые кукисы, но они почему то не пишутся в файл
Почему не SDK юзать?
I*
Почему не SDK юзать?
да там не апи. Кажется всё сложнее.
Пытался куки подставлять со своего ПК на сервере, но там переформировываются они, т.к. ip не совпадает и деаутентифицируют..
Теперь я ломаю голову, как можно пройти авторизацию в ВК через терминал и вытащить куки на нужном сервере, без графической оболочки (это касательно параметра remixsid)
Пытался куки подставлять со своего ПК на сервере, но там переформировываются они, т.к. ip не совпадает и деаутентифицируют..
Теперь я ломаю голову, как можно пройти авторизацию в ВК через терминал и вытащить куки на нужном сервере, без графической оболочки (это касательно параметра remixsid)
NO
Ты от пользователя пытаешься с API работать?
NO
Просто есть же токен сервисный для бэкенда, у него нет необходимости ни в каких кукисах.
I*
Просто есть же токен сервисный для бэкенда, у него нет необходимости ни в каких кукисах.
есть задачка, выходящая за рамки возможностей api)
NO
Понятно, удачи )
I*
это не чужие, мои. Только проблема, что когда свои кукисы выкидываю на сервер - они сбрасываются, и теряется аутентификация
I*
как раз таки она самая, на античате нашёл обсуждение
I*
да там помимо ip оно отпечаток браузера делает, разрешение экрана и т.д. (в кукисы если заглянете, поймёте)
I*
Но большую роль играет ip.
2020 December 20
DM
В UserPolicy
В StoreUserRequest
Но в таком случае аминистратор сможет создать юзера с любой ролью, а он НЕ должен уметь создавать юзера с ролью owner. Как сделать проверку? В authorize() нельзя обратиться к $this->validated() и вытащить инпут с ролью, т.к. авторизация происходит первее, и на момент срабатывания authorize валидатора ещё нет. Какие есть варианты?
public function create(User $user)
{
return $user->role === User::ADMINISTRATOR || $user->role === User::OWNER;
}
В StoreUserRequest
public function authorize()
{
return Auth::user()->can('create', User::class);
}
Но в таком случае аминистратор сможет создать юзера с любой ролью, а он НЕ должен уметь создавать юзера с ролью owner. Как сделать проверку? В authorize() нельзя обратиться к $this->validated() и вытащить инпут с ролью, т.к. авторизация происходит первее, и на момент срабатывания authorize валидатора ещё нет. Какие есть варианты?
DM
Или лучше не делать проверку прав в реквесте, а перенести в контроллер?
ПЛ
В UserPolicy
В StoreUserRequest
Но в таком случае аминистратор сможет создать юзера с любой ролью, а он НЕ должен уметь создавать юзера с ролью owner. Как сделать проверку? В authorize() нельзя обратиться к $this->validated() и вытащить инпут с ролью, т.к. авторизация происходит первее, и на момент срабатывания authorize валидатора ещё нет. Какие есть варианты?
public function create(User $user)
{
return $user->role === User::ADMINISTRATOR || $user->role === User::OWNER;
}
В StoreUserRequest
public function authorize()
{
return Auth::user()->can('create', User::class);
}
Но в таком случае аминистратор сможет создать юзера с любой ролью, а он НЕ должен уметь создавать юзера с ролью owner. Как сделать проверку? В authorize() нельзя обратиться к $this->validated() и вытащить инпут с ролью, т.к. авторизация происходит первее, и на момент срабатывания authorize валидатора ещё нет. Какие есть варианты?
вариант 1
вынести проверку на создаваемую роль в FormRequest
вариант 2
вынести проверку в контроллер
такая валидация лучше выглядит именно там, так как ближе к неверным входным данным, нежели к отсутствию прав доступа, имхо
вынести проверку на создаваемую роль в FormRequest
вариант 2
вынести проверку в контроллер
такая валидация лучше выглядит именно там, так как ближе к неверным входным данным, нежели к отсутствию прав доступа, имхо
ПЛ
иными словами политика проверяет возможность создать юзера
а реквест - роль создаваемого юзера
а реквест - роль создаваемого юзера