Рубрика: Программирование

twig вывести на русском текущий месяц


{% set mnths = ['','января','февраля','марта','апреля','мая','июня','июля','августа','сентября','октября','ноября','декабря'] %}
{{ mnths[date('now', 'Europe/Moscow')|date("n")] }}


Условие с датой

{% if date('now', 'Europe/Moscow') > date('2028-01-02') %}
    вывод после 2028 года
{% else %}
    вывод до 2028 года
{% endif %}



{{ countBonus|number_format(2, '.', '') }} - выведет с нулями после точки
{{ '%07.2f'|format(countBonus) }} - добъет нули до и после точки

Про компьютеры

Основном мой рабочий компьютер сейчас, это Макбук Про. Он конечно не идеальный, но после долгих лет на windows и  linux, остановился именно на нем. На это есть три главные причины:

Читать далее Про компьютеры

Парацетамол

Я: — Иммунитет, что за нафиг, почему у меня температура 40?
Иммунитет: — Я выбросил в кровь пирогены, которые добрались до центра терморегуляции в гипоталамусе и тот сместил точку равновесия в сторону теплопродукции.

Читать далее Парацетамол

HTTP Digest

Документация по Digest http://www.hardline.ru/4/38/4862/

Проверка Curl

curl -v —digest —user ‘User:Password’ «https://yandex.ru/MessageService/WebService.svc»

 

Система аутентификации на базе протокола HTTP Digest. Усиление модуля.
В статье «Система аутентификации на базе протокола HTTP Basic был рассмотрен алгоритм Basic аутентификации и с помощью него была построена система Basic аутентификации на основе ролей, работающая без специальной настройки IIS сервера и использующая базу данных для хранения учетных записей пользователей.У Basic есть один недостаток, а именно username и password передаются по сети открыто (clear text), base64 кодировка не может считаться защитой.

Аутентификация Digest

В этой статье будет рассмотрен алгоритм Digest аутентификации, решающей некоторые проблемы, имеющиеся у HTTP Basic Authentication. Например эта схема не передаёт password по сети открытым текстом. Официальное название схемы — «Digest Access Authentication».

Расширим нашу систему из предыдущей статьи.

К преимуществам Digest можно отнести следуещее:

  1. passwords не передаются открыто по сети
  2. способность защиты от повторяющихся атак (monitoring http nc value)
  3. способность создать защиту (monitoring nonce)
    • в определённый промежуток времени
    • от определённого client
    • от определённого request

Один сайт может одновременно использовать несколько систем защиты, например Basic и Digest

Пришло время рассмотреть работу алгоритма Digest аутентификации:

1. Первый запрос от User Agent к Http Server заголовок Authorization пустой — значит server должен возвратить запрос на аутентификацию. Например такой:

2. ответ сервера:

HTTP/1.1 401 Unauthorized
        WWW-Authenticate: Digest
                 realm="testrealm@host.com",
                 qop="auth",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41",
                 algorithm=MD5,
                 stale=false

Разберём заголовок WWW-Authenticate (как вы заметили, он усложнился по сравнению с заголовком Basic):

realm Строка, указывающая юзеру где он и какой пароль вводить например «registered_users@gotham.news.com».
nonce Уникальная строка, которая генерируется на сервере в момент ответа 401. запрещено использовать кавычку, так как внутри заголовка строка в кавычках рекомендуется также закодировать её base64, например time-stamp H(time-stamp «:» ETag «:» private-key)
opaque Строка, которую юзер должен будет вернуть на сервер в неизменённом виде Рекомендуется закодировать base64
stale true/false
Индикатор, который показывает, что если true — запрос был правильный, username-password тоже, nonce неправильный false или любое другое значение или отсутствие stale — неправильные username, password
algorithm optional, MD5 = default
qop указывает «quality of protection».
«auth» указывает authentication,
«auth-int» указывает authentication + integrity protection. могут быть оба через запятую

3. У юзера всплывает модальное окно, предлагающее ввести username и password (обратите внимание, окно отличается от Basic окна). Происходит запрос юзера для аутентификации:

GET ... ... HTTP/1.1
        Authorization: Digest
                 username="Mufasa",
                 realm="testrealm@host.com",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 uri="/dir/index.html",
                 qop=auth,
                 nc=00000001,
                 cnonce="0a4f113b",
                 response="6629fae49393a05397450978507c4ef1",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"

