سؤال

في كل مرة يقوم المستخدم بنشر شيء يحتوي على < أو > في إحدى صفحات تطبيق الويب الخاص بي، تلقيت هذا الاستثناء.

لا أريد الخوض في المناقشة حول مدى ذكاء طرح استثناء أو تعطل تطبيق ويب بأكمله لأن شخصًا ما أدخل حرفًا في مربع نص، لكنني أبحث عن طريقة أنيقة للتعامل مع هذا الأمر.

تعويض الاستثناء والعرض

لقد حدث خطأ، يرجى العودة وإعادة كتابة النموذج بأكمله مرة أخرى، ولكن هذه المرة يرجى عدم استخدام <

لا يبدو محترفًا بدرجة كافية بالنسبة لي.

تعطيل التحقق من صحة النشر (validateRequest="false") سيتجنب بالتأكيد هذا الخطأ، لكنه سيجعل الصفحة عرضة لعدد من الهجمات.

من الناحية المثالية:عند حدوث إعادة نشر تحتوي على أحرف HTML مقيدة، سيتم ترميز تلك القيمة المنشورة في مجموعة النماذج تلقائيًا بتنسيق HTML.لذلك .Text خاصية مربع النص الخاص بي ستكون something & lt; html & gt;

هل هناك طريقة يمكنني من خلالها القيام بذلك من المعالج؟

هل كانت مفيدة؟

المحلول

أعتقد أنك تهاجمه من الزاوية الخاطئة بمحاولة تشفير جميع البيانات المنشورة.

لاحظ أن "<"يمكن أن يأتي أيضًا من مصادر خارجية أخرى، مثل حقل قاعدة بيانات أو تكوين أو ملف أو موجز وما إلى ذلك.

بالإضافة إلى، "<"ليس خطرا بطبيعته.إنه خطير فقط في سياق محدد:عند كتابة سلاسل لم يتم ترميزها إلى مخرجات HTML (بسبب XSS).

في سياقات أخرى، تكون السلاسل الفرعية المختلفة خطيرة، على سبيل المثال، إذا كتبت عنوان URL الذي قدمه المستخدم في رابط، فإن السلسلة الفرعية "javascript:"قد يكون خطيرا.من ناحية أخرى، يعد حرف الاقتباس المفرد خطيرًا عند استيفاء السلاسل في استعلامات SQL، ولكنه آمن تمامًا إذا كان جزءًا من اسم تم إرساله من نموذج أو قراءته من حقل قاعدة بيانات.

خلاصة القول هي:لا يمكنك تصفية الإدخال العشوائي للشخصيات الخطيرة، لأن أي شخصية قد تكون خطيرة في ظل الظروف المناسبة.يجب عليك التشفير عند النقطة التي قد تصبح فيها بعض الأحرف المحددة خطيرة لأنها تعبر إلى لغة فرعية مختلفة حيث يكون لها معنى خاص.عند كتابة سلسلة إلى HTML، يجب عليك تشفير الأحرف التي لها معنى خاص في HTML، باستخدام Server.HtmlEncode.إذا قمت بتمرير سلسلة إلى عبارة SQL ديناميكية، فيجب عليك تشفير أحرف مختلفة (أو الأفضل من ذلك، السماح لإطار العمل بالقيام بذلك نيابةً عنك باستخدام عبارات معدة أو ما شابه).

متى أنت متأكد من أنك تقوم بتشفير HTML في كل مكان تقوم فيه بتمرير السلاسل إلى HTML، ثم قم بتعيينها validateRequest="false" في ال <%@ Page ... %> التوجيه في الخاص بك .aspx الملف (الملفات).

في .NET 4 قد تحتاج إلى القيام بالمزيد.في بعض الأحيان يكون من الضروري إضافة أيضا <httpRuntime requestValidationMode="2.0" /> إلى web.config (مرجع).

نصائح أخرى

يوجد حل مختلف لهذا الخطأ إذا كنت تستخدم ASP.NET MVC:

نموذج C#:

[HttpPost, ValidateInput(false)]
public ActionResult Edit(FormCollection collection)
{
    // ...
}

نموذج فيجوال بيسك:

<AcceptVerbs(HttpVerbs.Post), ValidateInput(False)> _
Function Edit(ByVal collection As FormCollection) As ActionResult
    ...
