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 innappropriatel y. We usually decorate every Page class, and every
method that alters the application state. In the case you mention, we would
have used FormsAuthentica tion.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" <ja**********@g mail.comwrote in message
news:11******** **************@ 16g2000cwy.goog legroups.com...

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

[Bhagya]

Peter Bradley wrote:

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 innappropriatel y. We usually decorate every Page class, and every
method that alters the application state. In the case you mention, we would
have used FormsAuthentica tion.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" <ja**********@g mail.comwrote in message
news:11******** **************@ 16g2000cwy.goog legroups.com...

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

Hello,

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

[Bhagya]

Peter Bradley wrote:

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 innappropriatel y. We usually decorate every Page class, and every
method that alters the application state. In the case you mention, we would
have used FormsAuthentica tion.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" <ja**********@g mail.comwrote in message
news:11******** **************@ 16g2000cwy.goog legroups.com...

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

Hello,

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

[Bhagya]

Peter Bradley wrote:

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 innappropriatel y. We usually decorate every Page class, and every
method that alters the application state. In the case you mention, we would
have used FormsAuthentica tion.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" <ja**********@g mail.comwrote in message
news:11******** **************@ 16g2000cwy.goog legroups.com...

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

Hello,

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

[Mark Rae]

"Bhagya" <ja**********@g mail.comwrote in message
news:11******** **************@ f1g2000cwa.goog legroups.com...

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:

PrincipalPermis sionAttribute 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 PrincipalPermis sion 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. PrincipalPermis sionAttribute 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 WindowsPrincipa l. By default, the principal policy is set to
Unauthenticated Principal. If you do not set the principal policy to
WindowsPrincipa l, a demand for principal permission will fail. The following
code should be executed before the principal permission is demanded:
AppDomain.Curre ntDomain.SetPri ncipalPolicy(Pr incipalPolicy.W indowsPrincipal ).

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

....

C#
[PrincipalPermis sionAttribute(S ecurityAction.D emand, Name="Bob",
Role="Superviso r")]

....

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

....

C#
[PrincipalPermis sionAttribute(S ecurityAction.D emand, Name="Bob")]

....

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

....

C#
[PrincipalPermis sionAttribute(S ecurityAction.D emand, Authenticated=t rue)]

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

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
"Bhagya" <ja**********@g mail.comwrote in message
news:11******** *************@j 44g2000cwa.goog legroups.com...

>
Peter Bradley wrote:

>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 innappropriatel y. We usually decorate every Page class, and
every
method that alters the application state. In the case you mention, we
would
have used FormsAuthentica tion.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" <ja**********@g mail.comwrote in message
news:11******* *************** @16g2000cwy.goo glegroups.com.. .

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

Hello,

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