logo

Extra Block Types (EBT) - New Layout Builder experience❗

Extra Block Types (EBT) - styled, customizable block types: Slideshows, Tabs, Cards, Accordions and many others. Built-in settings for background, DOM Box, javascript plugins. Experience the future of layout building today.

Demo EBT modules Download EBT modules

❗Extra Paragraph Types (EPT) - New Paragraphs experience

Extra Paragraph Types (EPT) - analogical paragraph based set of modules.

Demo EPT modules Download EPT modules

Scroll
04/09/2025, by Ivan

JSON Drop API Documentation

JSON:API मॉड्यूल Drupal में Drupal के Entity API, Field API और Typed Data API के जरिए परिभाषित डेटा मॉडल को लेता है और उसे JSON:API स्पेसिफ़िकेशन का पालन करने वाले API के माध्यम से एक्सपोज़ करता है, ताकि Drupal द्वारा प्रबंधित डेटा (एंटिटी) के साथ इंटरैक्शन सहज हो सके।

ऐसा करते समय, यह उस डेटा के लिए Drupal की सभी सुरक्षा व्यवस्थाओं का सम्मान करता है:

  • Entity Access का सम्मान किया जाता है।
  • Field Access का सम्मान किया जाता है।
  • डेटा में परिवर्तन करते समय, validation constraints का पालन किया जाता है।
  • internal फ़्लैग का सम्मान किया जाता है (देखें कि इसे entity type definition, field definition या property definition पर कैसे सेट किया जा सकता है, इसके लिए डॉक्युमेंटेशन देखें)।

दूसरे शब्दों में: JSON:API मौजूदा सुरक्षा उपायों को बायपास नहीं करता और न ही अपनी ओर से कोई अतिरिक्त लेयर जोड़ता है; यह Drupal की नींव का पुनः उपयोग करता है।

एंटिटी टाइप, फ़ील्ड टाइप और डेटा टाइप में बग सुरक्षा कमजोरियों का कारण बन सकते हैं

फिर भी, एंटिटी टाइप, फ़ील्ड टाइप और डेटा टाइप, तथा उनके access control handler और validation constraints को लागू करने वाले कोड में बग मौजूद हो सकते हैं। इसका बड़ा कारण Drupal की विरासत है: Drupal में मूल रूप से validation constraints नहीं थे बल्कि form validation callbacks थे; API-first मानसिकता की ओर शिफ्ट Drupal core में पूर्ण मानी जा सकती है, लेकिन contributed या custom मॉड्यूल्स के लिए इसकी गारंटी नहीं है।

ये बग सुरक्षा कमजोरियों का कारण बन सकते हैं; अतीत में ऐसा हुआ भी है। ऐसी कमजोरियाँ केवल JSON:API मॉड्यूल तक सीमित नहीं हैं; वे उदाहरण के लिए RESTful Web Services मॉड्यूल और किसी भी PHP कोड को प्रभावित करती हैं जो Entity API के साथ इंटरैक्ट करता है।

हालाँकि, क्योंकि कोई दुष्ट उपयोगकर्ता PHP API की तुलना में JSON:API या RESTful Web Services जैसे HTTP API तक अधिक आसानी से पहुँच सकता है, इसलिए इस मामले में अतिरिक्त सावधानी की आवश्यकता होती है। अन्य HTTP API मॉड्यूल्स के विपरीत, JSON:API का आउट-ऑफ़-द-बॉक्स API सरफ़ेस बड़ा होता है: सभी non-internal एंटिटी टाइप डिफ़ॉल्ट रूप से उपलब्ध करा दिए जाते हैं (बिल्कुल Entity Access का सम्मान करते हुए), ताकि डेवलपर अनुभव जितना संभव हो उतना सहज रहे।

छह सुरक्षा संबंधी विचार

1. स्थिर (Stable) contributed मॉड्यूल्स का उपयोग करने का महत्व

एंटिटी टाइप, फ़ील्ड टाइप और डेटा टाइप के कारण उत्पन्न सुरक्षा कमजोरियों का समाधान यथाशीघ्र केवल उन स्थिर मॉड्यूल्स के लिए किया जाता है जो Drupal.org पर प्रकाशित हैं और security advisory policy द्वारा कवर किए गए हैं। कस्टम मॉड्यूल्स और non-stable contributed मॉड्यूल्स कवर नहीं होते। यदि आप इनमें से कुछ का उपयोग कर रहे हैं, तो अतिरिक्त सावधानी बरतें।

2. Entity और Field Access का ऑडिट करना

चाहे आप JSON:API का उपयोग कर रहे हों या कोई अन्य API-जैसा मॉड्यूल, हमेशा यह अनुशंसित है कि Drupal साइट्स पर Entity Access और Field Access का ऑडिट करें। यदि JSON:API की लिखने (write) की क्षमताएँ सक्षम हैं, तो यह विशेष रूप से महत्वपूर्ण है।

3. केवल वही एक्सपोज़ करें जिसकी आपको आवश्यकता है

जब विशिष्ट resource types (एंटिटी टाइप + बंडल) को एक्सपोज़ करने की आवश्यकता नहीं है, तो उनकी पहुँच को अस्वीकार (deny) करना सुनिश्चित करने के बाद, आप एक कदम और आगे जाकर उन्हें अक्षम (disable) कर सकते हैं। किसी resource type या field को disable करने के लिए, एक PHP API उपलब्ध है जिसे आप कस्टम मॉड्यूल में लागू कर सकते हैं, या आप JSON:API Extras contrib मॉड्यूल का उपयोग कर सकते हैं, जो resource types और fields को disable करने के लिए UI प्रदान करता है। यह हमेशा संभव नहीं है, लेकिन उस स्थिति में जहाँ साइट मालिक सभी API क्लाइंट्स का भी मालिक हो, आप API सरफ़ेस को यथासंभव छोटा रखने के लिए ऐसा कर सकते हैं।