End Function

في ASP.NET MVC (بدءًا من الإصدار 3)، يمكنك إضافة ملف AllowHtml تنسب إلى خاصية في النموذج الخاص بك.

يسمح للطلب بتضمين علامة HTML أثناء ربط النموذج عن طريق تخطي التحقق من صحة الطلب للخاصية.

[AllowHtml]
public string Description { get; set; }

إذا كنت تستخدم .NET 4.0 فتأكد من إضافة هذا إلى ملف .NET 4.0 الخاص بك web.config الملف داخل <system.web> العلامات:

<httpRuntime requestValidationMode="2.0" />

في .NET 2.0، يتم تطبيق التحقق من صحة الطلب فقط على aspx طلبات.في .NET 4.0 تم توسيع هذا ليشمل الجميع طلبات.يمكنك الرجوع إلى فقط إجراء التحقق من صحة XSS عند المعالجة .aspx من خلال تحديد:

requestValidationMode="2.0"

يمكنك تعطيل التحقق من صحة الطلب تماما من خلال تحديد:

validateRequest="false"

بالنسبة لـ ASP.NET 4.0، يمكنك السماح بالترميز كمدخل لصفحات محددة بدلاً من الموقع بأكمله عن طريق وضع كل ذلك في ملف <location> عنصر.سيؤدي هذا إلى التأكد من أن جميع صفحاتك الأخرى آمنة.لا تحتاج إلى وضع ValidateRequest="false" في صفحة .aspx الخاصة بك.

<configuration>
...
  <location path="MyFolder/.aspx">
    <system.web>
      <pages validateRequest="false" />
      <httpRuntime requestValidationMode="2.0" />
    </system.web>
  </location>
...
</configuration>

يعد التحكم في ذلك داخل web.config أكثر أمانًا، لأنه يمكنك أن ترى على مستوى الموقع الصفحات التي تسمح بالترميز كمدخلات.

لا تزال بحاجة إلى التحقق من صحة الإدخال برمجيًا في الصفحات التي تم تعطيل التحقق من صحة الطلب فيها.

الإجابات السابقة رائعة، لكن لم يقل أحد كيفية استبعاد حقل واحد من التحقق من صحته لإدخال HTML/JavaScript.لا أعرف شيئًا عن الإصدارات السابقة، ولكن في MVC3 Beta يمكنك القيام بذلك:

[HttpPost, ValidateInput(true, Exclude = "YourFieldName")]
public virtual ActionResult Edit(int id, FormCollection collection)
{
    ...
}

لا يزال هذا يتحقق من صحة كافة الحقول باستثناء الحقل المستبعد.والشيء الجميل في هذا هو أن سمات التحقق الخاصة بك لا تزال تتحقق من صحة الحقل، ولكنك لا تحصل على الاستثناءات "تم اكتشاف قيمة Request.Form التي يحتمل أن تكون خطيرة من العميل".

لقد استخدمت هذا للتحقق من صحة التعبير العادي.لقد قمت بإنشاء ValidationAttribute الخاص بي لمعرفة ما إذا كان التعبير العادي صالحًا أم لا.نظرًا لأن التعبيرات العادية يمكن أن تحتوي على شيء يشبه البرنامج النصي، فقد قمت بتطبيق الكود أعلاه - لا يزال التعبير العادي قيد التحقق مما إذا كان صالحًا أم لا، ولكن ليس إذا كان يحتوي على نصوص برمجية أو HTML.

في ASP.NET MVC، تحتاج إلى تعيين requestValidationMode="2.0" وvalidateRequest="false" في web.config، وتطبيق سمة ValidateInput على إجراء وحدة التحكم الخاصة بك:

<httpRuntime requestValidationMode="2.0"/>

<configuration>
    <system.web>
        <pages validateRequest="false" />
    </system.web>
</configuration>

و

[Post, ValidateInput(false)]
public ActionResult Edit(string message) {
    ...
}

أنت تستطيع ترميز HTML محتوى مربع النص، لكن لسوء الحظ لن يمنع ذلك حدوث الاستثناء.في تجربتي لا توجد طريقة للتغلب على ذلك، ويجب عليك تعطيل التحقق من صحة الصفحة.وبفعلك هذا تقول:"سأكون حذرا، أعدك."

