Session

[Bhagya]

Hello,
On the LogOut Page i have done Session.Abandon();
And on every Page, In the Page_Load Event i check if the session exists
and only then display data.
Now the problem is after i logout from application and click the back
button of Internet Explorer, the page displays. Can anyone guide me
plsssss.

Thank you,
Bhagya

 

[Peter Bradley]

This is such a common problem.

The problem is, when you click the Back button, your browser gets the page
from its cache. Worse than that, it means that no page_load event is
generated.

The choices you have are pretty limited (AFAIK). You can either try to
disable the Back button, by clearing the browser cache or something, or you
can deal with the problem when it genuinely arises. The former is really
annoying to users.

If you think about it, the problem is not that the page displays, but that
the user then moves on from that page and expects that data to be as
displayed in the browser. Because the session has been cleared, this will
not be the case. What you need to do, therefore, is to check the state of
the application when the user clicks on whatever action control you have
that deals with the application's state - usually a submit or "next" button.
You should be able to check the application's consistency at this point and,
if the application data is not consistent (i.e. you detect, implicitly, that
the user used the browser back button or the session timed out or whatever)
you can display a message or throw an exception or redirect to the login
page or do whatever is reasonable in your program.

This works for us. We make it easier for ourselves by maintaining
application-specific objects that hold the application state. All we put in
the Session are references to these objects. Storing tonnes of data in an
unstructured way in the Session is a really bad idea IMHO. We also use
forms authentication and attributes to ensure that users who are not logged
in and/or do not have the required role(s) cannot access classes and/or
methods innappropriately. We usually decorate every Page class, and every
method that alters the application state. In the case you mention, we would
have used FormsAuthentication.SignOut() and Session.Abandon(): therefore the
user would fail the security challenge on the Submit or Next button event
handler, because the event handler would be decorated with the appropriate
attributes.

HTH


Peter

 

[Bhagya]

This is such a common problem.

The problem is, when you click the Back button, your browser gets the page
from its cache. Worse than that, it means that no page_load event is
generated.

The choices you have are pretty limited (AFAIK). You can either try to
disable the Back button, by clearing the browser cache or something, or you
can deal with the problem when it genuinely arises. The former is really
annoying to users.

If you think about it, the problem is not that the page displays, but that
the user then moves on from that page and expects that data to be as
displayed in the browser. Because the session has been cleared, this will
not be the case. What you need to do, therefore, is to check the state of
the application when the user clicks on whatever action control you have
that deals with the application's state - usually a submit or "next" button.
You should be able to check the application's consistency at this point and,
if the application data is not consistent (i.e. you detect, implicitly, that
the user used the browser back button or the session timed out or whatever)
you can display a message or throw an exception or redirect to the login
page or do whatever is reasonable in your program.

This works for us. We make it easier for ourselves by maintaining
application-specific objects that hold the application state. All we put in
the Session are references to these objects. Storing tonnes of data in an
unstructured way in the Session is a really bad idea IMHO. We also use
forms authentication and attributes to ensure that users who are not logged
in and/or do not have the required role(s) cannot access classes and/or
methods innappropriately. We usually decorate every Page class, and every
method that alters the application state. In the case you mention, we would
have used FormsAuthentication.SignOut() and Session.Abandon(): therefore the
user would fail the security challenge on the Submit or Next button event
handler, because the event handler would be decorated with the appropriate
attributes.

HTH


Peter

Hello,

I m extremely new to this field. Could u give a code snippet or some
example?

 

[Bhagya]

This is such a common problem.

The problem is, when you click the Back button, your browser gets the page
from its cache. Worse than that, it means that no page_load event is
generated.

The choices you have are pretty limited (AFAIK). You can either try to
disable the Back button, by clearing the browser cache or something, or you
can deal with the problem when it genuinely arises. The former is really
annoying to users.

If you think about it, the problem is not that the page displays, but that
the user then moves on from that page and expects that data to be as
displayed in the browser. Because the session has been cleared, this will
not be the case. What you need to do, therefore, is to check the state of
the application when the user clicks on whatever action control you have
that deals with the application's state - usually a submit or "next" button.
You should be able to check the application's consistency at this point and,
if the application data is not consistent (i.e. you detect, implicitly, that
the user used the browser back button or the session timed out or whatever)
you can display a message or throw an exception or redirect to the login
page or do whatever is reasonable in your program.

