Обмеження на розмір завантажуваного файлу (+ тема про помилки)

[gdekjifgb]

Який середньостатистичний розмір, завантажуваної, картинки необхідно встановлювати на стороні сервера (реалізація не в налаштуваннях серверу, а в коді)? Знаю, що це  скажене питання із серії питань Скаженого пана root_x. Але хоч прирблизно на що орієнтуватись?

Обмеження на кількість завантаж файлів на добу вже є. І з кількістю також - безпонііматія. Другий день думаю над цим. Зрозуміло що  ситуація проясниться вже під час функціонування. А  в теорії що і як?

На цьому форумі є  обмеження на кількість завантажуваних файлів?
----

Про помилки: десь поряд є незрозуміла тема про перевірку помилок. Вношу ясність (або додаю не ясності).

У коді є функція/метод який щось виконує. Але спочатку у ньому перевіряються змінні , назвемо їх важливі дані (встановлення, допустимий діапазон значень, довжина... різні перевірки.).  Із нього викликаються інші методи/функції - назвемо їх вкладеними функціями,  У ЯКИХ ТАКОЖ ПЕРЕВІРЯЮТЬСЯ ЦІ САМІ ЗМІННІ. На перший погляд це абсолютний дебілізм.

Але!, є інші місця коду де викликаються оці вкладені функції і без перевірки важливих даних подальше виконання коду неможливе. Такі перевірки* НЕ ЗАЙВІ. Це я розумію. (а в кінці поясню про *).
---

А от коли до бд іде запит на отримання кількості записів, то у моєму коді є перевірка на КІЛЬКІСТЬ РЯДКІВ, ЩО ВЕРНУВ ЗАПИТ. Точніше перевірка на не рівність 1.

Неадекватність такої ситуації в тім що запит на кількість записів в таблиці завжди(?) повинен(?) вертати ОДИН рядок із кількістю записів в таблиці (наприклад самий елементарний каунт: select count(*) from tbl; ).

Не знаю при яких умовах такий запит може вернути не один рядок, але я все рівно перевіряю.


Для чого мені такі не дуже адекватні переперевірки: тому що кількість рядків (в даному випадку 1 рядок в якому міститься кількість записів таблиці) для виконуваного коду становить суттєву важливість.

От і питання: чи в даному випадку такі перевірки доцільні чи ні?
---

Пояснення про * : знаю, що ви можете сказати: якщо в коді таке відбувається, значить в проекті допущено помилки і потрібно все наново обдумати, спроектувати і переписати. Але не завжди так. І то я навів узагальнений приклад.

[Миха́йло Даниле́нко]

Це значення зазвичай робиться змінним (тобто користувач вашого рушія може це змінити в адмінці). Різні потреби — різні значення. Хтось завантажує лише гіфки по 10k, а хтось — равки по 20М.

Є таке поняття як taint — тобто є змінні, що програміст контролює, і змінні, на які впливають дані, отримані ззовні (користувач, мережа, файли). Все, що прийшло від користувача — має пройти untaint (наприклад, перевірку регекспом). Один раз і в чітко визначеному місці. Це визначає безпеку рушія. Ну а те, про що ви говорите (перевірки всередині функцій) — це assertи, що допомагають програмісту відловити свої власні помилки. Відповідно їх ви ставите в залежності від своїх потреб.

Не доцільні, якщо ви не підозрюєте, що ваш драйвер sql містить серйозні баги і не збираєтесь його відлагоджувати. В даному випадку — що ви виграєте від такої перевірки? На якійсь дивній системі, де count() повертає щось незрозуміле ви видаєте помилку. Але якщо count() не повертає один рядок — то є велика вірогідність, що увесь інший sql також працює не так, як ви сподіваєтесь. Як це відслідкувати? Тому краще вкластися в систему тестів, ніж в runtime-перевірки маргінальних випадків.

[gdekjifgb]

. Але якщо count() не повертає один рядок — то є велика вірогідність, що увесь інший sql також працює не так, як ви сподіваєтесь. Як це відслідкувати?

ну тому я і перевіряю. А то раптом щось не так. Тут моя позиція наступна: Якщо із таблиці вибирається пост користувача разом з параметрами доступу до поста, то якщо вибраних рядків НЕ 1, то і показувати нема чого (але це НЕ каунт запит).

Або якщо вибираються тільки параметри доступу для подальшого їх аналізу і якщо запит вернув  не 1 рядок... (знову не каунт запит)
---
Ну в основному згоден (та тут без варіантів(?)):  при зміні структури таблиці (без редагування  запиту) - COUNT(*) запит не буде виконуватись.  АБО буде виконуватись (запити різні бувають) і вертати неправильні результати(?). Замкнуте коло  . Ну мені вже зрозуміліше стало.

Ну я радий що тепер вам стало зрозуміло про що я запитую.

Ну а те, про що ви говорите (перевірки всередині функцій) — це assertи, що допомагають програмісту відловити свої власні помилки. Відповідно їх ви ставите в залежності від своїх потреб.

ааа, згадав. Я про це читав. тільки забув, як воно по науковому, називається.

Все, що прийшло від користувача — має пройти untaint (наприклад, перевірку регекспом). Один раз і в чітко визначеному місці. Це визначає безпеку рушія.

