[ASP.NET] Uitvoeren van code stoppen in Page_Load

[EmilneM]

Op een ASP.NET-webform wordt in de Page_Load gechecked of een gebruiker is ingelogd. Is dit niet het geval dan wordt via een JavaScript ModalDialog een inlogvenster getoond.

Er moet echter ook voorkomen worden dat er verdere code wordt uitgevoerd. In de huidige situatie heb ik dit nog niet voor elkaar:

Visual Basic .NET:

Private Sub Page_Load(ByVal sender As System.Object, _
  ByVal e As System.EventArgs) Handles MyBase.Load
        'Put user code to initialize the page here
        
        If Session("Ingelogd") = False Then
            'Code om JavaScript ModalDialog te tonen

        End If

End Sub

Private Sub cmdVerder_ServerClick(ByVal sender As System.Object, _
  ByVal e As System.EventArgs) Handles cmdVerder.ServerClick
        'Code die niet uitgevoerd zou mogen worden

End Sub

Stel: de gebruiker klikt op de knop 'cmdVerder', er vindt een postback plaats. In de Page_Load wordt gechecked of de gebruiker ingelogd is. Is dit niet het geval dan wordt de dialoog getoond om in te loggen. De code die onder de knop 'cmdVerder' staat wordt echter nog wel uitgevoerd.

Hoe voorkom ik bovenstaande situatie? In elke subroutine steeds checken of de gebruiker is ingelogd vind ik geen nette optie.

[Not Pingu]

code:

Response.Redirect("mijnurl.aspx", true);

En dat werkt idd niet samen met je Javascript dialog, maar dit is bij mijn weten de enige manier om het uitvoeren van code te stoppen. De 'true' hoort nl. bij de parameter 'EndResponse'.

Maar netter is om gewoon Request.IsAuthenticated te controleren bij functies die niet aangesproken mogen worden door users die niet ingelogd zijn

[edit]
false moest true zijn, zie ook uitleg

[ Voor 89% gewijzigd door Not Pingu op 29-06-2005 20:20 ]

[EmilneM]

Gunp01nt schreef op woensdag 29 juni 2005 @ 20:15:

code:

Response.Redirect("mijnurl.aspx", false);

Vind ik geen optie. De pagina wordt dan opnieuw gestart en de gebruiker kan niet verder waar hij was.

offtopic:
Waar staat dat 'False' voor in de response.redirect?

[Not Pingu]

EmilneM schreef op woensdag 29 juni 2005 @ 20:18:

Vind ik geen optie. De pagina wordt dan opnieuw gestart en de gebruiker kan niet verder waar hij was.

Maar waarom wil je dit dan in de onload checken? Als ik het goed begrijp moet de gebruiker, ingelogd of niet, op de pagina kunnen komen, maar bepaalde knoppen e.d. mogen niet bereikbaar zijn.
In dat geval zit er gewoon niks anders op dan een If statement bij elke eventhandler van een knop. En je verbergt natuurlijk de knoppen als de gebruiker ze toch niet kan indrukken, das vanuit usability-oogpunt wel zo fijn

offtopic:
Waar staat dat 'False' voor in de response.redirect?

Sorry, was een foutje van me. Heb ik aangepast

[Woy]

Volgens mij heb je ook een Response.End(). Er wordt dan verder geen data meer naar de pagina gestuurd. Waarschijnlijk trouwens niet wat je wilt want dan is de pagina nog niet gerenderd.

Vind ik geen optie. De pagina wordt dan opnieuw gestart en de gebruiker kan niet verder waar hij was.

Waarom kan de gebruiker dan niet verder? De pagina is op dat moment ook al aan het reloaden dus de gebruiker heeft zowiezo een reload in zijn browser. Als je gewoon de gegevens opslaat ergens in een DB/Session/Cookie/wahtever dan kan je nadat de gebruiker weer is ingelogd gewoon verder gaan

offtopic:
Waar staat dat 'False' voor in de response.redirect?

Dat kan je ook wel in de Documentatie vinden lijkt me, als je daar kijkt zie je gewoon dat de property endResponse heet.

Waarom maak je trouwens gebruik van je eigen Authenticatie mechanisme, kan je niet beter gewoon gebruik maken van de ingebouwde FormsAuthentication??

[EmilneM]

Gunp01nt schreef op woensdag 29 juni 2005 @ 20:23:
Maar waarom wil je dit dan in de onload checken? Als ik het goed begrijp moet de gebruiker, ingelogd of niet, op de pagina kunnen komen, maar bepaalde knoppen e.d. mogen niet bereikbaar zijn.
In dat geval zit er gewoon niks anders op dan een If statement bij elke eventhandler van een knop. En je verbergt natuurlijk de knoppen als de gebruiker ze toch niet kan indrukken, das vanuit usability-oogpunt wel zo fijn

