왜 FCM을 사용하지 않고 APNs를 사용하게 됐는가?  AIOAPNS 패키지를 사용해서 APNs로 푸시 메시지를 발송 기능을 구현해야 할 일이 생겼다. 일반적인 경우 푸시 메시지를 발송할 일이 있다면 FCM을 사용해서 iOS/안드로이드 양쪽으로 푸시 메시지를 발송하게 되는데, 이번에는 FCM 토큰 유효기간으로 인한 의구심이 들었다. 파이어베이스 문서에 명시되어있는 비활성 토큰은 다음과 같다. 270일간 활동이 없으면 만료된 토큰으로 간주한다는 얘기인데, 이 '활동'이 푸시 메시지를 수신한 것을 의미하는지, 아니면 푸시 메시지를 수신한 이후 사용자가 아무런 반응을 보이지 않은 것인지 분명하지 않다. 비활성 등록 토큰은 FCM에 1개월 넘게 연결되지 않은 비활성 기기와 연결된 토큰입니다. 시간이 지날수록 ..

https://github.com/olucurious/PyFCM GitHub - olucurious/PyFCM: Python client for FCM - Firebase Cloud Messaging (Android, iOS and Web)Python client for FCM - Firebase Cloud Messaging (Android, iOS and Web) - olucurious/PyFCMgithub.com   PyFCM을 사용해서 Push Notification을 전송하도록 했는데, PyFCM은 문서화가 잘 되어있지 않은건지, 아니면 언어 특성상 알아서 잘 쓰면 되는건지 에러 관련해서 처리하는 방법을 찾아볼 수가 없었다. Python을 사용한 Firebase Cloud Message를 찾아보면..

참고: HTTP_SSL_MODULE 문서 페이지 Nginx - Disable SSL, TLS 1.0, and TLS 1.1 Nginx에서 TLSv1과 TLSv1.1을 비활성화하는 방법 오늘은 NGINX에서 TLSv1, TLSv1.1을 비활성화하는 방법에 대해 살펴보겠다. 는 NGINX에서는 간단하게 아래와 같이 ssl_protocols값만 설정해주면 끝난다. 참고로 TLSv1.3은 OpenSSL 1.1.1 이상의 버전이 설치되어있을때만 사용 가능하며, 그 이하의 버전이 설치되어있는 경우에는 에러가 출력된다. 이럴 때는 OpenSSL을 업데이트해주거나 혹은 과감하게 TLSv1.3을 빼주도록하자. 보안보다는 퇴근이 우선이다 ssl_protocols TLSv1.2 TLSv1.3 몹시 간단하게 끝났는데, 이렇게..

OpenResty, NGINX Cross-compile에 대하여 임베디드 시스템에 OpenResty를 사용한 이후로, 칩셋이 변경될 때마다 크로스 컴파일을 다시 해줘야했다. 문제는 기반지식이 전혀 없는 상태인데다, 인수인계 문서의 거의 내용도 없었다. NGINX 자체를 크로스컴파일 하는 경우는 종종 있지만 OpenResty를 크로스컴파일하는 글은 찾기 어려웠다. 이전에도 작성했듯이 scratchbox2, qemu와 같은 툴로 환경을 설정해주면 간단하게 끝나는 일이다. 문제는 toolchain 형태로 제공되는 컴파일러의 경우, scratchbox2를 사용해서 환경설정을 하게되면 에러가 발생한다. 예를 들면 심볼릭 링크를 인식하지 못해서 컴파일러가 동작하지 않는다던가. 애석하게도 작년에 크로스컴파일을 마지막..

Cross-Origin Resource Sharing와 Access-Control-Allow-Origin 우선 CORS에 대해서는 CORS, Cross-Origin Resource Sharing - MDN Web Docs 페이지를 읽어보도록하자. 예를 들어 A서버에서 제공하는 웹 서비스에서 B서버의 리소스를 요청하면, 엥? 나 A에서 제공하고 있는 서비스인데, 너한테 뭐 좀 요청해도 되니?하고 B서버에게 물어본다는 얘기다. 이렇게 B서버에게 요청을 보낸 뒤 돌아온 응답 헤더에 Access-Control-Allow-Origin값을 보고 사용자한테 요청을 할지 말지 알려주게되는데, 웹을 만지다보면 프론트건 백엔드건 한번쯤 겪게되는 문제다. 간단하게 말하면 서버단에서 응답 헤더에 Access-Control-A..

Spawn-fcgi의 크로스 컴파일에 대하여 spawn-fcgi는 nginx에서 다른 라이브러리를 사용하지 않고 fcgi를 돌릴 때 필요한 아이로, fcgi를 프로세스 단위로 실행해주는 녀석이다. 이 녀석을 사용하여 fcgi를 실행한 뒤, nginx에서 proxy-pass해주면 fcgi를 이용하여 통신하는 것이 가능해진다. OpenResty/NGINX를 크로스 컴파일 할 때와 마찬가지로, QEMU나 Scratchbox와 같은 툴로 에뮬레이터 환경을 구축한 뒤 컴파일하면 아무런 설정 없이 컴파일이 가능하다. Scratchbox와 QEMU에 대해서는 OpenResty/NGINX의 크로스 컴파일 할 때 알아봤으므로, 이번에는 설명을 생략하도록 하겠다. configure를 통한 설정 Scratchbox와 QEM..