Олег Правдин

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

Только формат файла от этого и не поменяется, это будет jpg который обозван как png.

Используйте систему слотов:

В компоненте таблицы:

...
<tr v-for="row in rows">
  <td v-for="header in headers">
    <slot :name="`cel_${header.key}`" :row="row"> {{ row[header.key] }} </slot>
  </td>
</tr>
...

Использование компонента таблицы:

...
<table-component :rows="users" :headers="headers">
  <template slot="cel_full_name" slot-scope="props">
    <router-link :to="`/user/${props.row.id}`">{{ props.row.full_name }}</router-link>
  </template>
</table-component>
...

Очень хороший вопрос и тема, в которой самое чудовищное количество самых дремучих северий на единицу кода.

В общем случае, по умолчанию, никаких проверок и траев с кетчами быть не должно.

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

Пример: В обоих приведенных выше случаях мы имеем масло масляное: попытка подменить пхп в выборосе ошибки. Вопрос - зачем? Если файл не найден, то РНР сам прекрасно сообщит нам об ошибке, причем в подробностях, и скажет в чем конкретно заключается проблема. А по строчке "file not found" иди гадай - путь ли кривой или в имени файла опечатка, или вообще пустоту передали.

Любые проверки надо делать только тогда, когда есть осмысленный сценарий их обработки.

И обсуждать выше приведенные примеры имеет смысл только если автор вопроса предоставит такой сценарий. тупое error: file not found таким сценарием не является. Так что в общем случае оставляем код в покое и не устраиваем никакого карго культа из перехвата ошибок.

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

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

Но повторюсь, если нет никакого осмысленного сценария обработки ошибки, то ловить её не надо.

В таком примере, как вы привели, if() проверяет только условие существования файла или директории. А try-catch обработает бОльшее число ситуаций: если это не файл, а директория, если права не позволяют читать, если устройство гакнулось и не прочиталось.


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

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

Внешние материалы по теме:

1. Пост по теме (на англ.)
   
2. скорость выполнения с исключениями и без (без быстрее)
   
3. Exception patterns, в частности:
   
   • Use Exceptions Instead Of Error Values
     
   • Don't Use Exceptions For Flow Control
     
   • Avoid Exceptions Whenever Possible
     
   • Code Without Exceptions
   
   
   

Что я делаю не так?

Нужно добавить <link rel="preload" />, а не заменить ими ваши скрипты.

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

Гарантия от replay attack достигается тем, что для передачи команды сторонам нужно аутентифицироваться, т. е. это всегда двусторонний обмен. Технически сначала стороны обмениваются сертификатами, проверяют их, затем на основании алгоритма Диффи-Хэллмана формируют симметричный ключ шифрования, который будет использоваться для шифрования потока данных. В общем случае, в каждой сессии этот ключ будет разным. Есть механизмы кэширования и сохранения стейта, для ускорения установления TLS-сессии (допустим, на случай если клиент недавно уже подключался) -- это нужно, чтобы увеличить скорость согласования TLS-соединения), но это всё опционально и отключабельно.

Внутрь TLS можно засунуть что угодно -- кастомный бинарный протокол на базе TCP/IP или REST API на базе HTTP -- без разницы.

10 лет это 3 класс

Отстаньте лучше от ребёнка. Ему всего лишь 10 лет - какое программирование? Пусть он сначала насладится детством. А уже после - сам начнёт ковыряться в том, что ему понравится

Все ответы из серии лучше бы молчал... Смысл повторять то, что написано в википедии. Вам в вопросе человек явно указал - НА ПАЛЬЦАХ, а они ему про стандарты... Дали бы просто ссылку на MDN - там самая лучшая документация обо всём: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
На русском тоже есть статьи: https://grishaev.me/cors

Вот моя текущая проблема, объсняю на её примере:

На нашем сервере (Сервер А) размещается Ангуляр приложение (DAPP), представляющее собой интерфейс к Ethernet смарт-контракту, который грубо говоря является нашим бэкендом.

На стороннем сервисе (Сервер Б) запущен http-интерфейс для доступа к нашему контракту (фактически это шлюз в сеть Ethereum). Это бесплатный сервис, к которому у нас нет доступа (Infura).

Мне нужно из моего DAPP, запущенного в браузере пользователя и которое загрузилось с Сервера А, делать http-запросы на Сервер Б, и тут в браузере выскакивает CORS и кричит НИИИИЗЯЯЯЯЯЯЯЯ! Причём в Chrome всё ок, а в долбаном тормозном Firefox (господи, сократи число пользующиегося им идиотов, чтобы он скорее издох) вылетает ошибка. Ибо, как завещает CORS, негоже JS коду, загруженному с одного адреса, делать http запросы на другой. Причём CORS устроен так, что эта ошибка не дебажится с помощью JS - типа для того чтобы это ограничение не смогли никак обойти. Поэтому какие бы я не прописывал Серверу А заголовки 'Allow-Origin', это ничего не меняет. В Гугле уже осознали весь идиотизм ситуации и в новых версиях Хрома уже не блочат всё подряд, как раньше, пропуская “простые” запросы (GET/POST), остальный браузеры пока тупят.

ПС. Проблему решили запуском прокси сервера, который добавляет в ответы от Сервера 2 заголовки Access-Controll-Allow-Origin с адресом Сервера 1. Тоесть Сервер 2 должен сказать браузеру, что он доверяет коду, загруженному с Сервера 1. Вот и весь CORS.

Решена проблема!
Оказывается в личном кабинете стояла галочка "Отдельные пароли для приложений".
Галочка сама ставится если включить двухфакторную авторизацию на яндексе. После выключения двухфакторной авторизации галочка Отдельные пароли для приложений остается включенной.