[ASP.NET] IsValid altijd True als val. dynamisch aangemaakt

[Verwijderd]

Ik had een pagina met validators gemaakt, en wou even controleren hoe het 'voelt' als javascript uit staat. Ik wist dat ASP.NET validators eventueel clientside kunnen draaien (gerenderd wroden als Javascript), maar ALTIJD ook serverside werken als je page.validate aanroept.

Dit werkte als ik in de .aspx een validator class aanmaak:

code:

<asp:RequiredFieldValidator id="test" controlToValidate="tekstveld" errorMessage="fout"></asp/RequiredFieldValidator>

maar als ik hem dynamisch aanmaak in de Page.onLoad:

code:

        if (IsPostBack)
        {
            Page.Validate();

            if (Page.IsValid)
            // dingen doen met database
        }
        else
        {
            vl_postcode = new RequiredFieldValidator();
            vl_postcode.ControlToValidate="postcode";
            vl_postcode.ErrorMessage = "kut";
            vl_postcode.ID = "ch";
            form1.Controls.Add(vl_postcode);
        }

dan is bij de postBack de IsValid altijd true, wat ik ook invul. De server-side validatie werkt dan dus niet. Ik zag tijdens het debuggen dat dit komt omdat de Page.Validators leeg is op dat moment, zelfs al wanneer op de submitknop geklikt wordt, dus nog voordat de page ge-PostBack-ed is.

Hoe kan dit, dat wanneer ik (naar mijn idee) dynamisch hetzelfde doe als wanneer ik het het statisch doe (in .aspx) het statisch wel werkt en dynamisch niet ?
Ik heb zelfs nog expliciet Validators.Add(vl_postcode) gedaan maar dat maakt ook niet uit.

[PolarBear]

Misschien iet in de trant van (in VB)

Visual Basic .NET:

Partial Class Default
    Inherits System.Web.UI.Page

    Dim WithEvents vl_postocde As RequiredFieldValidator

  Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        If Not Page.IsPostBack Then
            vl_postcode = new RequiredFieldValidator
            vl_postcode.ControlToValidate="postcode"
            vl_postcode.ErrorMessage = "kut"
            vl_postcode.ID = "ch"
            form1.Controls.Add(vl_postcode)
        End If
    End Sub

Dus met WithEvents

[ Voor 7% gewijzigd door PolarBear op 05-09-2007 12:05 ]

[Janoz]

Hmm, ik ben wel erg benieuwd waardoor dit wordt veroorzaakt. Het zou wel heel suf zijn wanneer het met .NET mogelijk was om, door je javascript uit te zetten, de serverside validatie te omzeilen. Niet alleen suf trouwens, maar ook een behoorlijk beveiligingsrisico!

[Niemand_Anders]

v1_postcode moet protected worden opgenomen in de class.
Vervolgens dien je in de constructor (Na InitializeComponent) v1_postcode zelf aan de validators collectie toe te voegen.

Het .net framework doet dan de rest voor jouw. Bij Page_Load is er al van alles (ik denk zeker 10 events, zie HttpApplication events + Page events. Het event Load zit in het midden van de event boom) met de page gebeurt. Alle initialisatie code dient in de constructor te gebeuren.

[Rickets]

Op het moment dat je controleert of de pagina geldig is, kent je pagina die validator nog niet. Het beste is om de validator toe te voegen voordat het Load-event plaatsvindt. (Door tijdens het Init-event je control collection zelf op te bouwen en je validator daar toe te voegen bijvoorbeeld.)

Je doet dus op dit moment niet hetzelfde als met aspx-pagina’s, want in dat geval voeg je de validator niet toe tijdens de Load, maar in je aspx-pagina.

Janoz schreef op woensdag 05 september 2007 @ 12:06:
Hmm, ik ben wel erg benieuwd waardoor dit wordt veroorzaakt. Het zou wel heel suf zijn wanneer het met .NET mogelijk was om, door je javascript uit te zetten, de serverside validatie omzeilt kan worden. Niet alleen suf trouwens, maar ook een behoorlijk beveiligingsrisico!

Dat is dus niet zo, het ligt aan de specieke opbouw van deze pagina Als de pagina correct opgebouwd wordt, kan je die validatie niet omzeilen.

[ Voor 36% gewijzigd door Rickets op 05-09-2007 12:20 ]

[Niemand_Anders]

Janoz schreef op woensdag 05 september 2007 @ 12:06:
Hmm, ik ben wel erg benieuwd waardoor dit wordt veroorzaakt. Het zou wel heel suf zijn wanneer het met .NET mogelijk was om, door je javascript uit te zetten, de serverside validatie omzeilt kan worden. Niet alleen suf trouwens, maar ook een behoorlijk beveiligingsrisico!

Simpel, v1_postcode is niet onderdeel van de page (niet bekend bij initialisatie van de page) Validators collectie en wordt daarom niet meegenomen bij Page.Validate().


Tipje van sluier:
v1_postcode wordt alleen toegevoegd als IsPostback false is. Zodra de het formulier wordt verstuurd is IsPostback true, en wordt v1_postcode niet gezet. Als hij de validator via de designer toevoegt is de validator 'globaal' over de page bekend.

[Verwijderd]