This works for us. We make it easier for ourselves by maintaining
application-specific objects that hold the application state. All we put in
the Session are references to these objects. Storing tonnes of data in an
unstructured way in the Session is a really bad idea IMHO. We also use
forms authentication and attributes to ensure that users who are not logged
in and/or do not have the required role(s) cannot access classes and/or
methods innappropriately. We usually decorate every Page class, and every
method that alters the application state. In the case you mention, we would
have used FormsAuthentication.SignOut() and Session.Abandon(): therefore the
user would fail the security challenge on the Submit or Next button event
handler, because the event handler would be decorated with the appropriate
attributes.

HTH


Peter

Hello,

I m extremely new to this field. Could u give a code snippet or some
example?

 

[Bhagya]

This is such a common problem.

The problem is, when you click the Back button, your browser gets the page
from its cache. Worse than that, it means that no page_load event is
generated.

The choices you have are pretty limited (AFAIK). You can either try to
disable the Back button, by clearing the browser cache or something, or you
can deal with the problem when it genuinely arises. The former is really
annoying to users.

If you think about it, the problem is not that the page displays, but that
the user then moves on from that page and expects that data to be as
displayed in the browser. Because the session has been cleared, this will
not be the case. What you need to do, therefore, is to check the state of
the application when the user clicks on whatever action control you have
that deals with the application's state - usually a submit or "next" button.
You should be able to check the application's consistency at this point and,
if the application data is not consistent (i.e. you detect, implicitly, that
the user used the browser back button or the session timed out or whatever)
you can display a message or throw an exception or redirect to the login
page or do whatever is reasonable in your program.

This works for us. We make it easier for ourselves by maintaining
application-specific objects that hold the application state. All we put in
the Session are references to these objects. Storing tonnes of data in an
unstructured way in the Session is a really bad idea IMHO. We also use
forms authentication and attributes to ensure that users who are not logged
in and/or do not have the required role(s) cannot access classes and/or
methods innappropriately. We usually decorate every Page class, and every
method that alters the application state. In the case you mention, we would
have used FormsAuthentication.SignOut() and Session.Abandon(): therefore the
user would fail the security challenge on the Submit or Next button event
handler, because the event handler would be decorated with the appropriate
attributes.

HTH


Peter

Hello,

I m extremely new to this field. Could u give a code snippet or some
example?

 

[Mark Rae]

I m extremely new to this field. Could u give a code snippet or some
example?

There's a problem with your newsreader - it keeps duplicating your posts...

 

[Peter Bradley]

Visual Studio Help has the following:

PrincipalPermissionAttribute can be used to declaratively demand that users
running your code belong to a specified role or have been authenticated. Use
of Unrestricted creates a PrincipalPermission with Authenticated set to true
and Name and Role set to a null reference (Nothing in Visual Basic).

The scope of the declaration that is allowed depends on the SecurityAction
that is used. PrincipalPermissionAttribute cannot be applied at the assembly
level.

The security information declared by a security attribute is stored in the
metadata of the attribute target and is accessed by the system at run time.
Security attributes are used only for declarative security. For imperative
security, use the corresponding permission class.

Important Prior to a demand for principal permission it is necessary to
set the current application domain's principal policy to the enumeration
value WindowsPrincipal. By default, the principal policy is set to
UnauthenticatedPrincipal. If you do not set the principal policy to
WindowsPrincipal, a demand for principal permission will fail. The following
code should be executed before the principal permission is demanded:
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal).

Example
The following example demonstrates how PrincipalPermission can be used
declaratively to demand that the current user is Bob and belongs to the
Supervisor role.

....

C#
[PrincipalPermissionAttribute(SecurityAction.Demand, Name="Bob",
Role="Supervisor")]

....

The following example demonstrates how to demand that the current user's
identity is Bob, regardless of role membership.

....

C#
[PrincipalPermissionAttribute(SecurityAction.Demand, Name="Bob")]

....

The following example demonstrates how to demand only that the user is
authenticated.

....

C#
[PrincipalPermissionAttribute(SecurityAction.Demand, Authenticated=true)]

-------------------------------------

If you need help on creating classes and objects, just read any standard
text. But in brief, let's say your UML (or whatever you use) determines
that you have a "Student" class that has interesting state transitions (e.g.
Enquirer --> Applicant --> Registered-Student --> Graduate --> Alumnus).
You define your class and then create an instance in your code. In order to
hold onto the instance across ASP.NET event handlers, methods and pages, you
store a reference to the class in the Session:

Student student = new Student();
Session["student"] = student;

Now, in a different scope (new page etc), you can do:

Student s = Session["student"];

Now you can call methods on your student object.

HTH


Peter