Теперь разберём заголовок Authorization:

username имя юзера
realm см. WWW-Authenticate
qop см. WWW-Authenticate (должно совпадать с одним из списка qop WWW-Authenticate)
algorithm см. WWW-Authenticate (должно совпадать)
opaque см. WWW-Authenticate (должно совпадать)
uri запрос (например страница)
response 32-character строка — именно c её помощью проверяется пароль.
nonce
nc once count — сколько раз был использован текущий nonce
cnonce уникальная строка, посылаемая браузером на сервер

4. Последовательность обработки запроса пользователя

  1. Проверяем, существует ли заголовок Authorization
  2. Проверяем, является ли он Digest
  3. Отсекаем слово Digest
  4. Берём username (обратите внимание — в заголовке отсутствует password — по крайней мере его не видно)
  5. проверяем базу данных с этим юзером, существует ли он — запоминаем его password из базы
  6. проверяем запрос по ролям против страниц с ролями, как мы уже делали в Basic.

Если что-то не так — переходим к пункту 6. Если всё ok — идём дальше (это ещё далеко не всё :))

5. Проверка пароля пользователя

  1. создаём строку A1 вида
    A1 = unq(username) : unq(realm) : passwd
  2. хешируем A1
    HA1 = MD5(A1)
  3. создаём строку A2 вида
    A2 = Http Method «:» digest-uri
  4. хешируем A2
    HA2 = MD5(A2)
  5. создаём строку GENRESPONSE вида
    GENRESPONSE = HA1 «:» nonce «:» nc «:» cnonce «:» qop «:» HA2
  6. хешируем GENRESPONSE
    HGENRESPONSE = MD5(GENRESPONSE)

если HGENRESPONSE равен response в заголовке Authorization запроса юзера и nonce в порядке — всё ok, нет — переходим к пункту 6

6. выдаём состояние ответа сервера 401, поднимающее модальное окно как в пункте 2 иначе говоря формируем WWW-Authenticate по типу Digest

Bitrix CMS

Bitrix CMS одна из самых страшных CMS в мире. Это свой собственный корявый язык поверх PHP.

Если вы хотите сделать что то быстро, надежно и красиво, bitrix  cms это мимо

Пример. У вас есть инфоблок, в котором можно настроить поля.

Вы добавляете новый вид поля — Список, и вбиваете туда адреса:

 

Снимок экрана 2020-11-28 в 14.19.24

 

Теперь на сайте делаете фильтр и предлагаете пользователю выбрать нужный вам адрес

И тут начитается ОЛОЛОЛОЛОЛ, фильтровать по  XML_ID  эту дичь не выйдет, то есть вы можете фильтровать ТОЛЬКО по значению value

 

