EPiServer Find is a fast and scalable so 3000 documents will not be an issue at all. I'm struggeling to understand your questoin, can you elaborate?

What do you mean by "anyone can submit content to our Find"?

Hi Mari,

Thanks for your answer. So based on EPiServer Find documentation if someone knows the URL of your website can add or delete a document from our repo (e.g. http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Find/10/DotNET-Client-API/Deleting-documents/) so I'm just worry if I release the address of my EPiServer Find to the client and use JS to fetch data directly from EPiServer find it could have some security problems.

Regards,

You absolutely right, Aria, the Find index URL should never be exposed to the public. The recommended way is to use Find .NET API for search, because it filters search results by access rights, page publish status, language etc. If you want to issue search requests directly to the Find index for some reason, you need a proxy on the CMS server. It is very important to limit access only to the requied types of requests, otherwise data modification or delition requests can go through the proxy. A better approach would be to create a search endpoints on the CMS server and there you can either use .NET API or direct access to the index. You should take care about the publish status, access rights etc yourself in case of direct index requests though.

Thanks Sergii.. I think the same way. I was just curious about what other people thought. I think EPiServer should be protected via password. For example if the URL is revealed you can't protect yourself against any external change and this need to be considered. On the other hand having service means our server need to fetch JSON convert it to .Net object and then convert it back to JSON file. So what I can suggest is to pass a token generated by Find and pass it to client, and with this token user can query Find just for content which that user can see and token is valid for specific amount of time.

Thanks for your contribution

Find index doesn't have information about users rights, current language or any other CMS-specific parameters of the current request. All this information exists only on CMS server side. When you search with Find .NET API it adds filters for all the parameters to the query before sending it to the Find index. Potential overhead of the JSON conversions is not significant in most cases.