Is there an option to disable “Search” for anonymous users? Allow only logged in users to search the forum.. Thanks in advance.
3 Likes
You should hide the search box with CSS. You’d also need to see that Google doesn’t index your site, if you really want people not to be able to find things.
1 Like
Hi, check out this thread Hooks from: & to: syntax in yml to disable anonymous searches - #4 by opcourdis
Adding the line below in your app.yml in the env: section, then ./launcher restart app may be useful even tough I wonder if there is still a way to access contents in another way for anonymous users who may also set a session cookie to pretend to be connected, but I may be wrong.. If anyone has an opinion on this, feel free to share
env:
DISCOURSE_RATE_LIMIT_SEARCH_ANON_GLOBAL_PER_MINUTE: 0
I’m trying that, but direct links to search pages now just return this JSON:
{
"failed":"FAILED",
"message":"You’ve performed this action too many times, please try again later."
}
Is there another way to do it?
The reason that I can’t let anonymous users search the forum is that a sophisticated bot is scraping data with queries like this:
/search?q=%40UserName+%23general+in%3Afirst
It looks like they are mapping users and their content for some kind of data mining task. In order to protect user data, I want to prevent any anonymous access to search. The problem is that there are internal links to search pages, so anyone who isn’t logged in will hit that incorrect JSON message.
I edited the themes so that they can’t find the search box until they log in, but any anonymous user who clicks on existing links to a search result will get the JSON.
They hit the forum with tens of thousands of requests today before I stopped it.
Edit: Claude suggested a Cloudflare security rule to redirect anonymous users who hit search URLs to the signup page. That isn’t ideal, but it will at least take care of it for tonight.
In case anyone wants to try it, here’s the Cloudflare Redirect Rule expression in Rules → Redirect Rules → create rule:
starts_with(http.request.uri.path, "/search") and not http.cookie contains "_t="
Type: Dynamic off / Static URL redirect →
https://forum.your_domain.com/signup, status 302, don’t preserve query string.
1 Like
It’s probably going to reach 100,000 bot hits today. 
Check your own forums for this kind of traffic, because it looks like the kind of thing where they would be scraping a lot of forums for some kind of “people search” data, linking forum usernames and content to real identities.
1 Like
Hi, what I propose here is not related to search function of this topic but do you use a worldwide forum or not ? If not this is very useful GitHub - friendly-bits/geoip-shell: User-friendly and versatile geoblocker for Linux · GitHub and easy to setup & mantain.
Members of your community though have to be aware that if they travel to certain countries they may not be able to reach your site.
Or everyone using a VPN. I think that is a nuclear option with so many consequences, and that is not a workaround for the OP.
There are also plugins:
1 Like
That’s why I asked OP if its a worldwide forum or country level, if you live in Norway and use a European VPN provider there’s no chance for it to show as coming from a remote continent country that the geoip-shell tool would ban.
Ain’t nothing nuclear about it, it depends on the OP situation, let’s see what he says.
@nat and @sam what is your take on this request?
It feels reasonable to me, especially given the traffic I personally see on /search endpoint for anonymous users.
On the other hand, I know the two of you were thinking recently about how to make “Ask AI” available to anonymous users.
On the other (other) hand, perhaps if we’re thinking about configuration of availability, this might be in scope to consider as part of that?
1 Like
This situation is quite unfortunate. As much as I believe search should be available to all, I can also empathise with how much grief this bot is causing. I also find the geo blocking suggestions above very useful as a first line of defence if users are known to be from certain places.
I had considered search_allowed_groups initially, but I think perhaps allow_anonymous_search (defaults true) is better. Doing a group-based feature would make certain internal features that depend on search a bit too gnarly.
With the above, when allow_anonymous_search is disabled, all search features (API/UI) are not allowed for anons. Site setting description is indicated as such.
One thing that I was hesitant on is that while this PR and site setting reason is due to griefing, I wonder if allow_anonymous_search disabled should show still show the search text box (that doesn’t work) and encourage the user to sign up/log in. However, I don’t think that should stop this PR from being merged.
I would also prefer if we don’t conflate other features into this specific request that is scoped to /search for now.
3 Likes
I really hope this feature is available ~~~~~~~~~~~~~~~~
Agree, that would make sense to do. Also agree it shouldn’t block the PR you created here. And you’ve got this bit already, which helps:
When set to false, anons going to
/searchwill be sent to the login page.
Looks sufficient to address this request as a first step.
1 Like
Hey there, this is now merged.
Please update to get the new allow_anonymous_search setting so you can disable it.
3 Likes