بالنسبة لـ MVC، تجاهل التحقق من صحة الإدخال عن طريق الإضافة

[التحقق من صحة الإدخال (خطأ)]

فوق كل إجراء في وحدة التحكم.

يمكنك اكتشاف هذا الخطأ في Global.asax.ما زلت أرغب في التحقق من صحة الأمر، ولكن أظهر الرسالة المناسبة.في المدونة المذكورة أدناه، كانت عينة مثل هذه متاحة.

    void Application_Error(object sender, EventArgs e)
    {
        Exception ex = Server.GetLastError();

        if (ex is HttpRequestValidationException)
        {
            Response.Clear();
            Response.StatusCode = 200;
            Response.Write(@"[html]");
            Response.End();
        }
    }

تبدو إعادة التوجيه إلى صفحة أخرى أيضًا بمثابة استجابة معقولة للاستثناء.

http://www.romsteady.net/blog/2007/06/how-to-catch-httprequestvalidationexcep.html

والجواب على هذا السؤال بسيط:

var varname = Request.Unvalidated["parameter_name"];

سيؤدي هذا إلى تعطيل التحقق من صحة الطلب المحدد.

الرجاء الأخذ في الاعتبار أن بعض عناصر التحكم في .NET ستقوم تلقائيًا بتشفير الإخراج باستخدام HTML.على سبيل المثال، سيؤدي تعيين خاصية .Text على عنصر تحكم TextBox إلى ترميزها تلقائيًا.وهذا يعني على وجه التحديد التحويل < داخل &lt;, > داخل &gt; و & داخل &amp;.لذا احذر من فعل هذا...

myTextBox.Text = Server.HtmlEncode(myStringFromDatabase); // Pseudo code

ومع ذلك، فإن خاصية .Text الخاصة بـ HyperLink وLiteral وLabel لن تقوم بتشفير الأشياء بتنسيق HTML، لذا فإن التفاف Server.HtmlEncode();حول أي شيء يتم تعيينه على هذه الخصائص أمر لا بد منه إذا كنت تريد منعه <script> window.location = "http://www.google.com"; </script> من إخراجها إلى صفحتك وتنفيذها لاحقًا.

قم بإجراء القليل من التجارب لمعرفة ما الذي يتم تشفيره وما لا يتم تشفيره.

في ملف web.config، ضمن العلامات، أدخل عنصر httpRuntime مع السمة requestValidationMode="2.0".أضف أيضًا سمة validateRequest = "false" في عنصر الصفحات.

مثال:

<configuration>
  <system.web>
   <httpRuntime requestValidationMode="2.0" />
  </system.web>
  <pages validateRequest="false">
  </pages>
</configuration>

إذا كنت لا ترغب في تعطيل ValidateRequest، فأنت بحاجة إلى تنفيذ وظيفة JavaScript لتجنب الاستثناء.إنه ليس الخيار الأفضل، لكنه يعمل.

function AlphanumericValidation(evt)
{
    var charCode = (evt.charCode) ? evt.charCode : ((evt.keyCode) ? evt.keyCode :
        ((evt.which) ? evt.which : 0));

    // User type Enter key
    if (charCode == 13)
    {
        // Do something, set controls focus or do anything
        return false;
    }

    // User can not type non alphanumeric characters
    if ( (charCode <  48)                     ||
         (charCode > 122)                     ||
         ((charCode > 57) && (charCode < 65)) ||
         ((charCode > 90) && (charCode < 97))
       )
    {
        // Show a message or do something
        return false;
    }
}

ثم في الكود الخلفي، في حدث PageLoad، أضف السمة إلى عنصر التحكم الخاص بك باستخدام الكود التالي:

Me.TextBox1.Attributes.Add("OnKeyPress", "return AlphanumericValidation(event);")

يبدو أنه لم يذكر أحد ما يلي بعد، ولكنه يحل المشكلة بالنسبة لي.وقبل أن يقول أي شخص نعم، فهو Visual Basic...مقرف.

<%@ Page Language="vb" AutoEventWireup="false" CodeBehind="Example.aspx.vb" Inherits="Example.Example" **ValidateRequest="false"** %>

لا أعرف إذا كان هناك أي سلبيات، ولكن بالنسبة لي كان هذا رائعًا.

الحل الآخر هو:

