فحص Mailgun api key بشكل عكسي (لا يلزم وجود مفتاح API إذا كان مستلم البريد يعالج الارتدادات)

خلل
1

لقد لاحظت أن العديد من المواقع تشتكي من عدم تعريف مفتاح واجهة برمجة تطبيقات Mailgun، ولكن (على الأقل معظم) تلك المواقع تتلقى ردودًا عبر حاوية استقبال البريد وهي تتعامل مع هذه الارتدادات، لذا لا يلزم أن يكون مفتاح واجهة برمجة التطبيقات (والخطاف المرتبط به على Mailgun) مطلوبًا. يبدو أن المنطق في المواصفات (وبالتالي، في الكود) معكوس:

missing_mailgun_api_key_spec

يظهر هذا:

    context "when using Mailgun without an API key" do
      let(:replies_enabled) { true }
      let(:mailgun_address) { "smtp.mailgun.org" }
      let(:api_key) { nil }

      it do
        expect(check).to have_a_problem.with_priority("low").with_message(
          "The server is configured to send emails via Mailgun but you haven't provided an API key used to verify the webhook messages.",
        )
      end

يشكو إذا كانت الردود ممكّنة، ولكن في هذه الحالة، نحن لا نحتاج إلى الخطاف، و

    context "when replies are disabled" do
      let(:replies_enabled) { false }
      let(:mailgun_address) { anything }
      let(:api_key) { anything }

      it { expect(check).to be_chill_about_it }
    end

هنا نحن لا نعالج الارتدادات باستخدام مستقبل البريد ونحن مرتاحون حيال ذلك.

هل أنا مرتبك أم أن هذا معكوس؟

حسنًا، ربما أنا مرتبك. يبدو أن مستقبل البريد لا يخبر Discourse عن الارتدادات. موقع مزدحم لا يحتوي على رسائل مرتدة حديثة.

ولكن:

و:

لذلك تشير هذه الوثائق إلى أنه إذا كان لديك مستقبل بريد يعمل، فيجب أن يتعامل مع هذا. والكود الذي كتبته ذات مرة في بعض أدواتي الداخلية التي أعدت هذه الخطافات تقول “لا نحتاج إلى خطافات عندما يكون لدينا مستقبل بريد”.

3 إعجابات