Перейти к содержимому


Фото
* * * * * 1 голосов

token у рисунков - идея по переделке


  • Чтобы отвечать, сперва войдите на форум
55 ответов в теме

#41 a13x

a13x
  • Забаненый
  • 213 сообщений
  • Дизайн, Программирование, Верстка, SEO, Заказчик, Пользователь
  • Версия CMS:2.x
  • Откуда:Москва

Опубликовано 04.12.2017 - 11:30

:D Что мешает хранить кэш (ресайз фоток) в другой папке, не в папке files, так же как и оригиналы фоток?

Защита от формирования картинки без водяного знака???

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

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

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

 

Вобщем для меня по прежнему это загадка <_<



#42 Пастухов

Пастухов
  • Пользователь
  • 119 сообщений
  • Программирование
  • Откуда:Минск

Опубликовано 04.12.2017 - 12:54

Вроде это несвязанные вещи, токен и водяной знак.

Очевидно, что связаны.
Токен - шифрует данные картинки, в том числе наличие водяного знака. Значит, токен ЗАВИСИТ от наличия/отсутствия знака.

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

Нет. Читайте внимательно, про какой запрос речь...

#43 Kosjak76

Kosjak76
  • Модератор
  • 3 729 сообщений
  • Программирование
  • Версия CMS:1.x, 2.x
  • Откуда:Харьков, Украина

Опубликовано 04.12.2017 - 13:34

В Симпле нет доступа к оригиналам файлов, и это правильно.

Доступ есть только к ресайзам через токен - и это тоже правильно.



#44 a13x

a13x
  • Забаненый
  • 213 сообщений
  • Дизайн, Программирование, Верстка, SEO, Заказчик, Пользователь
  • Версия CMS:2.x
  • Откуда:Москва

Опубликовано 04.12.2017 - 13:36

Очевидно, что связаны.
Токен - шифрует данные картинки, в том числе наличие водяного знака. Значит, токен ЗАВИСИТ от наличия/отсутствия знака.Нет. Читайте внимательно, про какой запрос речь...

Токен НИКАК не связан с ресайзом картинок, можете внимательно изучить класс IMAGE и убедиться в этом, отсюда и вывод что водяной знак никак не относится к токену.

Токен НИКАК не шифрует данные картинки, возможно урла для получения картинки - да, но никак не саму картинку.

Нет. Читайте внимательно, про какой запрос речь...

Понял, запрос к продукту товара, не к оригиналу. И в чём тогда проблема? Файл создаётся после первого запроса. Все повторные запросы просто вызовут отдачу файла, никакой нагрузки при этом не будет.

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


 

В Симпле нет доступа к оригиналам файлов, и это правильно.

Доступ есть только к ресайзам через токен - и это тоже правильно.

Ну если у вас всё хранится по штатным путям, то почему же нет?

Если только ограничено через .htaccess

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


Изменено: a13x, 04.12.2017 - 13:49


#45 Kosjak76

Kosjak76
  • Модератор
  • 3 729 сообщений
  • Программирование
  • Версия CMS:1.x, 2.x
  • Откуда:Харьков, Украина

Опубликовано 04.12.2017 - 13:55

Ну если у вас всё хранится по штатным путям, то почему же нет?

Если только ограничено через .htaccess

Да, именно так.

Про сервера, отличные от апача 

Требования к хостингу

Apache
PHP5 или PHP6
MySQL 4.1 и выше

Источник - оффсайт :) http://simplacms.ru/

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



#46 a13x

a13x
  • Забаненый
  • 213 сообщений
  • Дизайн, Программирование, Верстка, SEO, Заказчик, Пользователь
  • Версия CMS:2.x
  • Откуда:Москва

Опубликовано 04.12.2017 - 14:09

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


if(!empty($_SERVER["HTTP_REFERER"])){
...
}
 

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


Изменено: a13x, 04.12.2017 - 14:09


#47 Пастухов

Пастухов
  • Пользователь
  • 119 сообщений
  • Программирование
  • Откуда:Минск