protected void Application_Start()
{
    ...
    RequestValidator.Current = new MyRequestValidator();
}

public class MyRequestValidator: RequestValidator
{
    protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex)
    {
        bool result = base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);

        if (!result)
        {
            // Write your validation here
            if (requestValidationSource == RequestValidationSource.Form ||
                requestValidationSource == RequestValidationSource.QueryString)

                return true; // Suppress error message
        }
        return result;
    }
}

إذا كنت تستخدم إطار العمل 4.0، فقم بالإدخال في web.config (<pages validateRequest="false" />)

<configuration>
    <system.web>
        <pages validateRequest="false" />
    </system.web>
</configuration>

إذا كنت تستخدم إطار العمل 4.5، فقم بالإدخال في web.config (requestValidationMode="2.0")

<system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="2.0"/>
</system.web>

إذا كنت تريد صفحة واحدة فقط، في ملف aspx الخاص بك، يجب عليك وضع السطر الأول على النحو التالي:

<%@ Page EnableEventValidation="false" %>

إذا كان لديك بالفعل شيء مثل <%@ Page، فما عليك سوى إضافة الباقي => EnableEventValidation="false" %>

أوصي بعدم القيام بذلك.

في ASP.NET، يمكنك اكتشاف الاستثناء والقيام بشيء حياله، مثل عرض رسالة ودية أو إعادة التوجيه إلى صفحة أخرى...هناك أيضًا إمكانية أن تتمكن من التعامل مع التحقق من الصحة بنفسك ...

عرض الرسالة الودية:

protected override void OnError(EventArgs e)
{
    base.OnError(e);
    var ex = Server.GetLastError().GetBaseException();
    if (ex is System.Web.HttpRequestValidationException)
    {
        Response.Clear();
        Response.Write("Invalid characters."); //  Response.Write(HttpUtility.HtmlEncode(ex.Message));
        Response.StatusCode = 200;
        Response.End();
    }
}

أعتقد أنه يمكنك القيام بذلك في وحدة نمطية؛لكن هذا يترك بعض الأسئلة مفتوحة؛ماذا لو كنت تريد حفظ المدخلات إلى قاعدة البيانات؟فجأة، نظرًا لأنك تقوم بحفظ البيانات المشفرة في قاعدة البيانات، ينتهي بك الأمر إلى الوثوق في المدخلات منها، وهو ما قد يكون فكرة سيئة.من الناحية المثالية، يمكنك تخزين البيانات الأولية غير المشفرة في قاعدة البيانات وترميزها في كل مرة.

يعد تعطيل الحماية على مستوى كل صفحة ثم التشفير في كل مرة خيارًا أفضل.

بدلاً من استخدام Server.HtmlEncode، يجب عليك الاطلاع على الإصدار الأحدث والأكثر اكتمالاً مكتبة مكافحة XSS من فريق Microsoft ACE.

لقد وجدت حلاً يستخدم JavaScript لتشفير البيانات، والتي تم فك تشفيرها في .NET (ولا تتطلب jQuery).

  • اجعل مربع النص عنصر HTML (مثل منطقة النص) بدلاً من عنصر ASP.
  • إضافة حقل مخفي.
  • أضف وظيفة JavaScript التالية إلى رأسك.

    وظيفة boo () {targetText = document.getElementById ("Hiddenfield1") ؛sourceText = document.getElementById("userbox");targetText.value = escape(sourceText.innerText);}

في منطقة النص الخاصة بك، قم بتضمين onchange الذي يستدعي boo() :

<textarea id="userbox"  onchange="boo();"></textarea>

أخيرًا، في .NET، استخدم

string val = Server.UrlDecode(HiddenField1.Value);

أدرك أن هذا هو اتجاه واحد - إذا كنت بحاجة إلى اتجاهين، فسيتعين عليك الإبداع، ولكن هذا يوفر حلاً إذا لم تتمكن من تحرير web.config

إليك مثال توصلت إليه (MC9000) واستخدمته عبر jQuery:

$(document).ready(function () {

    $("#txtHTML").change(function () {
        var currentText = $("#txtHTML").text();
        currentText = escape(currentText); // Escapes the HTML including quotations, etc
        $("#hidHTML").val(currentText); // Set the hidden field
    });

    // Intercept the postback
    $("#btnMyPostbackButton").click(function () {
        $("#txtHTML").val(""); // Clear the textarea before POSTing
                               // If you don't clear it, it will give you
                               // the error due to the HTML in the textarea.
        return true; // Post back
    });


});

