У меня в настройках выбран русский язык и для интерфейса, и для статей, но при заходе на habr.com и habr.ru постоянно редиректит на habr.com/en/top. Неудобно.
Я говорю: Москва, а ты на последнюю букву – Астрахань, а ты, Вася, значит, на «Н» – Новгород. Теперь ты, Федя.
– А что я?
– Говори на «Д».
– Воркута.
– Почему Воркута?
– А я там сидел.
Примеры атак через инлайн-стили можно нагуглить: раз, два, три. Но тут вопрос больше состоит не в том как провести атаку через инлайн-стили, а в том поддерживаете ли вы CSP в своем проекте или нет. Если поддерживаете, то это нужно делать полностью, иначе это будет неэффективная полумера.
Хмм… я о Content Security Policy. Если в 2 словах, это инструмент для защиты сайта от XSS и некоторых других типов атак. При использовании CSP запрещено использовать инлайн-стили и не рекомендуется использовать инлайн-скрипты. В случае с инлайн-скриптами их можно подписывать с помощью атрибута nonce, но для стилей это не работает.
Раз есть инлайн стили, значит о поддержке CSP разрабочики vk не задумываются.
Мда… если производительность восьмерки действительно в три раза хуже семерки, то это полная *опа. Из моей практики, значительная часть времени при разработке Друпал-проекта уходила не на реализацию фич, а на то, чтобы продумать стратегию того как-бы похитрее закешировать данные, а потом вовремя инвалидировать кеш. С восьмеркой, видимо, это время только возрастет.
Центр авторизации аутентифицирует его по наличию куки .auth.mail.ru, генерирует одноразовый токен и перенаправляет на страницу проекта.
Я правильно понимаю, что токен передается просто GET-параметром на какой-то стндартный для проекта redirect url (примерно также сделано в oAuth2)? То есть схема выглядит так:
* юзер зашел на project.mail.ru, при этом он уже залогинен на одном из других проектов Mail.ru,
* его редиректит (с кодом 302) на auth.mail.ru,
* так как в auth.mail.ru есть его авторизационная кука его редиректит на, например, project.mail.ru/redirect?token=123456,
* project.mail.ru берет токен и передает его обратно на auth.mail.ru и в ответ получает сообщение, что все ок, токен валиден,
* после этого project.mail.ru выставляет свою авторизационную куку.
Когда пользователь заходит на сайт проекта, для которого у него еще нет авторизации, его запрос перенаправляется в центр авторизации.
Где определяется, что пользователь не авторизован? В браузере или на сервере?
Если речь о редиректе на уровне веб-сервера, то какой код для редиректа используется? 305, 307? Или авторизационная кука sdc-кука проверяется джаваскриптом (она ведь не httponly?) в браузере и им же делается редирект?
Когда пользователь заходит на сайт проекта, для которого у него еще нет авторизации, его запрос перенаправляется в центр авторизации. Центр авторизации аутентифицирует его по наличию куки .auth.mail.ru, генерирует одноразовый токен и перенаправляет на страницу проекта. Токен проксируется проектом в центр авторизации, который по нему генерирует уже проектную куку для .project.mail.ru.
Не очень понял логику. Зачем «Токен проксируется проектом в центр авторизации, который по нему генерирует уже проектную куку для .project.mail.ru»? Токен проксируется обратно на auth.mail.ru для того чтобы убедиться, что это валидный токен, верно? Но почему куку генерирует центр авторизации, а не сам project.mail.ru? Ведь, насколько я понял, задача в том, чтобы выставить sdc-куку именно на уровне проекта. И если кука генерируется на уровне центра авторизации, то как она передается на сайт проекта? Грубо говоря: проект curl-ом соединяется с центром авторизации, а центр авторизации возвращает некторое значение, которое проект должен использовать для sdc-куки?
И еще вопрос: как запрос проекта «проксируется» в центр авторизации? Это curl-запрос не выходящий за рамки локальной сети, в которой работают все проекты или нет?
Я согласен с тем, что программируя на PHP можно обойтись без знания о том что такое zval. Но если вы хотите разобраться почему именно в приведенном примере функции f1 и f2 ведут себя по разному, то понимать структуру zval и zvalue_value нужно.
Отличие между этими двумя функциями на уровне zval-ов заключается в том, что первая меняет lval и type переданного объекта, что вызывает copy-on-write. Вторая не трогает lval и type, а работает только с zend_object_value.
Как бы вы объяснили разницу в работе этих функций без упоминания zval-ов?
Кстати rrromka приведённый в начале пример не имеет никакого отношения к Zval.
Почему? Я этим примером хотел показать, что функция f1 меняет тип переданного zval-а, по этому внутри неё срабатывает copy-on-write и объект снаружи функции остается без изменения. Функция f2 тип не меняет, по этому копироания-при-записи нет и меняется zval снаружи функции.
+1. Кстати, именно этот доклад побудил меня перевести эту книгу. Я слушал этот доклад и в зале слышал комментарии типа: «о чем это?», «ничего непонятно». То есть не все PHP-разработчики задумываются о том как работает PHP, а это знание может быть полезным.
В плагине для Симфони есть поддержка Твига, можно посмотреть как там сделано.
Я там сидел несколько лет назад :)
Я говорю: Москва, а ты на последнюю букву – Астрахань, а ты, Вася, значит, на «Н» – Новгород. Теперь ты, Федя.
– А что я?
– Говори на «Д».
– Воркута.
– Почему Воркута?
– А я там сидел.
Не All up, а OLAP.
Раз есть инлайн стили, значит о поддержке CSP разрабочики vk не задумываются.
Центр авторизации аутентифицирует его по наличию куки .auth.mail.ru, генерирует одноразовый токен и перенаправляет на страницу проекта.Я правильно понимаю, что токен передается просто GET-параметром на какой-то стндартный для проекта redirect url (примерно также сделано в oAuth2)? То есть схема выглядит так:
* юзер зашел на project.mail.ru, при этом он уже залогинен на одном из других проектов Mail.ru,
* его редиректит (с кодом 302) на auth.mail.ru,
* так как в auth.mail.ru есть его авторизационная кука его редиректит на, например, project.mail.ru/redirect?token=123456,
* project.mail.ru берет токен и передает его обратно на auth.mail.ru и в ответ получает сообщение, что все ок, токен валиден,
* после этого project.mail.ru выставляет свою авторизационную куку.
Верно я понял или нет?
Где определяется, что пользователь не авторизован? В браузере или на сервере?
Если речь о редиректе на уровне веб-сервера, то какой код для редиректа используется? 305, 307? Или авторизационная кука sdc-кука проверяется джаваскриптом (она ведь не httponly?) в браузере и им же делается редирект?
Не очень понял логику. Зачем «Токен проксируется проектом в центр авторизации, который по нему генерирует уже проектную куку для .project.mail.ru»? Токен проксируется обратно на auth.mail.ru для того чтобы убедиться, что это валидный токен, верно? Но почему куку генерирует центр авторизации, а не сам project.mail.ru? Ведь, насколько я понял, задача в том, чтобы выставить sdc-куку именно на уровне проекта. И если кука генерируется на уровне центра авторизации, то как она передается на сайт проекта? Грубо говоря: проект curl-ом соединяется с центром авторизации, а центр авторизации возвращает некторое значение, которое проект должен использовать для sdc-куки?
И еще вопрос: как запрос проекта «проксируется» в центр авторизации? Это curl-запрос не выходящий за рамки локальной сети, в которой работают все проекты или нет?
f1иf2ведут себя по разному, то понимать структуру zval и zvalue_value нужно.Отличие между этими двумя функциями на уровне zval-ов заключается в том, что первая меняет lval и type переданного объекта, что вызывает copy-on-write. Вторая не трогает lval и type, а работает только с zend_object_value.
Как бы вы объяснили разницу в работе этих функций без упоминания zval-ов?
Почему? Я этим примером хотел показать, что функция
f1меняет тип переданного zval-а, по этому внутри неё срабатывает copy-on-write и объект снаружи функции остается без изменения. Функцияf2тип не меняет, по этому копироания-при-записи нет и меняется zval снаружи функции.