2023년 iOS 16 웹 푸시 알림

dfabulich · 12월 27, 2023, 8:04오후

이것은 거의 확실하게 Discourse 쪽의 문제입니다. 사이트 사용 후 특정 분수가 지나면 알림을 보내지 않기 때문이죠. 하지만 일반 사용자는 이를 확인할 방법이 없어서, 결국 알림을 신뢰할 수 없게 만듭니다. 다만 두 메시지에 대해 iOS 푸시 알림을 모두 받았다는 점은 확신합니다. 절대 신뢰하지 말아야 한다는 것을 안다면, 이 알림들은 제대로 작동합니다.

jtbayly · 12월 27, 2023, 9:16오후

문제는 반대인 것 같아요. 최근 휴대폰으로 사이트를 충분히 자주 사용하지 않으면 알림 수신 자체가 중단되는 것 같습니다.

dfabulich · 12월 27, 2023, 9:38오후

아마도 그럴 수 있지만, 우리 모두 추측만 하고 있을 뿐입니다. 우리가 가장 필요로 하는 것은 Discourse가 최종 사용자에게 적절한 로그를 제공하는 것입니다. Discourse는 어떤 알림을 보냈고, 어떤 알림을 보내지 _않았_나요?

PWA가 알림을 수신하면, 해당 내용을 기기의 IndexedDB에 로컬 로그로 기록할 수 있습니다. 사용자는 이 로그를 확인하고 서버 로그와 대조하여, Discourse가 푸시를 보냈지만 기기가 수신하지 못한 시점을 파악할 수 있어야 합니다.

하지만 전반적으로 말하자면: 문제를 Apple의 탓으로 돌리지 마시고, 특히 iOS 18을 기다리면 해결될 것이라고 가정하지 마십시오. Discourse 측에서 작업을 수행해야만 상황이 나아질 수 있습니다.

sam · 12월 27, 2023, 10:40오후

이것은 제 생각에 매우 매우 자세한 로깅 같습니다:

github.com/discourse/discourse

app/services/post_alerter.rb

cacaa90f4


      
          def self.push_notification(user, payload)
            return if user.do_not_disturb?
          
            if DiscoursePluginRegistry.push_notification_filters.any? { |filter|
                 !filter.call(user, payload)
               }
              return
            end
          
            if user.push_subscriptions.exists?
              if user.seen_since?(SiteSetting.push_notification_time_window_mins.minutes.ago)
                delay =
                  (SiteSetting.push_notification_time_window_mins - (Time.now - user.last_seen_at) / 60)
                Jobs.enqueue_in(delay.minutes, :send_push_notification, user_id: user.id, payload: payload)
              else
                Jobs.enqueue(:send_push_notification, user_id: user.id, payload: payload)
              end
            end

여기서 자세한 로그를 남기는 것은 아마도 충분히 쉬울 것입니다:

github.com/discourse/discourse

app/jobs/regular/send_push_notification.rb

cacaa90f4


      
          user = User.find_by(id: args[:user_id])
          if !user || user.seen_since?(SiteSetting.push_notification_time_window_mins.minutes.ago)
            return
          end

“샘이 온라인 상태였기 때문에 'payload’에 대한 알림을 건너뛰었습니다.”

하지만 이것을 디버깅하고 싶을 뿐이라면 SiteSetting.push_notification_time_window_mins을 0으로 설정하면 어떨까요?

그리고 다음 수준의 로깅은 매우 매우 자세해집니다:

사용자가 '방해하지 마세요’를 활성화했기 때문에 알림을 건너뛰었습니다
푸시 알림 제공자 타임아웃 discourse/app/services/push_notification_pusher.rb at cacaa90f4d01452358322ea8b5564f15f4816c74 · discourse/discourse · GitHub
만료된 구독
응답 오류

많은 것들이 잘못될 수 있습니다… 하지만 어떤 시점에서도 DE를 사용하여 검증할 수 있습니다: 최신 웹 푸시 구독을 찾기 위해 push_subscriptions 테이블을 살펴보세요.

dfabulich · 12월 27, 2023, 11:58오후

먼저 제 관점에서 보면, 문제는 사람들이 이곳이나 제 포럼에 "푸시 알림이 제대로 작동하지 않는 것 같다"고 글을 올리고, 다른 사용자들도 "맞아요! 저한테도요! 알림이 고장 났거나 불안정한 것 같아요"라고 동조한다는 점입니다. 때로는 Apple을 탓하고, 때로는 Discourse를 탓하지만, 모두 Discourse의 푸시 알림이 신뢰할 수 없다고 동의합니다.

저는 "당신의 폰에 오후 12:31에 알림이 오지 않았는데, 그 이유는 다음과 같습니다…"라고 설명하면서 이러한 사례를 직접 _조사_할 수 있기를 원합니다. 하지만 현재로서는 그것이 불가능하다고 생각합니다.