Опубликовано 04.12.2017 - 15:08

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

if(!empty($_SERVER["HTTP_REFERER"])){
...
}
 
Это конечно не панацея, но решается 2-мя строками, если конечно ваши конкуренты не захотят использовать curl и подсовывать нужные значения в этот заголовок, зато проблема с нормальным индексированием фоток отпадёт сама собой.

 
Обойти такую проверку можно, имея самые начальные знания в HTML, просто создав файлик с <img src="..."> и запустив с любого сайта или даже локального сервера. Что уж тут говорить про curl и подобные средства...
 

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

 
Тут я неточно выразился, имелось в виду, что токен ЗАВИСИТ от наличия/отсутствия водяного знака (через посредство имени файла).
Кстати говоря, класс IMAGE с токеном не работает вообще, работа с ним  идет в других местах.
 

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

 

Это стандартно: чтобы с сервера не скачивать большой объем картинки 2000х2000, чтобы показать ее затем малюсенькой с параметром width=150 (особенно актуально для списков товаров).



#48 a13x

a13x
  • Забаненый
  • 213 сообщений
  • Дизайн, Программирование, Верстка, SEO, Заказчик, Пользователь
  • Версия CMS:2.x
  • Откуда:Москва

Опубликовано 04.12.2017 - 16:00

Обойти такую проверку можно, имея самые начальные знания в HTML, просто создав файлик с <img src="..."> и запустив с любого сайта или даже локального сервера. Что уж тут говорить про curl и подобные средства...

Проверкой на REFERER я показал что можно проверять откуда пришёл человек, и конечно же можно проверять на полный путь запроса. Да, с curl'ом кому то придётся заморачиваться, но кому оно надо? На фото всё равно будет ватермарк, даже при максимальном размере.

Это стандартно: чтобы с сервера не скачивать большой объем картинки 2000х2000, чтобы показать ее затем малюсенькой с параметром width=150 (особенно актуально для списков товаров).

А разве токен отвечает за это? За это отвечает только параметр ресайз. Поэтому когда вы в шаблоне вызываете $image->filename|resize:50:50 у вас уже будет пикча с нужными вам размерами, соотв. ни о каких размерах 2000:2000 речи не идёт, если только вы сами это не укажете.

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



#49 Пастухов

Пастухов
  • Пользователь
  • 119 сообщений
  • Программирование
  • Откуда:Минск

Опубликовано 04.12.2017 - 17:04

Проверкой на REFERER я показал что можно проверять откуда пришёл человек, и конечно же можно проверять на полный путь запроса. Да, с curl'ом кому то придётся заморачиваться, но кому оно надо? На фото всё равно будет ватермарк, даже при максимальном размере.

А разве токен отвечает за это? За это отвечает только параметр ресайз. Поэтому когда вы в шаблоне вызываете $image->filename|resize:50:50 у вас уже будет пикча с нужными вам размерами, соотв. ни о каких размерах 2000:2000 речи не идёт, если только вы сами это не укажете.

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

 

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

Да, по большому счету плюс только один. 

 

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

 

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



#50 a13x

a13x
  • Забаненый
  • 213 сообщений
  • Дизайн, Программирование, Верстка, SEO, Заказчик, Пользователь
  • Версия CMS:2.x
  • Откуда:Москва

Опубликовано 04.12.2017 - 17:15

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

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


Изменено: a13x, 04.12.2017 - 17:18


#51 a13x

a13x
  • Забаненый
  • 213 сообщений
  • Дизайн, Программирование, Верстка, SEO, Заказчик, Пользователь
  • Версия CMS:2.x
  • Откуда:Москва

Опубликовано 02.01.2018 - 20:06

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

Создаёте в классе IndexView метод:

    public function err404()
    {
        // Иначе страница об ошибке
        header("http/1.1 404 not found");
        // Подменим переменную GET, чтобы вывести страницу 404
        $_GET['page_url'] = '404';
        $_GET['module'] = 'PageView';
        print $this->fetch();
    }
 

