Перейти к содержанию
Официальный форум поддержки Simpla

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


Рекомендуемые сообщения

Если переделать немного функционал ресайза, то в целях безопасности токен становится не нужным.

 

Подскажи тогда, с радостью выслушаю твои идеи 

Ссылка на сообщение
Поделиться на другие сайты
  • Ответов 57
  • Дата создания
  • Последний ответ

Лучшие авторы в теме

Лучшие авторы в теме

Подскажи тогда, с радостью выслушаю твои идеи

Несколько сообщений назад я уже отвечал на подобный вопрос Кросу.

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

Ссылка на сообщение
Поделиться на другие сайты

Несколько сообщений назад я уже отвечал на подобный вопрос Кросу.

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

там кроме что ты что то где то сделал и все ок, не какой конкретики. 

 

Напиши в двух словах, можно без кода же. Просто интересна сама идея. 

Ссылка на сообщение
Поделиться на другие сайты

там кроме что ты что то где то сделал и все ок, не какой конкретики. 

 

Напиши в двух словах, можно без кода же. Просто интересна сама идея.

Для чего нужен токен? Для того чтобы через гет не нарезали кучу не нужных картинок, верно?

Так вот если убрать обрезку картинок через гет, и использовать ее через функцию |resize то токен становится не нужным потому как через гет у нас уже не будет работать ресайз, а только через функцию, параметры которая передает в обработчик api/Image.php.

Расширив функцию |resize можно будет применить обрезку к любому объекту (фото бренда, категории, слайдер, прочее), а так же можно будет разделить все по разным папкам не исключая папки для нарезок.

Собственно я это давно уже реализовал, подходил к этому вопросу долго но уверенно.

Надеюсь мое толкование чем-то поможет.

Ссылка на сообщение
Поделиться на другие сайты

Для чего нужен токен? Для того чтобы через гет не нарезали кучу не нужных картинок, верно?

Так вот если убрать обрезку картинок через гет, и использовать ее через функцию |resize то токен становится не нужным потому как через гет у нас уже не будет работать ресайз, а только через функцию, параметры которая передает в обработчик api/Image.php.

Расширив функцию |resize можно будет применить обрезку к любому объекту (фото бренда, категории, слайдер, прочее), а так же можно будет разделить все по разным папкам не исключая папки для нарезок.

Собственно я это давно уже реализовал, подходил к этому вопросу долго но уверенно.

Надеюсь мое толкование чем-то поможет.

 

Можно и так. Но тогда для сайтов с большим количеством товаров очистив папку с миниатюрами и вызвав yandex php можно получить неприятности... Ведь при вызове данного скрипта (+ ему подобных) в 1 вызов мы начнем ресайзить целую тучу картинок. И тут без обрыва по ограничениям - не обойдется. В результате чего могут повреждаться несколько фото.   

 

............................................................

 

Накидал небольшой пример в котором убирается токен и добавляются функции для ресайза других изображений (категории, бренды и тд). Разрешенные размеры хранятся в кеш-файле с миниатюрами. Что позволяет при очистке миниатюр убрать лишние разрешенные параметры с кеш-файла

 

Для того что бы добавить ресайз на другой тип изображений - достаточно добавить строку в config.php в которой будет прописана папка с оригинальными изображениями и имя параметра будет оканчиваться на '_images_dir'

Пример: 

comments_images_dir = files/comments/;

Вызов в шаблоне:
{$image|resize:100:100:true:'comments'}

 

PS: Корс - это лишь для примера. Бестолковые сообщения просьба не писать

resize.zip

Ссылка на сообщение
Поделиться на другие сайты

Вызов в шаблоне:

{$image|resize:100:100:true:'comments'}

Именно так я и сделал у себя в проекте)

Проверял я нагрузку при 400 товаров в каждом из которых сразу ресайзились по 2 картинки (куртка спереди и сзади), ресайз произошел буквально в несколько секунд, конечно же это на опенсервере, на хостинге не тестировал.

Ссылка на сообщение
Поделиться на другие сайты

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

У тебя дубли кода, одних и тех же функций, не проще ли передавать параметр с названием папки, если не передана то используется скажем products а если передана но не существует такая папка то создадим ее?

Также нигде не увидел проверки на существование текущего обрезанного изображения, выходит ресайз работает постоянно при обращении к картинки, она с каждым разом заново ресайзится.

Ссылка на сообщение
Поделиться на другие сайты

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

У тебя дубли кода, одних и тех же функций, не проще ли передавать параметр с названием папки, если не передана то используется скажем products а если передана но не существует такая папка то создадим ее?

Также нигде не увидел проверки на существование текущего обрезанного изображения, выходит ресайз работает постоянно при обращении к картинки, она с каждым разом заново ресайзится.

 

По чистоте кода - я этим не заморачивался.  

Я все это набросал исключительно для примера. 

Даже не тестировал на работоспособность.  

 

А зачем проверка на существование изображения?

Это выполняет htaccess. Если нет файла - выполнить resize.php, а если есть то просто отдается картинка с сервера

Ссылка на сообщение
Поделиться на другие сайты

Именно так я и сделал у себя в проекте)

Проверял я нагрузку при 400 товаров в каждом из которых сразу ресайзились по 2 картинки (куртка спереди и сзади), ресайз произошел буквально в несколько секунд, конечно же это на опенсервере, на хостинге не тестировал.

 

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

Что-то я сомневаюсь, что средний хостинг выдержит ресайз одним скриптом 400 товаров. Особенно если в товаре будет открытие увеличенной картинки через fancybox. И многое зависит от конкретных размеров - делаете Вы ресайз 100х100 или 800х800...

 