네, 많은 다른 문제들이 발생할 수 있으며, 여기에는 제가 DE(개발 환경)에서 조사할 수 없는 클라이언트 측 문제들도 포함됩니다.

Service Worker가 push 이벤트를 수신했나요?
Service Worker가 showNotification을 호출했나요?
showNotification 권한이 부여되었나요, 아니면 showNotification이 아무 효과도 없었나요?
기기 자체가 ‘방해 금지’ 모드로 설정되어 있었나요?

최소 알림이 전송되었는지 확인하는 범위에서, 푸시 실패를 진단하기 위해 DE를 사용하는 방법에 대해 관리자를 위한 문서를 갖고 싶을 정도입니다.

하지만 사용자가 저에게 보낼 수 있는 클라이언트 측 로그를 유지하여, 제가 DE 로그와 대조할 수 있게 하는 것도 매우 도움이 될 것이라고 생각합니다.

그 중 하나는, 이 문제에 대해 불만을 제기하는 사람들의 절반 이상이 포럼의 관리자가 아니라는 점입니다. 그래서 Discourse가 이를 구현해야 합니다:

하지만 네, 이 값을 0으로 설정하면 "작동하지 않는다"는 불만의 80%는 사라질 것이라고 추측합니다.

전반적으로, Discourse 알림에 대한 사용자 신뢰도는 상당히 낮습니다. 이 문제가 관리자(심지어 최종 사용자)를 위해 연구 가능한 정도가 높을수록, Discourse 알림은 더 신뢰할 수 있게 될 것입니다.

sam · 12월 28, 2023, 4:58오전

이 부분에 대해 조금 혼란스럽습니다. 서버에서 URL로 직접 push를 보내고 있는데…

dfabulich · 12월 28, 2023, 5:34오전

제 추론은 다음과 같습니다. 이 스레드에서 사용자들이 어떤 말을 하고 있는지 살펴보세요.

이 게시물들은 문제가 Apple의 탓일 수 있음을 시사하는 것 같습니다. 아마 Discourse가 URL로 푸시를 보내고 있지만, 어떤 이유로든 Apple이 푸시를 전달하지 못하는 것일 수 있습니다. 그럴 수 있는 이유는 무엇일까요?

Apple이 푸시 작업에 4xx 또는 5xx를 반환하고 있고, Discourse가 다시 푸시해야 하는 경우.
Apple이 메시지를 받았지만, 기기에 메시지를 전달할 수 없거나(또는 원치 않거나?) 하는 경우.
기기가 메시지를 받았지만, Apple이 서비스 워커의 push 이벤트를 발생시키지 않는 경우.
서비스 워커가 push 이벤트를 받았지만, 버그로 인해 showNotification을 호출하지 않은 경우 (아마 이 경우는 아닐 것 같습니다. 너무 자명하니까…?)
서비스 워커가 push 이벤트를 받고 showNotification을 호출했지만, Apple이 표시 가능한 알림을 표시하기를 거부한 경우. 실제로 이렇게 될 수 있는 이유는 많습니다:
- 기기가 방해 금지(Do Not Disturb)로 설정되어 있는 경우 (이 경우 알림은 결국 알림 센터에 표시되어야 한다고 생각합니다)
- 권한이 언젠가 부여되었지만, 지금은 철회된 경우 (PWA는 이 경우를 감지하고 로그를 기록할 수 있습니다!)
- 사용자가 앱의 알림 설정을 기이하게 구성하여, 알림 센터에만 푸시하고 배너는 표시하지 않도록 한 경우
- … 또는 Apple이 다른 정책상의 이유로 메시지를 표시하기를 거부하는 경우 (알림이 스팸이라고 생각할 수도 있고?), 아마도 향후 iOS 버전에서 더 관대해질 수도 있습니다.

이것조차도 Discourse 자체가 알림을 보내지 않을 수 있는 이유(방해 금지, 푸시 필터, push_notification_time_window_mins)를 고려한 것이 아닙니다.

우리가 할 수 있는 말이 "음, 오후 12:31분에 Discourse가 ID XXX인 알림을 Apple에 발사했고, Apple은 201 Created 상태 코드를 반환했지만, 그 이후에 무슨 일이 일어났는지는 전혀 알 수 없다"에 그친다면, 이 사용자/관리자들은 더 이상 조사할 방법이 없게 됩니다. 결국 Apple을 탓하고 푸시 알림을 포기하게 될 것입니다. (“아마 2024년에 나올 iOS 18 웹 푸시 알림이 해결해 줄지도 모르겠네요.”)

