익명 사용자의 “검색” 기능을 비활성화할 수 있는 옵션이 있나요? 로그인한 사용자만 포럼 검색을 사용할 수 있도록 하고 싶습니다. 미리 감사드립니다.
2개의 좋아요
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개의 좋아요
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
이 방법을 시도해 보고 있는데, 이제 검색 페이지로 직접 연결하면 다음과 같은 JSON만 반환됩니다:
{
"failed":"FAILED",
"message":"You’ve performed this action too many times, please try again later."
}
다른 방법이 있을까요?
익명 사용자의 포럼 검색을 허용할 수 없는 이유는, 다음과 같은 쿼리를 사용하여 데이터를 수집하는 정교한 봇이 존재하기 때문입니다:
/search?q=%40UserName+%23general+in%3Afirst
이들은 어떤 종류의 데이터 마이닝 작업을 위해 사용자들과 그들의 콘텐츠를 매핑하는 것으로 보입니다. 사용자 데이터를 보호하기 위해 검색에 대한 익명 액세스를 차단하려고 합니다. 문제는 검색 페이지로 이어지는 내부 링크가 존재하기 때문에 로그인하지 않은 모든 사용자가 그 잘못된 JSON 메시지를 받게 된다는 것입니다.
검색 상자를 로그인할 때까지 찾을 수 없도록 테마를 수정했지만, 검색 결과로 이어지는 기존 링크를 클릭하는 익명 사용자는 여전히 JSON을 받게 됩니다.
오늘 제가 이를 차단하기 전에 이 봇은 포럼에 수만 건의 요청을 보냈습니다.
수정: Claude가 검색 URL에 접근하는 익명 사용자를 가입 페이지로 리디렉션하는 Cloudflare 보안 규칙을 제안했습니다. 이것이 이상적인 해결책은 아니지만, 적어도 오늘 밤까지는 이 문제를 처리할 수 있을 것입니다.
시도해 보고 싶은 분을 위해, Rules → Redirect Rules → create rule에서 사용할 Cloudflare Redirect Rule 식별자를 여기에 공유합니다:
starts_with(http.request.uri.path, "/search") and not http.cookie contains "_t="
유형: Dynamic off / Static URL redirect →
https://forum.your_domain.com/signup, 상태 302, 쿼리 문자열 유지하지 않음.
1개의 좋아요
오늘 봇 접근 횟수가 100,000회를 넘길 것 같습니다. 
이런 종류의 트래픽은 직접 포럼에서 확인해 보세요. 특정 “사람 찾기” 데이터를 위해 수많은 포럼에서 스크래핑을 하고, 포럼 사용자 이름과 콘텐츠를 실제 신원과 연결하려는 시도로 보입니다.
1개의 좋아요
안녕하세요, 여기서 제안하는 내용은 이 주제의 검색 기능과는 관련이 없지만, 전 세계적으로 포럼을 운영하고 계신가요? 아니라면 GitHub - friendly-bits/geoip-shell: User-friendly and versatile geoblocker for Linux · GitHub 이 매우 유용하며, 설정과 유지보수도 쉽습니다.
다만 커뮤니티 회원들은 특정 국가로 여행할 경우 해당 사이트 접근이 불가능할 수 있다는 점을 인지해야 합니다.
또는 VPN을 사용하는 모든 사람들입니다. 저는 이것이 너무 많은 결과를 초래하는 핵옵션이라고 생각하며, 이는 OP(원문 게시자)를 위한 해결책이 아닙니다.
플러그인도 있습니다:
1개의 좋아요
그래서 OP에게 전 세계 포럼인지 국가 단위인지 물어본 거예요. 노르웨이에 거주하면서 유럽 VPN 제공사를 사용한다면, 그 VPN이 원격 대륙 국가에서 온 것으로 보이게 될 가능성은 없어요. geoip-shell 도구가 차단할 수 있는 그런 국가에서 말이죠.
핵옵션 같은 건 없어요. OP의 상황에 따라 달라지니까, 뭐라고 할지 한번 들어봅시다.
@nat님, @sam님, 이 요청에 대해 어떻게 생각하시나요?
개인적으로 /search 엔드포인트에서 익명 사용자가 생성하는 트래픽을 직접 확인해 본 입장에서, 이 요청은 합리적으로 느껴집니다.
한편, 두 분께서 최근 익명 사용자에게 “AI에게 질문하기” 기능을 어떻게 제공할지에 대해 논의하고 있다는 것도 알고 있습니다.
다른 한편(또 다른 관점에서)으로, 가용성 설정을 고려하고 있다면, 이것이 해당 논의의 _일부_로 포함될 수 있는 범위에 해당하지 않을까 싶습니다?
1개의 좋아요
이 상황은 꽤 불행합니다. 검색 기능이 모든 사용자에게 제공되어야 한다고 믿지만, 이 봇으로 인해 얼마나 큰 혼란이 발생하고 있는지 공감할 수 있습니다. 또한, 사용자가 특정 지역에서 온 것으로 확인되는 경우, 위에 언급된 지오토킹(geo-blocking) 제안은 1차 방어선으로 매우 유용하다고 생각합니다.
처음에는 search_allowed_groups를 고려해 보았지만, allow_anonymous_search(기본값 true)가 더 나을 것 같습니다. 그룹 기반 기능을 구현하면 search에 의존하는 일부 내부 기능이 지나치게 복잡해집니다.
위와 같이 allow_anonymous_search가 비활성화되면, 모든 검색 기능(API/UI)이 비로그인 사용자에게 허용되지 않습니다. 사이트 설정 설명에도 이를 명시합니다.
고민이 되었던 점은, 이 PR과 사이트 설정의 이유가 괴롭힘(griefing) 때문이긴 하지만, allow_anonymous_search가 비활성화되었을 때 검색 텍스트 상자(작동하지 않는)를 여전히 표시하여 사용자가 가입/로그인하도록 유도해야 하는지 여부입니다. 그러나 이것이 이 PR의 병합을 막아야 한다고 생각하지는 않습니다.
아직 /search 범위로 한정된 이 특정 요청에 다른 기능을 혼합하지 않는 것이 좋겠습니다.
3개의 좋아요
이 기능이 있었으면 좋겠어요～～～～～～～～～～～～～～～
동의합니다. 그렇게 하는 것이 합리적일 것 같습니다. 또한, 여기에서 생성한 PR을 차단해서는 안 된다는 점에도 동의합니다. 그리고 이미 이 부분이 있으므로 도움이 됩니다:
false로 설정하면,
/search로 이동하는匿名用户는 로그인 페이지로 리디렉션됩니다.
첫 단계로서 이 요청을 해결하기에 충분해 보입니다.
1개의 좋아요