والعلامة:

<asp:HiddenField ID="hidHTML" runat="server" />
<textarea id="txtHTML"></textarea>
<asp:Button ID="btnMyPostbackButton" runat="server" Text="Post Form" />

هذا يعمل بشكل رائع.إذا حاول أحد المتسللين النشر عبر تجاوز جافا سكريبت، فسوف يرون الخطأ.يمكنك حفظ كل هذه البيانات المشفرة في قاعدة البيانات أيضًا، ثم إلغاء إلغائها (على جانب الخادم)، وتحليلها والتحقق من وجود هجمات قبل عرضها في مكان آخر.

سبب

يقوم ASP.NET افتراضيًا بالتحقق من صحة كافة عناصر التحكم في الإدخال للمحتويات التي قد تكون غير آمنة والتي يمكن أن تؤدي إلى عبر موقع البرمجة (XSS) و حقن SQL.وبالتالي فهو لا يسمح بمثل هذا المحتوى عن طريق طرح الاستثناء أعلاه.بشكل افتراضي، يوصى بالسماح بإجراء هذا التحقق في كل إعادة نشر.

حل

في العديد من المناسبات، تحتاج إلى إرسال محتوى HTML إلى صفحتك من خلال Rich TextBoxes أو Rich Text Editors.في هذه الحالة، يمكنك تجنب هذا الاستثناء عن طريق تعيين علامة ValidateRequest في ملف @Page التوجيه إلى الباطل.

<%@ Page Language="C#" AutoEventWireup="true" ValidateRequest = "false" %>

سيؤدي هذا إلى تعطيل التحقق من صحة طلبات الصفحة التي قمت بتعيين علامة ValidateRequest على خطأ.إذا كنت تريد تعطيل هذا، فتحقق من تطبيق الويب الخاص بك؛ستحتاج إلى ضبطه على خطأ في قسم web.config <system.web>

<pages validateRequest ="false" />

بالنسبة لإطارات العمل .NET 4.0 أو أعلى، ستحتاج أيضًا إلى إضافة السطر التالي في قسم <system.web> لتفعيل ما ورد أعلاه.

<httpRuntime requestValidationMode = "2.0" />

هذا كل شيء.آمل أن يساعدك هذا في التخلص من المشكلة المذكورة أعلاه.

مرجع بواسطة: خطأ في ASP.Net:تم اكتشاف قيمة Request.Form التي يحتمل أن تكون خطرة من العميل

الحلول الأخرى هنا رائعة، ولكن من الصعب جدًا تطبيق [AllowHtml] على كل خاصية نموذجية، خاصة إذا كان لديك أكثر من 100 نموذج على موقع بحجم مناسب.

إذا كنت مثلي، تريد تشغيل هذه الميزة (IMHO التي لا معنى لها) خارج الموقع على نطاق واسع، فيمكنك تجاوز طريقة Execute() في وحدة التحكم الأساسية الخاصة بك (إذا لم يكن لديك بالفعل وحدة تحكم أساسية، أقترح عليك إنشاء واحدة، يمكن أن تكون كذلك) مفيد جدًا لتطبيق الوظائف الشائعة).

    protected override void Execute(RequestContext requestContext)
    {
        // Disable requestion validation (security) across the whole site
        ValidateRequest = false;
        base.Execute(requestContext);
    }