대신, "기기의 로그를 보면 오후 12:33분에 서비스 워커가 ID XXX 알림의 푸시 이벤트로 깨어났고, showNotification을 발사했으며, Notification API를 통해 해당 XXX 푸시에 대한 showNotification 권한이 부여되었다는 것을 Apple이 말하고 있음을 볼 수 있다"고 말할 수 있어야 합니다.

(또한 https://meta.discourse.org/my/preferences/notifications 페이지에 “테스트 알림 보내기” 버튼이 있어야 한다고 생각합니다. 이 버튼은 알림을 _예약_할 수 있게 해주며, 예를 들어 N분 또는 N시간 후의 알림을 예약할 수 있어 사용자가 "몇 시간 후에는 작동하지 않는다"는 경우를 테스트할 수 있게 해줍니다.)

WorldIsMine · 12월 28, 2023, 7:44오전

제 쪽에서는 스테이징 사이트에서 이 문제를 재현할 수 없었습니다. 스테이징 사이트에서는 알림이 문제없이 작동합니다. 문제는 제 프로덕션 사이트입니다. 알림을 활성화할 때마다 몇 시간 안에 알림이 작동하지 않게 됩니다. 제 유일한 추측은 푸시 알림의 양이 문제일 수 있다는 것입니다. 제 프로덕션 사이트는 매우 활발하게 운영되며 5만 명 이상의 회원이 있어 제 사용자 계정(그리고 전반적으로)에 많은 알림이 발송되고 있습니다.

RGJ · 12월 30, 2023, 11:49오전

그래서 @WorldIsMine와 저는 작은 실험을 해 보았습니다.

그의 알림이 작동하지 않을 때까지 기다렸습니다.
그의 푸시 구독이 여전히 push_subscriptions 테이블에 있는지 확인했습니다
rails 콘솔에서 푸시 알림을 보내고 모든 예외를 기록하도록 했습니다.

u = User.find(1)
payload = { excerpt: "Test", "translated_title": "Test!" }
PushNotificationPusher.push(u, payload)

예외는 발생하지 않았습니다.
그는 알림을 받지 못했습니다.
(재확인하기 위해, 저는 제 자신에게 푸시 알림을 보낼 수 있었습니다)

그러면 이것은 Apple 쪽의 문제인가요? 무엇이 문제일 수 있을까요?

dfabulich · 12월 30, 2023, 3:42오후

macOS Safari에서 테스트할 수 있는 Mac에 접근할 수 있나요? 그렇게 하면 개발자 도구를 설정하여 서비스 워커를 디버깅할 수 있습니다.

RGJ · 12월 31, 2023, 12:31오전

제 이해로는 여기에는 서비스 워커가 관여되어 있지 않습니다.

dfabulich · 12월 31, 2023, 12:32오전

아니요, iOS에서는 모든 웹 푸시 알림에 서비스 워커가 필요합니다. Sending web push notifications in web apps and browsers | Apple Developer Documentation

RGJ · 12월 31, 2023, 12:40오전

음, 제 수준을 넘어서는 것 같네요. 불행히도 클라이언트 쪽에서는 이 분야에 경험이 없고, 사용할 수 있는 Mac도 없습니다.

적어도 서버 쪽 문제는 제외할 수 있게 되었네요.

dfabulich · 1월 1, 2024, 11:36오후

아하! 이 문제와 관련된 버그를 적어도 하나 찾아냈다고 생각합니다. 별도 스레드에 등록해 두었습니다.

사용자가 활성 상태일 때 iOS 알림의 푸시 권한이 해제될 수 있습니다 Bug

iOS의 경우, 알림이 억제(suppressed)되면 푸시 권한을 잃을 수 있습니다. Discourse의 코드는 알림을 선택적으로 억제하도록 구성되어 있으며, 이 상황이 세 번 발생하면 푸시 권한이 취소됩니다. 다음은 푸시 알림 서비스 워커의 코드입니다. 이 코드에는 178번째 줄에 치명적인 버그가 있습니다. 해당 부분에서 서비스 워커는 사용자가 활성 상태(즉, 유휴 상태가 아님)인지 확인합니다. 사용자가 활성 상태인 경우, 알림을 표시하지 않고 푸시 이벤트가 false를 반환합니다. (또한 payload.hide_when_active를 확인하지만, hide_when_active는 항상 true인 것으로 밝혀졌으며, 따라서 사용자가 활성 상태일 때 이 코드는 항상 false를 반환합니다.) Apple은 조용한 푸시를 금지하며, 알림을 표시하지 않는 이벤트가 3회 발생하면 푸시 권한을 취소합니다 이는 Apple의 푸시 알림 규칙에 따라 허용되지 않습니다. https://w…

sam · 1월 8, 2024, 9:58오후

수정이 문제를 개선하길 바랐지만, 확신할 수 없습니다.

Meta는 이 수정 사항을 적용한 지 일주일째입니다. iPhone PWA에서 라이브 알림을 활성화했는데, 오늘 갑자기 작동이 멈췄습니다.

이 기능은 1월 5일에 생성되었습니다.

무엇이 문제를 일으키는지, 그리고 그 상태가 얼마나 지속되는지 확인하기 위해 스크립트로 디버깅을 시도해 보겠습니다. 하지만 여러 가지 정황을 볼 때, 이는 단순히 Apple 쪽의 버그인 것 같습니다.

이 문제를 더 생각할수록, Apple 기기에 대한 해결책은 이제 Discourse Hub라는 생각이 듭니다.

jtbayly · 1월 8, 2024, 10:17오후

이 문제를 추적해 주셔서 감사합니다!

알림을 클릭해 본 적이 있나요? 특정 수의 알림을 받은 후 그중 하나도 클릭하지 않으면 Apple이 웹 알림을 자동으로 끄는 것이 아닌가 해서 여쭤봅니다.

dfabulich · 1월 8, 2024, 11:39오후

실패를 분석하기 위해 여전히 다음 기능들이 필요합니다:

푸시 알림 내역을 확인하기 위한 데이터 탐색기(Data Explorer) 사용 방법 안내.
서버 측 로그와 상관 관계를 파악할 수 있도록 추출할 수 있는 온디바이스(기기 내) 로그.
로그에는 전체 페이로드를 포함한 모든 push 이벤트의 타임스탬프, 그리고 Notification.permission 상태가 포함되어야 합니다.
N분/시간 후 알림을 큐에 추가하는 “테스트 알림 보내기” 버튼.

sam · 1월 25, 2024, 3:44오전

참고로, 지난 3주간 메타에서 PWA 알림이 안정적으로 작동하고 있습니다.

nathank · 2월 9, 2024, 11:11오후

여기에는 이 분야에서 더 큰 문제가 발생할 것임을 시사하는 불안한 업데이트가 있습니다:

Nick_Chomey · 2월 22, 2024, 4:18오후

참고로, @nathank 님이 위에서 보고한 뉴스는 애플에 의해 완전히 확인되었습니다.

유럽연합(EU)의 디지털시장법(DMA)은 디지털 플랫폼에 더 많은 개방성과 경쟁을 가져오려는 것이 목적이지만, 애플은 이 법을 악의적으로 준수하는 척하면서 EU 내 PWA(Progressive Web App)를 제거하기로 결정했습니다. 곧 출시될 Safari iOS 17.4에서 이를 실행할 예정입니다.

이로 인해 PWA를 홈 화면에 설치하는 것, 푸시 알림 사용, 백그라운드 동기화 등이 차단되고 오프라인 저장소 등에도 지장이 생길 것입니다. EU의 iPhone 사용자들이 이를 사용할 수 없게 되면 기업들이 웹 앱, 특히 PWA에 대한 투자를 훨씬 덜 하게 될 것이므로 EU를 넘어 전 세계적으로도 영향을 미칠 것입니다.

이는 많은 Discourse 커뮤니티와 Discourse 자체에 큰 장애물이 될 것으로 생각합니다. 만약 여러분에게도 해당된다면, Open Web Advocacy(OWA) 그룹의 이 설문조사에 응답해 주시기를 강력히 권고합니다. OWA는 이에 맞서 싸우고 있으며, 이러한 정책들이 웹 개발에 미치는 모든 영향을 DMA 팀에 알리는 데 주력하고 있습니다. 그들은 이러한 변화로 인해 영향을 받는 기업들의 증언과 데이터를 시급히 수집하여, DMA가 이에 맞서 싸울 수 있도록 더 나은 정보를 제공하려 하고 있습니다.

자세한 내용을 알고 싶고, 이 변화가 여러분의 비즈니스에 어떤 영향을 미치는지 설문조사에 응답하며 이 소식을 널리 퍼뜨려 주십시오. 특히 Discourse가 사용자에게 다가오는 변화에 대해 알릴 수 있다면, 각 사용자가 OWA에 연락하여 이 변화가 그들의 비즈니스와 커뮤니티에 어떻게 영향을 미치는지 설명할 수 있을 것입니다.

글		댓글	조회수
iOS Mobile App Notifications Product Support	53	10227	6월 7, 2022
Push notification settings - iOS Product Support	2	616	8월 4, 2023
Discourse offers to enable live notifications on macOS Safari 16, but they don't work Bug push-notifications	7	1186	2월 15, 2023
iOS/Android Push Notifications on Self-Hosted Discourse (Docker) Product Support notifications , push-notifications , ios	17	825	4월 14, 2026
Push Notifications Not functioning Product Support	22	3771	5월 3, 2019

2023년 iOS 16 웹 푸시 알림

Related topics