Розумію.

Це значення зазвичай робиться змінним (тобто користувач вашого рушія може це змінити в адмінці). Різні потреби — різні значення. Хтось завантажує лише гіфки по 10k, а хтось — равки по 20М.

У користувачів таких можливостей не буде. Ліміти "прописані в коді" і змінювати може тільки розробник.

Адмінка тільки у мене. можливо іще і у модераторів буде, коли потреба в наявності модераторів виникне.
---

  щось жахливо цікаве я створюю %:))

[Djalin]

А ви впевнені, що юзерів потрібно обмежувати? Можливо тоді взагалі не варто зберігати картинки у себе а використати спеціалізований сервіс?

[gdekjifgb]

А ви впевнені, що юзерів потрібно обмежувати? Можливо тоді взагалі не варто зберігати картинки у себе а використати спеціалізований сервіс?

1 мені приємно що ви долучаєтесь до дискусій. Бо я вже хотів запитувати "чи я тутешнім не набрид?"

2 на початку (поки місце на сервері відносно лімітоване) обов’язково потрібно обмежувати. Тому що якийсь користувач буде спеціально заливати-і-заливати файли на сервер. Поки все вільне місце не займе. Хоч на хостингу дають 10 чи 20 ГБ місця, але все рівно треба (я так вважаю!) мати (вже реалізовану!) можливість встановлювати таке обмеження. Бо потім під час функціонування сайту ХаотичноШвидкоЯкНебудь вирішення проблем призведе до виникнення нових проблем.

2.1 для аналізу ротсту викорстання місця на хотингу також корисно мати хоч якісь обмеження. Навіть якщо це обмеження буде 1024 (кожен ДО 1 МБ) файлів на добу. Маючи такі цифри я можу прогнозувати і робити певні висновки з приводу подальшого розвитку. Що в моїх роздумах не так?

3 мове йдеться про фотоальбоми користувача. Тут використання сторонніх ресурсів не годиться. І на додачу альбоми можуть бути для всіх, для друзів, або зариті.

4 в пости і  коментарі користувача є можливість вставляти зображення по посиланню.

[gdekjifgb]

А ви впевнені, що юзерів потрібно обмежувати?

  На додачу я іще зробив обмеження на кількість подачі заявок в друзі та прийняття в друзі.
Щоб такого https://www.youtube.com/watch?v=puZdAHzmkrc не було.

[Re.]

Або якщо вибираються тільки параметри доступу для подальшого їх аналізу і якщо запит вернув  не 1 рядок... (знову не каунт запит)

Якщо Ви такий параноїк, то просто дописуйте: select count(*) from table limit 1. Але найкраще — підучити принципи роботи рушіїв SQL, допоки не буде впевненості у тому, що може вернути і що не може вернути той чи інший запит. Ваша проблема — банальна технічна безграмотність. Учіться, поки не збагнете, що select count(*) from table не може вернути понад два рядка. До повного просвітлення, як кажуть.

[gdekjifgb]

Якщо Ви такий параноїк,...

маємо, що маємо.

... то просто дописуйте: select count(*) from table limit 1.

Уявіть неможливу ситуацію: запит вернув БІЛЬШЕ ніж один рядок. У тих рядках різні значення. Як визначити чи знизу брехня, чи зверху правда? Повторююсь: маємо, те що маємо.

!!!і я вважаю, що краще (бути скаженим root_x`ом і) робити зайві перевірки (але я в майбутньому трішки зміню підхід до цього), ніж збирати органічне добриво із органічного добрива, як тут(я фото замалював https://itmages.ru/image/view/6140499/34a5bdf4 )

Але найкраще — підучити принципи роботи рушіїв SQL, допоки не буде впевненості у тому, що може вернути і що не може вернути той чи інший запит. Ваша проблема — банальна технічна безграмотність. Учіться, поки не збагнете, що select count(*) from table не може вернути понад два рядка. До повного просвітлення, як кажуть.

Безграмотність є, але не тотальна. Поки що не маю змоги придбати парочку потрібних паперових книг.
---

[Re.]

Книги? Зараз усе так стрімко змінюється, що ці книги не встигли надрукуватись, як уже треба переписувати. Дивіться навчальні відео, як-не-як уже онлайнових курсів завались скільки зʼявилось. А Ви про книги паперові.

[cadca]

Off-topic:

select count(*) from table не може вернути понад два рядка

а так:

Код: [Вибрати]

select count(*) from table ... group by ...?

[gdekjifgb]

...

Мова про простий селект (без group by), що вертає тільки один рядок.

[Cthulhu]

Off-topic:

Книги? Зараз усе так стрімко змінюється, що ці книги не встигли надрукуватись, як уже треба переписувати. Дивіться навчальні відео, як-не-як уже онлайнових курсів завались скільки зʼявилось. А Ви про книги паперові.

+1. Все необхідне є в офіційній документації. Чи в коді, якщо мова про OSS. Чи в гігантській кількості блогів і статей на тему. Чи й, кхм, на stackoverflow. Книги навколоайтішної тематики я купляв лише двічі, і дуже-дуже давно - коли був малий і дурний. Обидві були страшенно нудні, я їх так і не прочитав до кінця, не знаю вже, чим там все закінчилось.