RGJ
(Richard - Communiteq)
9월 13, 2024, 5:30오후
1
user_auth_token_logs 테이블에 6,100만 행(그리고 계속 증가 중)이 있는 포럼이 있습니다.
user_auth_tokens는 단 25,000개뿐입니다.
6,100만 행 중 5,400만 행은 더 이상 존재하지 않는 user_auth_token을 참조하고 있습니다(즉, 데이터베이스 무결성 문제). 그리고 6,100만 행 중 약 5,800만 행은 2개월 이상 된 데이터입니다(즉, 쓸모없는 것처럼 보임?).
질문:
추가적인 무결성 문제의 위험 없이 이 데이터를 정리할 수 있을까요?
작업을 통해 이를 자동으로 정리하는 것이 좋은 아이디어일까요?
db=# select count(*) from user_auth_tokens;
count
-------
25648
db=# select count(*) from user_auth_token_logs;
count
----------
61415352
db=# select count(*) from user_auth_token_logs where user_auth_token_id not in (select id from user_auth_tokens);
count
----------
54558442
db=# select count(*) from user_auth_token_logs where created_at < '2024-07-13';
count
----------
58565943
4개의 좋아요
pmusaraj
(Penar Musaraj)
9월 13, 2024, 6:22오후
3
네, user_auth_token_logs는 디버깅 목적으로만 존재합니다. 모든 행을 비워도 되는 결과로, 디버깅할 로그가 남지 않는 것뿐입니다.
이 부분은 다음에서 처리됩니다:
https://github.com/discourse/discourse/blob/main/app/jobs/scheduled/weekly.rb#L13
2개의 좋아요
RGJ
(Richard - Communiteq)
9월 13, 2024, 7:07오후
5
알려주셔서 감사합니다. 그런 설정이 있는 줄 몰랐습니다.
그럼… 클린업은 verbose_auth_token_logging이 true일 때만 실행됩니다(이 인스턴스에서는 해당되지 않음).
하지만 비-verbose 로깅은 설정과 무관하게 항상 수행됩니다
8fb823c 에 따라
이 문제를 #contribute:bug로 이동합니다
4개의 좋아요
pmusaraj
(Penar Musaraj)
9월 13, 2024, 7:45오후
6
아 네, 잘 지적해 주셨네요. 214행에서 217행 도 수정이 필요한 것 같습니다.
일정 기간이 지난 후 전역적으로 정리하는 방식에는 동의합니다. @osama (위에서 링크한 커밋의 작성자이므로) 이러한 로그들을 일정 시간이 지난 후 정리할 수 있다고 생각하시나요? (그렇다면 얼마나 지난 후일까요?) 의심스러운 로그인을 감지하기 위해 일부 로그는 유지해야 하는 것 같습니다.
4개의 좋아요
RGJ
(Richard - Communiteq)
9월 13, 2024, 10:16오후
7
왜 수정이 필요한가요? 해당 코드는 로테이션된 UserAuthToken을 정리하는 것과 관련이 있고, 로그 레코드와는 무관한 것 아닌가요?
업데이트: SiteSetting.verbose_auth_token_logging을 활성화하고 주간 작업을 트리거한 후 VACUUM FULL user_auth_token_logs를 실행하자 테이블이 16GB에서 687MB로 줄었습니다
오늘 나무 몇 그루를 살렸습니다
3개의 좋아요
Osama
9월 16, 2024, 8:15오후
8
네, 대부분의 로그는 정리할 수 있다고 생각합니다. 하지만 일부는 유지해야 합니다. 구체적으로, action이 suspicious, generate, 또는 rotate인 기록은 의심스러운 로그인 탐지 및 관련 보고서 생성에 사용되므로 유지해야 한다고 생각합니다.
title: I18n.t("reports.suspicious_logins.labels.login_time"),
},
]
report.data = []
sql = <<~SQL
SELECT u.id user_id, u.username, u.uploaded_avatar_id, t.client_ip, t.user_agent, t.created_at login_time
FROM user_auth_token_logs t
JOIN users u ON u.id = t.user_id
WHERE t.action = 'suspicious'
AND t.created_at >= :start_date
AND t.created_at <= :end_date
ORDER BY t.created_at DESC
SQL
DB
.query(sql, start_date: report.start_date, end_date: report.end_date)
.each do |row|
data = {}
Math.sin((lat2_rad - lat1_rad) / 2)**2 +
Math.cos(lat1_rad) * Math.cos(lat2_rad) * Math.sin((lon2_rad - lon1_rad) / 2)**2
c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a))
c * EARTH_RADIUS_KM
end
def self.is_suspicious(user_id, user_ip)
return false unless User.find_by(id: user_id)&.staff?
ips = UserAuthTokenLog.where(user_id: user_id).pluck(:client_ip)
ips.delete_at(ips.index(user_ip) || ips.length) # delete one occurrence (current)
ips.uniq!
return false if ips.empty? # first login is never suspicious
if user_location = login_location(user_ip)
ips.none? do |ip|
if location = login_location(ip)
distance(user_location, location) < SiteSetting.max_suspicious_distance_km
end
end
3개의 좋아요
포럼에서 이 버그가 아직 수정되지 않았다는 것을 확인했습니다
의심스러운 로그인 보고서는 스태프에게만 적용되는 것 같습니다. 일반 관리자가 아닌 사용자의 로그를 유지해야 하는 특별한 이유가 있나요?
보고서가 작동하려면 계정 생성 시점부터의 데이터가 필요한가요? 최근 6개월 정도로 로그를 줄일 수 있을까요?
현재는 로그 정리 작업이 전혀 이루어지지 않고 있어, 이는 프라이버시 문제를 일으킬 수 있습니다.
2개의 좋아요
RGJ
(Richard - Communiteq)
8월 8, 2025, 4:31오후
13
위 논의를 저도 이해하지 못하겠습니다.
버그는 매우 단순합니다: verbose 모드가 아니라면 UserAuthTokenLog의 정리 작업이 전혀 수행되지 않습니다. 즉, 영원히 수행되지 않습니다. 해당 if 문은 제거되어야 합니다.
원래 구현은 SiteSetting.verbose_auth_token_logging이 true일 때만 로그를 기록했습니다. 이 경우에도 설정을 비활성화한 후 가장 최근 남은 로그가 그대로 남아있는 문제가 있었지만, 이는 사소한 문제였습니다.
하지만 이 변경 사항 으로 인해 로그 기록이 무조건적으로 수행되게 되었습니다(“generate, rotate, suspicious 인증 토큰 로그는 이제 verbose_auth_token_logging 설정과 관계없이 항상 기록됩니다. ”).
요약하자면, 그 변경 사항에서 삭제 작업도 무조건적으로 수행되도록 하는 것을 놓친 것입니다.
3개의 좋아요
sam
(Sam Saffron)
8월 11, 2025, 2:47오전
14
물론, 앞으로 몇 주 안에 문제를 해결하겠습니다. 급한 일이 있다면, 테스트를 완료하고 의도된 대로 작동하는지 확인된 PR을 보내주세요.
1개의 좋아요
RGJ
(Richard - Communiteq)
8월 13, 2025, 10:05오전
17
pmusaraj
(Penar Musaraj)
8월 14, 2025, 5:13오후
20
실제로, @Osama 덕분에 해당 PR이 이제 병합되었습니다. 이 PR은 user_auth_token_logs의 대부분의 유형을 처리하지만, 모든 유형을 처리하는 것은 아닙니다. 곧 generate 항목에 대한 수정 사항을 후속 처리할 예정입니다. (더 많은 배경 정보는 위 PR 링크의 토론을 참조하세요).
후속 처리가 완료될 때까지 이 주제를 열어 두겠습니다.
4개의 좋아요