فقط تأكد من أنك تقوم بترميز HTML لكل ما يتم ضخه إلى طرق العرض التي تأتي من إدخال المستخدم (هذا هو السلوك الافتراضي في ASP.NET MVC 3 مع Razor على أي حال، لذلك ما لم تكن تستخدم Html.Raw() لسبب غريب لا ينبغي أن تتطلب هذه الميزة.

كنت أتلقى هذا الخطأ أيضًا.

في حالتي، قام المستخدم بإدخال حرف معلمة á في اسم الدور (فيما يتعلق بموفر عضوية ASP.NET).

أقوم بتمرير اسم الدور إلى طريقة لمنح المستخدمين لهذا الدور و $.ajax طلب النشر كان فاشلا فشلا ذريعا ...

لقد فعلت هذا لحل المشكلة:

بدلاً من

data: { roleName: '@Model.RoleName', users: users }

افعل هذا

data: { roleName: '@Html.Raw(@Model.RoleName)', users: users }

@Html.Raw فعلت الحيلة.

كنت أحصل على اسم الدور كقيمة HTML roleName="Cadastro b&#225;s".هذه القيمة مع كيان HTML &#225; تم حظره بواسطة ASP.NET MVC.الآن أحصل على roleName قيمة المعلمة كما ينبغي أن تكون: roleName="Cadastro Básico" ولن يقوم محرك ASP.NET MVC بحظر الطلب بعد الآن.

قم بتعطيل التحقق من صحة الصفحة إذا كنت تحتاج حقًا إلى الأحرف الخاصة مثل، >, , <, ، إلخ.ثم تأكد من أنه عند عرض إدخال المستخدم، تكون البيانات مشفرة بتنسيق HTML.

توجد ثغرة أمنية في التحقق من صحة الصفحة، لذا يمكن تجاوزها.كما لا ينبغي الاعتماد على التحقق من صحة الصفحة فقط.

يرى: http://web.archive.org/web/20080913071637/http://www.procheckup.com:80/PDFs/bypassing-dot-NET-ValidateRequest.pdf

يمكنك أيضًا استخدام JavaScript الهروب (سلسلة) وظيفة لاستبدال الأحرف الخاصة.ثم استخدم جانب الخادم Server.URLDecode(سلسلة) لتبديله مرة أخرى.

بهذه الطريقة لن تضطر إلى إيقاف تشغيل التحقق من صحة الإدخال وسيكون من الواضح للمبرمجين الآخرين أن السلسلة قد تحتوي على محتوى HTML.

انتهى بي الأمر باستخدام JavaScript قبل كل إعادة نشر للتحقق من الأحرف التي لا تريدها، مثل:

<asp:Button runat="server" ID="saveButton" Text="Save" CssClass="saveButton" OnClientClick="return checkFields()" />

function checkFields() {
    var tbs = new Array();
    tbs = document.getElementsByTagName("input");
    var isValid = true;
    for (i=0; i<tbs.length; i++) {
        if (tbs(i).type == 'text') {
            if (tbs(i).value.indexOf('<') != -1 || tbs(i).value.indexOf('>') != -1) {
                alert('<> symbols not allowed.');
                isValid = false;
            }
        }
    }
    return isValid;
}

من المؤكد أن صفحتي هي في الغالب إدخال بيانات، وهناك عدد قليل جدًا من العناصر التي تقوم بعمليات إعادة النشر، ولكن على الأقل يتم الاحتفاظ ببياناتها.

ما دام هؤلاء فقط الأحرف "<" و">" (وليس علامة الاقتباس المزدوجة نفسها) وأنت تستخدمها في سياق مثل <input value="هذا" />، أنت آمن (أثناء استخدام <textarea>هذا</textarea> ستكون عرضة للخطر بالطبع).قد يؤدي ذلك إلى تبسيط موقفك، ولكن أي شئ المزيد من استخدام أحد الحلول المنشورة الأخرى.

إذا كنت تريد فقط إخبار المستخدمين بأنه لا ينبغي استخدام < و > ولكنك لا تريد معالجة/نشر النموذج بالكامل (وفقد كل المدخلات) مسبقًا، فلا يمكنك ببساطة وضع أداة التحقق من الصحة في جميع أنحاء الميدان لفحص تلك الشخصيات (وربما غيرها من الشخصيات التي يحتمل أن تكون خطرة)؟

لم ينجح أي من الاقتراحات بالنسبة لي.لم أرغب في إيقاف تشغيل هذه الميزة لموقع الويب بأكمله بأي حال من الأحوال لأنني لا أريد أن يقوم المستخدمون بنسبة 99% بوضع HTML على نماذج الويب.لقد قمت للتو بإنشاء طريقة العمل الخاصة بي لأنني الوحيد الذي يستخدم هذا التطبيق المحدد.أقوم بتحويل الإدخال إلى HTML في الكود الموجود خلفه وإدراجه في قاعدة البيانات الخاصة بي.

يمكنك استخدام شيء مثل:

var nvc = Request.Unvalidated().Form;

لاحقاً، nvc["yourKey"] يجب أن تعمل.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top