...для сайтов с большим количеством товаров очистив папку с миниатюрами и вызвав yandex php можно получить неприятности... Ведь при вызове данного скрипта (+ ему подобных) в 1 вызов мы начнем ресайзить целую тучу картинок. И тут без обрыва по ограничениям - не обойдется. В результате чего могут повреждаться несколько фото.

 

После очистки папки с миниатюрами при вызове yandex.php, когда бывает и по нескольку тысяч товаров с несколькими картинками, особенно если там в ресайзе вдруг поставили особые размеры, ГАРАНТИРОВАННО  скрипт не отработает как надо и поисковик получит полное безобразие со всеми вытекающими последствиями.

 

Так что я бы на месте автора протестировал как следует, а не кое-как локально...

Ссылка на сообщение
Поделиться на другие сайты

Перечитав весь этот бред так и не понял с чего вы взяли что будет нагрузка при большом кол-ве товаров?

Моя реализация работает точно так же как и стоковый ресайз только без токена, с такой же скоростью нарезаются картинки товаров ну может немного быстрее.

Где тут нагрузка? Тем более не будет же сразу одновременно 2-5к товаров открыто на однйой странице вот это да я понимаю будут тормоза.

Ссылка на сообщение
Поделиться на другие сайты

Сделаем иначе, я предлагаю протестировать свою реализацию на нагрузку, вот только не знаю как проверить эту самую нагрузку (буду рад услышать дельные советы).
+ Кто поделится дампом товаров скажем на 2к, главное название и фото (много фото).
Спасибо.

Изменено пользователем Sheeft
Перенесено в соответствующую тему )
Ссылка на сообщение
Поделиться на другие сайты

Возьмем пример:
10000 товаров. Папки с миниатюрами пустые.
будем вызывать yandex.php
 
1) Вариант с ресайзом в ф-и |resize
При выполнении yandex.php там есть строка: 

print "<picture>".$simpla->design->resize_modifier($p->image, 200, 200)."</picture>";

Которая соответственно начнет делать нарезку миниатюр для всех товаров что будут отображаться в yandex.php
Что скорее всего вызовет  Maximum execution time, Allowed memory size и тд
 
2) Через гет. в ф-и |resize формируется лишь имя для get
Через данный способ, яндекс, получит необходимый ему xml быстро и без ошибок по лимитам. 
А сам ресайз будет выполнятся лишь по необходимости. То есть когда будет производится обращение по сгенерированной в xml ссылке. Что соответственно может выполняться часто (пока не нарежутся миниатюры) но быстро (что не вызовет долгого выполнения и соответствующих ошибок)

Ссылка на сообщение
Поделиться на другие сайты

Один треп и никаких реальных цифр и доказательств, то что вы здесь пишите можно назвать битвой экстрасенсов.

Никакой конкретики.

Ссылка на сообщение
Поделиться на другие сайты

Один треп и никаких реальных цифр и доказательств, то что вы здесь пишите можно назвать битвой экстрасенсов.

Никакой конкретики.

 

В посте  #35  yr4ik расписал просто и доходчиво. Я весьма  удивлен, что Noxter не понял...

 

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

 

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

Ссылка на сообщение
Поделиться на другие сайты
  • 1 год спустя...

Идея конечно хорошая, но хоть кто нибудь сможет объяснить мне, зачем картинкам (фоткам) токены?

- сложно парсить? -нет.

- экономит ресурсы? -нет, наверно наоборот.

- может кэшируется лучше или что-то ещё? - ...

Минусы зато сразу бросаются в глаза: при индексации яндексом, он такие фотки просто не сможет проиндексировать правильно, а правильно это так, чтобы они при поиске потом выдавались в выдаче т.к. ваш токен вероятнее всего будет уже другим, хотя бы после сброса кэша (удаление фоток) когда это понадобится. Так в чём же плюс? :huh:

Ссылка на сообщение
Поделиться на другие сайты

Токен - защитный ключ к картинке. Если его не применять, то недоброжелатель, увидев на сайте картинку tov.600x800.jpg, сможет вызвать адреса files/products/tov.600x801.jpg,files/products/tov.600x802.jpg и подобные.  Каждый такой вызов вызовет отработку ресайза и запись нового файла, что может привести к бесполезному расходу дискового пространства, вплоть до исчерпания лимитов...

Кроме того, это также защита от формирования картинки без водяного знака...

Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

 

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

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

 

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

Ссылка на сообщение
Поделиться на другие сайты

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

Очевидно, что связаны.

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

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

Нет. Читайте внимательно, про какой запрос речь...
Ссылка на сообщение
Поделиться на другие сайты

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

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

Ссылка на сообщение
Поделиться на другие сайты

Очевидно, что связаны.

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

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

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

 

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

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

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

 

 

 

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

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

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

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

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

Изменено пользователем a13x
Ссылка на сообщение
Поделиться на другие сайты

 

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

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

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

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

 

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

Apache

PHP5 или PHP6

MySQL 4.1 и выше

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

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

Ссылка на сообщение
Поделиться на другие сайты

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


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

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

Изменено пользователем a13x
Ссылка на сообщение
Поделиться на другие сайты

 

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

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

 

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

 

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

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

 

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

Кстати говоря, класс IMAGE с токеном не работает вообще, работа с ним  идет в других местах.

 

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

 

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

Ссылка на сообщение
Поделиться на другие сайты

 

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

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

 

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

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

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

Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

Загрузка...
×
×
  • Создать...