4. Read-only मोड

यदि आपकी विशेष आवश्यकताओं के लिए आपको केवल डेटा पढ़ने की आवश्यकता है, तो आप /admin/config/services/jsonapi पर JSON:API का read-only मोड सक्षम कर सकते हैं। यह पहले से मौजूद validation constraints और write logic में काल्पनिक, अभी-अज्ञात बग्स से उत्पन्न जोखिमों को कम करता है। क्योंकि अधिकांश आधुनिक decoupled Drupal सेटअप्स को केवल डेटा पढ़ने की आवश्यकता होती है, read-only मोड डिफ़ॉल्ट रूप से चालू रहता है। (Drupal core के JSON:API में और contributed मॉड्यूल के संस्करण 2.4 और नए में।)

5. Security through obscurity: गुप्त base path

JSON:API के लिए base path डिफ़ॉल्ट रूप से /jsonapi होता है। इसे बदलकर कुछ ऐसा किया जा सकता है जैसे /hidden/b69dhj027ooae/jsonapi, जो स्वचालित हमलों की प्रभावशीलता को कम करने का एक तरीका है। यदि sites/example.com/services.yml पहले से मौजूद नहीं है, तो इसे बनाएँ और यह जोड़ें:

parameters:
  jsonapi.base_path: /hidden/b69dhj027ooae/jsonapi

6. कुछ routes हटाकर यह सीमित करें कि किन entity bundles को बनाया या संपादित किया जा सकता है

यदि आपको JSON:API के माध्यम से केवल कुछ entity bundles बनानी या अपडेट करनी हैं, तो आप एक event subscriber लागू कर सकते हैं जो custom मॉड्यूल में POST और PATCH routes में से whitelist के अलावा सभी routes हटा दे। यह read-only मोड को disable करने के बाद प्रभावी होगा और router rebuild की आवश्यकता पड़ सकती है।

अपने मॉड्यूल की services.yml फ़ाइल में एक सर्विस जोड़ें:

services:
  mymodule.route_subscriber:
    class: Drupal\mymodule\Routing\JsonapiLimitingRouteSubscriber
    tags:
      - { name: event_subscriber }

event subscriber बनाएँ। यह उदाहरण JSON:API के माध्यम से किसी भी कंटेंट को delete करना असंभव भी बना देता है:

<?php

namespace Drupal\mymodule\Routing;

use Drupal\Core\Routing\RouteSubscriberBase;
use Symfony\Component\Routing\RouteCollection;

/**
 * Class JsonapiLimitingRouteSubscriber.
 *
 * jsonapi संसाधनों से सभी DELETE routes हटाएँ ताकि कंटेंट सुरक्षित रहे।
 *
 * उन POST और PATCH routes को हटाएँ जो jsonapi संसाधनों के लिए हैं,
 * सिवाय उन routes के जिन्हें हम decoupled API के माध्यम से end users
 * को बनाना और अपडेट करना देना चाहते हैं।
 */
class JsonapiLimitingRouteSubscriber extends RouteSubscriberBase {

  /**
   * {@inheritdoc}
   */
  protected function alterRoutes(RouteCollection $collection) {
    $mutable_types = $this->mutableResourceTypes();
    foreach ($collection as $name => $route) {
      $defaults = $route->getDefaults();
      if (!empty($defaults['_is_jsonapi']) && !empty($defaults['resource_type'])) {
        $methods = $route->getMethods();
        if (in_array('DELETE', $methods)) {
          // हम कभी डेटा delete नहीं करना चाहते, केवल unpublish करना चाहते हैं।
          $collection->remove($name);
        }
        else {
          $resource_type = $defaults['resource_type'];
          if (empty($mutable_types[$resource_type])) {
            if (in_array('POST', $methods) || in_array('PATCH', $methods)) {
              $collection->remove($name);
            }
          }
        }
      }
    }
  }

  /**
   * उन resource types की सूची प्राप्त करें जिन्हें API के माध्यम से बदलना अनुमत है।
   *
   * @return array
   *   mutable jsonapi resource types की कुंजियों की सूची।
   */
  public function mutableResourceTypes(): array {
    return [
      'node--article' => TRUE,
      'node--document' => TRUE,
      'custom_entity--custom_entity' => TRUE,
    ];
  }

}

एक अतिरिक्त अनुमति के साथ सभी JSON:API routes तक पहुँच को सीमित करें

जब आप JSON:API का उपयोग backend integrations, सीमित API clients या अन्य गैर-जन-सुलभ उपयोग मामलों के लिए कर रहे हों, तो यह वांछनीय हो सकता है कि सभी JSON:API तक पहुँच केवल किसी विशेष अनुमति वाले उपयोगकर्ताओं को दी जाए। इसके लिए (या अतिरिक्त रूप से), ऊपर बताए गए route subscriber में निम्न स्निपेट जोड़ें:

    // एक अतिरिक्त permission के साथ सभी jsonapi routes की पहुँच सीमित करें।
    foreach ($collection as $route) {
      $defaults = $route->getDefaults();
      if (!empty($defaults['_is_jsonapi'])) {
        $route->setRequirement('_permission', 'FOO custom access jsonapi');
      }
    }

इसके बाद उस permission को FOO.permissions.yml में परिभाषित करें और उपयुक्त उपयोगकर्ता भूमिकाओं (roles) को प्रदान करें।

लेख स्रोत: Drupal Documentation.