В главном файле index.php ищите код который мы добавили в метод и заменяете на:

 

$view->err404();

Далее в файле resize.php делаете примерно такую проверку:

 

if(strpos(@$_SERVER["HTTP_REFERER"], $_SERVER["HTTP_HOST"]) === false)
    $view->err404();

Теперь при запросе изображения которое не сгенерировано, сервер выдаст страницу с 404 ошибкой и человек даже не будет заморачиваться чтобы пытаться работать через curl или подменят заголовок. Если же запрос пришёл с вашего сервера, то проблем не будет. Думаю одна проверка куда проще чем тащить и генерировать токен.


Изменено: a13x, 02.01.2018 - 20:08


#52 Плохиш

Плохиш
  • Забаненый
  • 98 сообщений
  • Программирование
  • Версия CMS:2.x
  • Откуда:Орел

Опубликовано 03.01.2018 - 10:15

Новость хорошая:

 

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

 

Новость плохая:

 

Если же запрос пришёл с вашего сервера, то проблем не будет.

 

Похоже, Вы подразумеваете, что изображения надо показывать ТОЛЬКО на страницах своего домена и если запрос пришел с иного сервера, то это это хакерские штучки. Но это вовсе не так.
И в некоторых случаях картинки могут не показываться. Как минимум:
1. Стандартное письмо о заказе содержит ссылки на картинки, которые при Вашем подходе могут стать битыми в простых ситуациях.
2. Аналогично, если используется yandex.xml, то поисковик вполне может получить 404 вместо картинок.
3. И вообще, ограничивать показ картинок страницами своего домена - в принципе плохая идея для продвижения. Ибо тем самым Вы закрываете, например, полноценные возможности для показа картинок в RSS.

Вообще вопрос не простой, на форуме описано несколько разных способов избавиться от токена, но полностью хорошего решения не найдено.
В одной из последних попыток
http://forum.simplac...ge-4#entry96897
недостатки того метода довольно похожи на недостатки Вашего...


Изменено: Плохиш, 03.01.2018 - 10:16


#53 a13x

a13x
  • Забаненый
  • 213 сообщений
  • Дизайн, Программирование, Верстка, SEO, Заказчик, Пользователь
  • Версия CMS:2.x
  • Откуда:Москва

Опубликовано 03.01.2018 - 12:00

Суть в том что это ТОЛЬКО для генерации новых изображений. Если изображение было сгенерировано ранее, то никаких проблем не будет, ведь суть токена именно в этом.

Поэтому проблема №1 отпадает т.к. человек посещал ссылку с товаром.

Проблема №2: если робот обходил все ваши страницы , то все изображения будут сгенерированы.

Проблема №3: здесь ограничивается не показ, а создание новых.

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


Изменено: a13x, 03.01.2018 - 12:04


#54 Плохиш

Плохиш
  • Забаненый
  • 98 сообщений
  • Программирование
  • Версия CMS:2.x
  • Откуда:Орел

Опубликовано 03.01.2018 - 14:32

Поэтому проблема №1 отпадает т.к. человек посещал ссылку с товаром.

 

С какой же стати она отпадает? Если в шаблоне письма прописан resize:67:67, и больше нигде такого ресайза нет, то ссылка на картинку из письма как раз и даст 404.

 

Проблема №2: если робот обходил все ваши страницы , то все изображения будут сгенерированы.

 

Довольно туманно: не очень понятно, что имеете в виду под "все" и многое зависит от того, как работают роботы - вряд ли все их тонкости Вам известны.
Опять же если в yandex.php прописан resize_modifier($p->image, 770, 770) и больше нигде такого ресайза нет, то ссылка на такую картинку и даст 404.

 

Проблема №3: здесь ограничивается не показ, а создание новых.

 

