설정에서 입력된 값이 천 단위 구분자로 인해 조용히 손상됩니다

호러 스토리가 시작됩니다.

커뮤니티 매니저 한 명이 우리에게 연락을 주었습니다. 포럼의 사용자 수가 이전처럼 잘 늘지 않고 있다는 것을 발견했기 때문이죠.

조사를 해본 결과, 가입한 지 얼마 안 된 많은 사용자가 비활성으로 판단되어 삭제되고 있다는 사실을 알게 되었습니다.

원인은 clean_up_inactive_users_after_days 설정이 1로 되어 있었기 때문이었습니다. :scream:

그래서 저는 히스토리 아이콘을 클릭해 확인해 보았습니다. 설정이 1년 이상 전 730(2년)에서 1,095(3년)로 변경된 것을 볼 수 있었습니다.

네, 맞습니다. 숫자형 사이트 설정에서 쉼표(또는 비영어권 국가에서 흔히 쓰이는 마침표)를 숫자 구분자로 입력하면, 첫 번째 구분자 이후의 모든 값이 무시됩니다(!). 더糟糕한 것은, 이 문제가 하드 리프레시 후에야 비로소 드러난다는 점입니다.

12개의 좋아요

이처럼 높은 수치를 사용하는 다른 설정들도 같은 방식으로 영향을 받는 건지 궁금합니다. :thinking:

6개의 좋아요

음, 그렇습니다.
모든 숫자형 설정이 영향을 받으며, 많은 수의 일, 분 및 일반적인 고값 설정이 있습니다.

imap_polling_old_emails:1000
decompressed_theme_max_file_size_mb:1000
topic_views_heat_low:1000
secure_uploads_max_email_embed_image_size_kb:1024
maximum_session_age:1440
post_edit_time_limit:1440
composer_media_optimization_image_resize_dimensions_threshold:1920
composer_media_optimization_image_resize_width_target:1920
max_bookmarks_per_user:2000
topic_views_heat_medium:2000
default_other_new_topic_duration_minutes:2880
polling_interval:3000
topic_views_heat_high:3500
max_image_size_kb:4096
max_attachment_size_kb:4096
min_topic_views_for_delete_confirm:5000
max_form_template_content_length:5000
invite_link_max_redemptions_limit:5000
sitemap_page_size:10000
max_notifications_per_user:10000
short_progress_text_threshold:10000
auto_close_topics_post_count:10000
max_drafts_per_user:10000
anonymous_account_duration_minutes:10080
default_email_digest_frequency:10080
tl3_requires_posts_read_cap:20000
anon_polling_interval:25000
max_post_length:32000
tl2_post_edit_time_limit:43200
max_export_file_size_kb:50000
max_bulk_invites:50000
background_polling_interval:60000
decompressed_backup_max_file_size_mb:100000
search_enable_recent_regular_posts_offset_size:200000
default_other_auto_track_topics_after_msecs:300000
max_draft_length:400000
composer_media_optimization_image_bytes_optimization_threshold:524288

  suggested_topics_unread_max_days_old:
  suggested_topics_max_days_old:
  pending_users_reminder_delay_minutes:
  invite_expiry_days:
  purge_unactivated_users_grace_period_days:
  anonymous_account_duration_minutes:
  ignored_users_message_gap_days:
  clean_up_inactive_users_after_days:
  clean_up_unused_staged_users_after_days:
  show_time_gap_days:
  old_post_notice_days:
  returning_users_days:
  suppress_digest_email_after_days:
  disallow_reply_by_email_after_days:
  delete_email_logs_after_days:
  reset_bounce_score_after_days:
  delete_rejected_email_after_days:
  purge_deleted_uploads_grace_period_days:
  tl2_requires_days_visited:
  tl3_requires_days_visited:
  invalidate_inactive_admin_email_after_days:
  send_old_credential_reminder_days:
  search_query_log_max_retention_days:
  cold_age_days_low:
  cold_age_days_medium:
  cold_age_days_high:
  delete_drafts_older_than_n_days:
  delete_merged_stub_topics_after_days:
  default_other_new_topic_duration_minutes:
  retain_web_hook_events_period_days:
  revoke_api_keys_unused_days:
  revoke_api_keys_maxlife_days:
  revoke_user_api_keys_unused_days:
  revoke_user_api_keys_maxlife_days:

7개의 좋아요

리포트 감사합니다, @RGJ! :pray:

정말 위험한 문제였네요. 여기서는 1) UI에서 숫자 입력만 허용하고, 2) 추가적인 안전을 위해 백엔드에서 숫자가 아닌 문자를 제거하는 방식으로 수정했습니다.

11개의 좋아요

다시 열겠습니다. 문제가 되돌아왔을 뿐만 아니라 더 악화되었기 때문입니다.

  • Admin → Settings → Basic Setup → suggested topics로 이동

데스크톱용 Firefox

  • 5.0을 입력한 후 저장(오류 없음) 및 새로고침 → 50으로 설정된 것을 확인
  • 5,0을 입력한 후 저장(오류 없음) 및 새로고침 → 0으로 설정된 것을 확인

iOS용 Safari

  • 5.0을 입력한 후 저장(오류 없음) 및 새로고침 → 50으로 설정된 것을 확인
  • 5,0을 입력한 후 저장(오류 없음) 및 새로고침 → 50으로 설정된 것을 확인
4개의 좋아요

리처드, 보고해줘서 고마워. 확실히 재현할 수 있어.

2개의 좋아요

리포트 감사합니다, 리처드! 말씀하신 내용을 저도 재현해 볼 수 있었습니다. 현재까지 모든 것은 “설계대로” 동작하고 있으며, 다만 파이어폭스에서 5,0이 0으로 변환되는 것은 버그입니다. 꽤 특이한 버그네요.

한 번 더 검토해서, 관리자가 보는 내용이 정확하도록 구분 기호가 포함되지 않도록 업데이트할 필요가 있을 것 같습니다. 현재는 변경 사항을 저장한 후 웹 브라우저를 새로고침해야 변경 내용이 표시됩니다.

하지만 여기서 더 할 수 있는 것들이 있다고 생각합니다. 관리자가 이러한 실수를 하지 않도록, 그리고 혼란을 겪지 않도록 도움을 줄 수 있을 텐데요. suggested topics max days old에 "364.5 days"를 입력하면 3645일로 변환되는 것은 뭔가 잘못된 것 같습니다. 이런 유형의 필드에는 숫자가 아닌 값의 입력을 아예 허용하지 않는 것이 나을지도 모르겠습니다.

6개의 좋아요

이 문제는 FIX: Do not allow , or . in site setting integer input - Pull Request #27618%EC%97%90%EC%84%9C - discourse/discourse - GitHub 수정되었습니다. 이제 해당 필드에 숫자 외의 어떤 값도 입력할 수 없습니다. 더 이상 ,나 . 구분자를 사용할 수 없습니다.

이전에는 정수 사이트 설정에 대한 입력값을 서버 측에서만 정제(sanitize)하고 있었는데, 사용자가 예를 들어 100.5를 입력하면 1005가 되며 UI에 이 결과가 반영되지 않아 다소 혼란스러웠습니다.

이제 이러한 설정에 네이티브 숫자 입력 필드를 사용하므로, 값은 정수만 허용해야 하므로 .이나 ,를 입력하지 못하도록 하고 스텝(step) 크기를 1로 설정하여 사용자 경험을 조금 더 개선할 수 있습니다. 이 네이티브 숫자 입력 필드에서는 다른 모든 문자 입력이 이미 방지되고 있습니다.

6개의 좋아요

이 주제는 3일 후 자동으로 닫혔습니다. 더 이상 새 답글을 작성할 수 없습니다.