Om veiligheidsoverwegingen verloopt de sessie na een bepaalde tijd. Het is een belangrijke eis van de opdrachtgever dat gebruikers na verloop van de sessie verder kunnen met waar ze waren in een bepaalde sessie, ze moeten hiervoor uiteraard wél opnieuw gebruikersnaam en wachtwoord invoeren.

Waarom maak je trouwens gebruik van je eigen Authenticatie mechanisme, kan je niet beter gewoon gebruik maken van de ingebouwde FormsAuthentication??

Gebruikersnamen en wachtwoorden zijn opgeslagen in de database. Als de gebruiker succesvol is ingelogd wordt in de Session 'Ingelogd = True' (Session("Ingelogd") = True) meegegeven. Op alle pagina's van de webapplicatie wordt vervolgens gechecked of de gebruiker is ingelogd...

[ Voor 22% gewijzigd door EmilneM op 29-06-2005 20:34 ]

[Not Pingu]

EmilneM schreef op woensdag 29 juni 2005 @ 20:28:
[...]


Om veiligheidsoverwegingen verloopt de sessie na een bepaalde tijd. Het is een belangrijke eis van de opdrachtgever dat gebruikers na verloop van de sessie verder kunnen met waar ze waren in een bepaalde sessie, ze moeten hiervoor uiteraard wél opnieuw gebruikersnaam en wachtwoord invoeren.

Maar op het moment dat je alle code afbreekt als de user niet ingelogd is, dan zullen er waarschijnlijk ook een aantal zaken niet gerenderd worden / niet werkend zijn waar de gebruiker dus kennelijk wel nog gebruik van moet kunnen maken.
Gewoon een if-statementje in elk stukje code dat alleen door ingelogde gebruikers mag worden uitgevoerd, lijkt me het makkelijkste.

[whoami]

EmilneM schreef op woensdag 29 juni 2005 @ 20:12:
Op een ASP.NET-webform wordt in de Page_Load gechecked of een gebruiker is ingelogd. Is dit niet het geval dan wordt via een JavaScript ModalDialog een inlogvenster getoond.

Waarom maak je geen gebruik van de security / inlogmogelijkheden die asp.net je al biedt ?

Gebruikersnamen en wachtwoorden zijn opgeslagen in de database. Als de gebruiker succesvol is ingelogd wordt in de Session 'Ingelogd = True' (Session("Ingelogd") = True) meegegeven. Op alle pagina's van de webapplicatie wordt vervolgens gechecked of de gebruiker is ingelogd...

Wel dat kan je perfect doen met forms - authentication.

En bij het enablen / disablen van bepaalde knoppen kan je gebruik maken van de functionaliteit die in .NET zit:

code:

btnBliepButton.Enabled = User.Identity.IsAuthenticated;

[ Voor 45% gewijzigd door whoami op 29-06-2005 21:04 ]

[Friedchicken]

Bij werkt hij als volgt:

code:

 'Controleer of de sessie nog niet verlopen is.
        'Is dit wel het geval, stuur de gebruiker terug naar de loginpagina en geef
        'de juiste returnURL mee.
        If (Session("UserID") = 0) Then
            Dim returnurl As String = "login.aspx?ReturnUrl=" & Request.RawUrl
            Response.Redirect(returnurl)
        End If

Gaat wanneer sessie verlopen is dus nog wel terug naar waar de user was...

[ Voor 15% gewijzigd door Friedchicken op 29-06-2005 21:03 ]

[EmilneM]

Waarom maak je geen gebruik van de security / inlogmogelijkheden die asp.net je al biedt ?

Per inlogsessie sla ik een aantal variabelen op in het Session-object. Als ik gebruik maak van de security-mogelijkheden van ASP.NET heb ik naast het Session-object, dat verloopt na een bepaalde tijd, nog een object (cookie van security-mogelijkheden ASP.NET) dat verloopt.

[Woy]

Je Authentication ticket heeft een sliding expiration en als die tijd dus minstens net zo lang of langer is als je Session levert dit lijkt mij nooit problemen op. Het cookie wordt tenslote automatisch opnieuw gezet als de gebruiker opnieuw inlogd

[Verwijderd]

met EXIT SUB kan je direct uit een SUB springen. EXIT kan je ook gebruiken in bijvoorbeeld FOR loops

[Woy]

Verwijderd schreef op donderdag 30 juni 2005 @ 15:03:
met EXIT SUB kan je direct uit een SUB springen. EXIT kan je ook gebruiken in bijvoorbeeld FOR loops

Daar gaat het hier helemaal niet over het gaat er over dat de rest van de execution van de page wordt gestopt ( Op het renderen na ). Met alleen uit de sub springen heb je nog niks bereikt want al je event handlers worden nog steeds uitgevoerd.

[gorgi_19]

http://msdn.microsoft.com...scompleterequesttopic.asp dan niet de oplossing?

[Woy]

Volgens mij slaat dat ook het Renderen van de page over.

Maar nogmaals het lijkt mij echt handiger om gewoon gebruik te gaan maken van FormsAuthentication