मुझे एक टेबल नाम को संग्रहीत प्रो में कैसे पास करना चाहिए?

सबसे पहले, आपको कभी नहीं . करना चाहिए क्लाइंट ऐप पर SQL कमांड कंपोजिशन इस तरह से करें, यही है एसक्यूएल इंजेक्शन क्या है। (यह एक ऐसे व्यवस्थापक उपकरण के लिए ठीक है जिसका अपना कोई निजी नहीं है, लेकिन साझा उपयोग एप्लिकेशन के लिए नहीं है)।

दूसरे, हाँ, एक संग्रहीत प्रक्रिया के लिए एक पैरामीट्रिज्ड कॉल क्लीनर और सुरक्षित दोनों है।

हालांकि , जैसा कि आपको ऐसा करने के लिए डायनेमिक SQL का उपयोग करने की आवश्यकता होगी, आप अभी भी निष्पादित क्वेरी के पाठ में पारित स्ट्रिंग को शामिल नहीं करना चाहते हैं। इसके बजाय, आप वास्तविक . के नाम देखने के लिए पारित स्ट्रिंग का उपयोग करना चाहते हैं टेबल जिन्हें उपयोगकर्ता को रास्ते में क्वेरी करने की अनुमति दी जानी चाहिए।

यहाँ एक सरल अनुभवहीन उदाहरण दिया गया है:

CREATE PROC spCountAnyTableRows( @PassedTableName as NVarchar(255) ) AS
-- Counts the number of rows from any non-system Table, *SAFELY*
BEGIN
    DECLARE @ActualTableName AS NVarchar(255)

    SELECT @ActualTableName = QUOTENAME( TABLE_NAME )
    FROM INFORMATION_SCHEMA.TABLES
    WHERE TABLE_NAME = @PassedTableName

    DECLARE @sql AS NVARCHAR(MAX)
    SELECT @sql = 'SELECT COUNT(*) FROM ' + @ActualTableName + ';'

    EXEC(@SQL)
END

कुछ ने निष्पक्ष रूप से पूछा है कि यह सुरक्षित क्यों है। उम्मीद है, छोटी बॉबी टेबल्स इसे स्पष्ट कर सकती हैं:0

अधिक प्रश्नों के उत्तर:

1. अकेले QUOTENAME के ​​सुरक्षित होने की गारंटी नहीं है। MS हमें इसका उपयोग करने के लिए प्रोत्साहित करता है, लेकिन उन्होंने इस बात की गारंटी नहीं दी है कि इसे हैकर्स द्वारा धोखा नहीं दिया जा सकता है। FYI करें, असली सुरक्षा गारंटी के बारे में है। QUOTENAME के ​​साथ टेबल लुकअप, एक और कहानी है, यह अटूट है।

2. इस उदाहरण के लिए QUOTENAME कड़ाई से आवश्यक नहीं है, केवल INFORMATION_SCHEMA पर लुकअप अनुवाद सामान्य रूप से पर्याप्त है। QUOTENAME यहां इसलिए है क्योंकि पूर्ण और सही समाधान शामिल करना सुरक्षा के लिहाज से अच्छा है. यहां मौजूद QUOTENAME वास्तव में एक विशिष्ट, लेकिन समान संभावित समस्या से बचाव कर रहा है, जिसे अव्यक्त इंजेक्शन के रूप में जाना जाता है ।

मुझे ध्यान देना चाहिए कि आप गतिशील कॉलम नामों और INFORMATION_SCHEMA.COLUMNS के साथ भी ऐसा ही कर सकते हैं। टेबल।

आप इसके बजाय पैरामीटरयुक्त SQL क्वेरी का उपयोग करके संग्रहीत कार्यविधियों की आवश्यकता को बायपास कर सकते हैं (यहां देखें:https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlcommand.parameters?view=नेटफ्रेमवर्क-4.8)। लेकिन मुझे लगता है कि संग्रहीत कार्यविधियाँ इस तरह के मामलों के लिए अधिक प्रबंधनीय और कम त्रुटि-प्रवण सुरक्षा सुविधा प्रदान करती हैं।