Faraday::SSLError (SSL_read: 읽는 중 예상치 못한 EOF)

포럼과 WordPress 사이에 OAuth2를 설정하려고 하고 있습니다. 그런데 WordPress에 로그인한 뒤 https://forum/auth/oauth2_basic/callback로 돌아오면 "Oops"가 표시되고, 로그에는 Faraday::SSLError (SSL_read: unexpected eof while reading)가 나옵니다.

이것이 무엇을 의미하나요? 그리고 여기서 말하는 SSL은 어느 쪽의 것을 가리키는 건가요? 구글 검색 결과로는 OpenSSL의 버전 관련 버그인 경우가 꽤 많은데, 어느 쪽(클라이언트/서버)에서 발생하는 문제일까요? 다만 해당 제안들은 약 2년 전 것이었습니다.

그리고 솔직히 말하면, 저도 설정 오류를 자주 범하는 편이라…

열심히 검색해 본 결과, 문제가 OpenSSL 버전인 것 같습니다. 제 WordPress 등은 Ubuntu 20.04와 OpenSSL 1.1.1f가 설치된 VPS에 있는데, 이것이 설치 가능한 최신 버전입니다. 하지만 Discourse는 22.04를 사용하며, 여기서는 OpenSSL 3.x가 사용됩니다.

즉, 제 두통의 원인은 Discourse가 아니라 WordPress가 있는 서버입니다.

글쎄요, 더 새로운 Ubuntu로 이사를 가야겠네요. 네, 그리고 이제 제가 왜 리눅스를 그렇게 싫어하는지 그 깊은 이유에 접어듭니다: 수십 개의 일반 WordPress 사이트, WooCommerce 하나, Moodle 두 개, Postfix, Varnish 및 그 플러그인들을 모두 이전해야 하고, LAMP 스택은 MariaDB로 재구성해야 하며, Nginx-Varnish-Apache 스택도 재구성하고, 크론 작업도 조정해야 하는 등 해야 할 일이 많습니다. 마지막으로 이런 작업을 했을 때 3일이 걸렸는데, 이건 근무일을 말하는 게 아닙니다…

글쎄요, 이건 제 문제이고 오직 제 문제입니다. 저도 알고 있습니다. 그리고 이제 결정을 내려야 합니다: 제 사용자들이 정말로 WordPress를 제공자로 사용하여 OpenID로 포럼에 로그인할 수 있는 기능이 필요한지 말입니다.

수정:

do-release-upgrade를 실행하고 짧은 테스트를 해본 결과, 작동하는 것으로 보입니다. DigitalOcean에서는 18 → 20으로 업그레이드했을 때 완전한 재앙이었던 것과 달리 상황이 바뀌었습니다.

하지만 아무것도 변하지 않았습니다.

  • OpenID는 discovery를 가져오지 못하지만 curl로는 확인됩니다.
  • OAuth는 여전히 그 SSL 오류를 반환합니다.
  • DiscourseConnect는 모든 것을 가로채기 때문에 선택지가 아닙니다.

포기합니다. 이건 제 취향이 아니에요 :man_shrugging:

수정

아, 정말 바보 같네요 :man_facepalming: discovery JSON에 대한 직접 링크와 curl이 작동했기 때문에, 오류가 Discourse 쪽에 있을 것이라고 확신했습니다. 이제 WordPress 서버의 Nginx 로그를 확인해 보니, discovery 요청이 될 때마다 Nginx가 444 오류를 반환하고 있었습니다 — 제가 직접 요청한 경우를 제외하고는요. 그 후 해결책은 정말 쉬웠습니다: 제 나쁜 봇 목록에서 Faraday를 제거하는 것이었죠.

모르겠네요. 이 주제는 삭제되어야 할 것 같습니다. 왜냐하면 Discourse와 관련이 없으니까요. 하지만 분명히, 좀 더 넓게 생각하는 누군가에게 힌트가 될 수 있을 겁니다.