Но даже в этом случае, попробуйте без бутылки разобраться КАК тут это сделать?:

 

 



 $APPLICATION->IncludeComponent("bitrix:news","",Array(
        "DISPLAY_DATE" => "Y",
        "DISPLAY_PICTURE" => "Y",
        "DISPLAY_PREVIEW_TEXT" => "Y",
        "SEF_MODE" => "Y",
        "AJAX_MODE" => "Y",
        "IBLOCK_TYPE" => "news",
        "IBLOCK_ID" => "1",
        "NEWS_COUNT" => "20",
        "USE_SEARCH" => "Y",
        "USE_RSS" => "Y",
        "USE_RATING" => "Y",
        "USE_CATEGORIES" => "Y",
        "USE_REVIEW" => "Y",
        "USE_FILTER" => "Y",
        "SORT_BY1" => "ACTIVE_FROM",
        "SORT_ORDER1" => "DESC",
        "SORT_BY2" => "SORT",
        "SORT_ORDER2" => "ASC",
        "CHECK_DATES" => "Y",
        "PREVIEW_TRUNCATE_LEN" => "",
        "LIST_ACTIVE_DATE_FORMAT" => "d.m.Y",
        "LIST_FIELD_CODE" => Array(),
        "LIST_PROPERTY_CODE" => Array(),
        "HIDE_LINK_WHEN_NO_DETAIL" => "Y",
        "DISPLAY_NAME" => "Y",
        "META_KEYWORDS" => "-",
        "META_DESCRIPTION" => "-",
        "BROWSER_TITLE" => "-",
        "DETAIL_SET_CANONICAL_URL" => "Y",
        "DETAIL_ACTIVE_DATE_FORMAT" => "d.m.Y",
        "DETAIL_FIELD_CODE" => Array(),
        "DETAIL_PROPERTY_CODE" => Array(),
        "DETAIL_DISPLAY_TOP_PAGER" => "Y",
        "DETAIL_DISPLAY_BOTTOM_PAGER" => "Y",
        "DETAIL_PAGER_TITLE" => "Страница",
        "DETAIL_PAGER_TEMPLATE" => "",
        "DETAIL_PAGER_SHOW_ALL" => "Y",
        "STRICT_SECTION_CHECK" => "Y",
        "SET_TITLE" => "Y",
        "ADD_SECTIONS_CHAIN" => "Y",
        "ADD_ELEMENT_CHAIN" => "N",
        "SET_LAST_MODIFIED" => "Y",
        "PAGER_BASE_LINK_ENABLE" => "Y",
        "SET_STATUS_404" => "Y",
        "SHOW_404" => "Y",
        "MESSAGE_404" => "",
        "PAGER_BASE_LINK" => "",
        "PAGER_PARAMS_NAME" => "arrPager",
        "INCLUDE_IBLOCK_INTO_CHAIN" => "Y",
        "USE_PERMISSIONS" => "Y",
        "GROUP_PERMISSIONS" => Array("1"),
        "CACHE_TYPE" => "A",
        "CACHE_TIME" => "3600",
        "CACHE_FILTER" => "Y",
        "CACHE_GROUPS" => "Y",
        "DISPLAY_TOP_PAGER" => "Y",
        "DISPLAY_BOTTOM_PAGER" => "Y",
        "PAGER_TITLE" => "Новости",
        "PAGER_SHOW_ALWAYS" => "Y",
        "PAGER_TEMPLATE" => "",
        "PAGER_DESC_NUMBERING" => "N",
        "PAGER_DESC_NUMBERING_CACHE_TIME" => "36000",
        "PAGER_SHOW_ALL" => "Y",
        "FILTER_NAME" => "",
        "FILTER_FIELD_CODE" => Array(),
        "FILTER_PROPERTY_CODE" => Array(),
        "NUM_NEWS" => "20",
        "NUM_DAYS" => "30",
        "YANDEX" => "Y",
        "MAX_VOTE" => "5",
        "VOTE_NAMES" => Array("0", "1", "2", "3", "4"),
        "CATEGORY_IBLOCK" => Array(),
        "CATEGORY_CODE" => "CATEGORY",
        "CATEGORY_ITEMS_COUNT" => "5",
        "MESSAGES_PER_PAGE" => "10",
        "USE_CAPTCHA" => "Y",
        "REVIEW_AJAX_POST" => "Y",
        "PATH_TO_SMILE" => "/bitrix/images/forum/smile/",
        "FORUM_ID" => "1",
        "URL_TEMPLATES_READ" => "",
        "SHOW_LINK_TO_FORUM" => "Y",
        "POST_FIRST_MESSAGE" => "Y",
        "SEF_FOLDER" => "/",
        "SEF_URL_TEMPLATES" => Array(
            "detail" => "#ELEMENT_ID#/",
            "news" => "search/",
            "section" => "rss/",
        ),
        "AJAX_OPTION_JUMP" => "N",
        "AJAX_OPTION_STYLE" => "Y",
        "AJAX_OPTION_HISTORY" => "N",
        "VARIABLE_ALIASES" => Array(
            "detail" => Array(),
            "news" => Array(),
            "section" => Array(),
        ),
        "USE_SHARE" => "Y",
        "SHARE_HIDE" => "Y",
        "SHARE_TEMPLATE" => "",
        "SHARE_HANDLERS" => array("delicious", "facebook", "lj", "twitter"),
        "SHARE_SHORTEN_URL_LOGIN" => "",
        "SHARE_SHORTEN_URL_KEY" => "",
        )
);

 

diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Если при подключении по ssh  получаем ошибку:

 

Unable to negotiate with 11.11.7.10 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

fatal: Could not read from remote repository.

Please make sure you have the correct access rights

То надо в файле

~/.ssh/config

Прописать:

Host 11.11.7.10

    KexAlgorithms +diffie-hellman-group1-sha1