How to protect content from parsing with Nginx?

Question

Nginx

Good afternoon!
Is it possible to protect content from parsing if client folders are named as user id? For example, checking by token or folder by alias?

Answer 1

The main protection against parsing is only when accessing authorization data and setting limits on data (the amount available to the user or for a certain period of time, for example, a day / month).
Anonymously accessible data, in general, cannot be protected from being uploaded by users. Everything that the user sees on the screen can be stupidly copied and analyzed.
In some cases, if you collect a high-quality browser fingerprint, you can assign a certain identifier to anonymous users and, based on it, set data access limits on the backend, but as always, difficulties are in the details and if you overdo it, you can interfere with the work of legitimate users.
You can put a 'stick in the wheel' by making this process more difficult (and more expensive), mainly obfuscation / encryption of data available directly (via api) from the backend and obfuscation of the code, converting it into user-visible content, so that classic (cheap) tools didn't work. As always, the cost of protection (development costs) should be comparable to the costs of grabbers for obtaining data (usually it is easier for them).
Unfortunately , along with the content grabber, search engine robots will be misled , because their main job is to rob content.

spoiler

* api не должен быть простым и интуитивно понятным, идентификаторы могут вообще не быть постоянными (их можно преобразовывать на бакэнде на основе данных в сессии)
* код javascipt, например получения ссылки на объект должен быть нетривиальным, т.е. чтобы получить следующую ссылку на требуемый граберу объект, потребовалось бы использовать сам браузер (а не простенький скрипт парсер html)
* верстка может быть непостоянной, изменяющиеся, простые гуляющие наименования классов и идентификаторов уже могут создать кучу проблем (я такое встречал), а уж постоянное изменение структуры должно совсем запудрить голову даже опытным граберам (не встречал)
* шрифт может не являться правильным (видимые символы могут не соответствовать их кодам), при этом генерируемый каждый раз новый под конкретную сессию пользователя. Простая подстановка, сильно усложнит (но не сделает невозможной) получение данных через буфер или document.innerText в консоли браузера, оставив граберу только вариант распознавание экрана скринридером (а не тривиальная верстка потребует от пользователя сложную настройку и автоматизацию и эти инструменты)
* типовые javascript методы браузера должны быть замещены на 'неправильно работающие', чтобы граберу пришлось использовать внешние скрипты а не простой инжект javascript (обычно это сильно упрощает).

Answer 2

There is no need to assign the task of protecting against parsing to nginx, it was not created for this.
You need to defend yourself on the back

Answer 3

I can recommend a report from 2GIS and their version of writing a lua module for nginx (opernresty)
https://www.youtube.com/watch?v=pYxnW7kYcbU
The report is at least useful in that it contains useful information on how to detect parsers and what to do with it.

Answer 4

In short - no way.