Показ и создание новых в Simpla стандартно делается "на лету", и эти вещи взаимосвязаны.
Это лишь Вы задумали "ограничивается не показ, а создание новых". Но реально во многих простых ситуациях это даст и ограничение на показ.
Например, в RSS изменили размер картинки на 97:97, которого ранее нигде не было. Картинки такие НЕ покажутся реально. Вот и будет ограничение на показ...

 

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

 

Эта проблема может возникнуть во всех трех указанных случаях.

Значит, Вы вводите дополнительное ограничение: владелец сайта должен каждый раз, когда меняет размер на сайте, думать - а не испортит ли мне это выдачи в случаях 1-3? Неудобство очевидное.
Например, в целях продвижения хочется картинку 550:550, а такой нет сейчас на сайте. Что - вставлять принудительно? Можно, конечно, ее скрыть, но ведь это совсем некрасиво.

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

 

То есть при практическом применении возможна масса сюрпризов. 



#55 a13x

a13x
  • Забаненый
  • 213 сообщений
  • Дизайн, Программирование, Верстка, SEO, Заказчик, Пользователь
  • Версия CMS:2.x
  • Откуда:Москва

Опубликовано 03.01.2018 - 15:33

Показ - это значит показ - картинка УЖЕ создана.

Создание - создание И показ картинки.

Именно так работает модуль resize.

Оба варианта абсолютно разные и из второго вытекает первое, но это не равные вещи.

Чтобы понять как работает робот мне не надо знать все его тонкости, обход страниц осуществляется обычным заходом на страницу и никак иначе. Всё что у вас прописано для человека, сработает и для робота, если вы конечно сами там не сделали ограничения.

Если вы любите создавать тучу картинок где отличие в 10-100 пикселей, то этот метод  не для вас.

Он подразумевает создание 3 типов превьюшек: small - (100-200px для категории) , medium - (400-700px для карточки товара) и big - 1200px для большого изображения. Все остальные это ваши тараканы и бред заказчиков. Вы можете создавать для письма 65 пикс, для картинок в футере 37 пикс, для шапки 92 и тп. и использовать токен.

 

Например, в целях продвижения хочется картинку 550:550, а такой нет
сейчас на сайте. Что - вставлять принудительно? Можно, конечно, ее
скрыть, но ведь это совсем некрасиво.

В чём проблема вставить ближайшую которая используется? 600 может быть или 700? Или вы боитесь за овертрафик? :lol:


Изменено: a13x, 03.01.2018 - 15:36


#56 Плохиш

Плохиш
  • Забаненый
  • 98 сообщений
  • Программирование
  • Версия CMS:2.x
  • Откуда:Орел

Опубликовано 03.01.2018 - 16:03

Чтобы понять как работает робот мне не надо знать все его тонкости, обход страниц осуществляется обычным заходом на страницу и никак иначе. Всё что у вас прописано для человека, сработает и для робота, если вы конечно сами там не сделали ограничения.

 

Как раз в Вашем случае и надо знать, ибо это существенно! Важно, каким запросом он выкачивает картинку, посылает ли REFERER от домена сайта или нет. И тут я не уверен, что все так просто, как Вы думаете. Подозреваю, что и Вы не проводили эксперименты для точного выяснения - хотя бы по одному из многих поисковиков.

 

Он подразумевает создание 3 типов превьюшек: small - (100-200px для категории) , medium - (400-700px для карточки товара) и big - 1200px для большого изображения. Все остальные это ваши тараканы и бред заказчиков. Вы можете создавать для письма 65 пикс, для картинок в футере 37 пикс, для шапки 92 и тп. и использовать токен.

 

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

 

В чём проблема вставить ближайшую которая используется? 600 может быть или 700?

 

Много раз приходилось общаться со спецами по SEO. У них обычно требования жесткие. И сами поисковики и разные агрегаторы зачастую свои условия ставят.

Вообще странный вопрос от программиста. Обычно программист старается делать, чтобы правильно работало для ЛЮБЫХ данных. А у Вас какие-то надуманные ограничения, к тому же нестрогие на бытовом языке.






0 пользователей читают эту тему

0 пользователей, 0 гостей, 0 скрытых