Tipje van sluier:
v1_postcode wordt alleen toegevoegd als IsPostback false is. Zodra de het formulier wordt verstuurd is IsPostback true, en wordt v1_postcode niet gezet. Als hij de validator via de designer toevoegt is de validator 'globaal' over de page bekend.

Maar als je iedere keer (ook in een PostBack) dat object opnieuw aanmaakt, weet die validator toch niet meer wat je ingevuld hebt ?

Edit: Ik heb het wel geprobeerd, gewoon in de PageLoad trouwens, en nu werkt het wel! Ik snap alleen niet echt waarom.
Bij PHP moest je gewoon expliciet de formvalues opvragen via $_POST, maar blijkbaar zet ASP.NET die waardes automatisch in de velden en weet die nieuwgemaakte validator in een PostBack sessie dus welke waarde hij moet valideren ?

[Janoz]

@Rickets: Ik vermoede ook wel dat dit door een fout van de topicstarter kwam, maar ik ben niet zo heel bekend met .NET. Daarnaast weet ik niet of zijn aanpak common is, of gewoon helemaal verkeerd. Met de hint van Niemand_Anders wordt het me wel een stuk duidelijker, maar het lijkt me wel iets om op te letten. Bij het gebruiken van een redelijk high level omgeving verwacht je dat bepaalde zaken in het onderliggende framework goed opgelost zijn. Uit de topicstart vermoede ik dat de het wel of niet uitvoeren van de serverside validatie afhankelijk was van de client, maar dat blijkt dus niet zo te zijn. Er was sowieso geen serverside validatie in dit geval, maar dat viel niet op omdat er aan de clientkant wel werd gevalideerd.

[Verwijderd]

Bij het gebruiken van een redelijk high level omgeving verwacht je dat bepaalde zaken in het onderliggende framework goed opgelost zijn.

Dat vond ik nou ook. In het kader van objectgeorienteerd webprogrammeren heb ik even gewacht dat de hele page class bleef 'leven' na een postback, maar dit geldt alleen voor de door de class gegenereerde formdata.. Het kan wel als je de validators in de Session[] zet, maar of dat logisch is is de vraag.

Er was sowieso geen serverside validatie in dit geval, maar dat viel niet op omdat er aan de clientkant wel werd gevalideerd.

Precies ! Bij toeval kwam ik erachter. Bedankt voor de reacties allemaal !

[4of9]

[
Edit: Ik heb het wel geprobeerd, gewoon in de PageLoad trouwens, en nu werkt het wel! Ik snap alleen niet echt waarom.
Bij PHP moest je gewoon expliciet de formvalues opvragen via $_POST, maar blijkbaar zet ASP.NET die waardes automatisch in de velden en weet die nieuwgemaakte validator in een PostBack sessie dus welke waarde hij moet valideren ?

Bij iedere postback gaat asp.net de control tree opnieuw genereren. Intern weet asp.net de state van de objecten dmv controlstate en viewstate.

als je wilt weten hoe het precies werkt raad ik je aan deze artikelen eens te lezen:

http://weblogs.asp.net/in...s-_2800_Part-1_2900_.aspx

[gorgi_19]

Verwijderd schreef op woensdag 05 september 2007 @ 16:29:
Dat vond ik nou ook. In het kader van objectgeorienteerd webprogrammeren heb ik even gewacht dat de hele page class bleef 'leven' na een postback, maar dit geldt alleen voor de door de class gegenereerde formdata.. Het kan wel als je de validators in de Session[] zet, maar of dat logisch is is de vraag.

Http is stateless; hoe zou hij dat moeten onthouden? En alle pagina's in de sessie houden, dan blaas je binnen notime je server op qua geheugen

[gorgi_19]

Janoz schreef op woensdag 05 september 2007 @ 12:50:
@Rickets: Ik vermoede ook wel dat dit door een fout van de topicstarter kwam, maar ik ben niet zo heel bekend met .NET. Daarnaast weet ik niet of zijn aanpak common is, of gewoon helemaal verkeerd. Met de hint van Niemand_Anders wordt het me wel een stuk duidelijker, maar het lijkt me wel iets om op te letten. Bij het gebruiken van een redelijk high level omgeving verwacht je dat bepaalde zaken in het onderliggende framework goed opgelost zijn. Uit de topicstart vermoede ik dat de het wel of niet uitvoeren van de serverside validatie afhankelijk was van de client, maar dat blijkt dus niet zo te zijn. Er was sowieso geen serverside validatie in dit geval, maar dat viel niet op omdat er aan de clientkant wel werd gevalideerd.

De aanpak was gewoonweg verkeerd Wil je je controlcollection veranderen, dan moet dat tijdens het Init-event gebeuren (eventueel tijdens de CreateChildControls). In ieder geval in een method die altijd uitgevoerd wordt. De properties kunnen wel tijdens de Load gezet worden (ook in de postback), want door de viewstate / controlstate worden deze toch wel onthouden.
Je hoeft hem dan ook niet per se in de designer in te voegen; dynamisch kan je best controls toevoegen, mits je het op tijd doet.

De code werd dus pas later aan de pagina toegevoegd, vandaar dat de Javascript wel werkte. Bij een harde 'postback' ontbrak de validator in de controlcollection (deze werd niet opnieuw toegevoegd) en dus werd de control niet gevalideerd