You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by robnangle <ro...@gmail.com> on 2011/06/06 14:26:26 UTC
Clearing @SessionState
Hi All,
I create have a @SessionState on my user but when I try logout it is not
fully clearing the session.
@SessionState
private User user;
onSubmitFromLogout(){
user = null;
return index;
}
Is there a specific way to do it?
Cheers
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4458525.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Essentially i want to destroy the session..
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4458598.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
I want to clear the session so that when another user logs in (say an admin
user) they are the current user in session. at the moment when i log out and
log back in as a different user (an admin user), the previous user is still
in session.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4458593.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by Taha Tapestry <ta...@gmail.com>.
Also if you just want to clear the User object use
ApplicationStateManager.set(User.class, null);
Sent from my iPhone
On Jun 6, 2011, at 5:56 PM, robnangle <ro...@gmail.com> wrote:
> Hi All,
>
> I create have a @SessionState on my user but when I try logout it is not
> fully clearing the session.
>
> @SessionState
> private User user;
>
> onSubmitFromLogout(){
> user = null;
> return index;
> }
>
> Is there a specific way to do it?
> Cheers
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4458525.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 06 Jun 2011 13:35:01 -0300, Rich M <ri...@moremagic.com> wrote:
>> Well does it have to be persisted? I call the adminUser() in every class
>> where it is necessary. The updatePoints() is the constructor so it will
>> be called when the page is loading?
Absolutely no.
> You might want to refresh your knowledge of the page render lifecycle
> and how pages/components operate in T5, based on your comment here.
>
> http://tapestry.apache.org/page-life-cycle.html
>
> Someone else might be better able to explain, but to my knowledge, a
> page is only constructed a minimal amount of times and re-used within
> the application. The page is not constructed to render a response for a
> request.
Until 5.1, with the page pool, pages were instantiated and then reused
later, so the constructor is invoked once per instance in the pool and
never again.
From 5.2 on, a single page instance is used, so the page's constructor is
invoked exactly once.
> You'd be looking to call the logic for a page "loading" or rather being
> requested in the onActivate method, or a render phase like @SetupRender.
Absolutely correct.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Thiago H. de Paula Figueiredo wrote:
>
> I'm sorry, I overlooked the only place user is set. Having been using
> Tapestry since 5.0.5, almost four years ago, I'd say @SessionState works
> as it should. Your code uses too much side-effects for my taste. And I
> can't see the declarations of the username and password variables.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Sorry I must not have copied in the username, it is declared.
Yes I am sure it does just cant quite figure out where I am going wrong. If
the admin user logs in first, it works 100%.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459422.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by Rich M <ri...@moremagic.com>.
On 06/06/2011 01:58 PM, Thiago H. de Paula Figueiredo wrote:
> On Mon, 06 Jun 2011 14:34:20 -0300, robnangle <ro...@gmail.com>
> wrote:
>
>> Eh I dont understand what you mean here. Am i not setting the user when
>> somebody logs in with a valid username and password?
>
> I'm sorry, I overlooked the only place user is set. Having been using
> Tapestry since 5.0.5, almost four years ago, I'd say @SessionState
> works as it should. Your code uses too much side-effects for my taste.
> And I can't see the declarations of the username and password variables.
>
I'd have to say there is too much going on as well as omitted for an
outside observer to really help much more than the suggestions that have
been made by several of us to follow Tapestry standard practices
The best recommendation I could make it to make a much more simplified
version, in separate pages perhaps, where all that happens is a login
page -> authenticate user and establish session state -> display links
depending on user type -> provide log out
Strip out any other logic like the fixtures, etc.
Here's how I might approach it (TML pages left out)
Login page class:
public class Login {
@InjectPage
private userIndex index;
@Inject
private UserDAO udao;
@Component
private Form login;
@Component
private TextField uname;
@Component
private PasswordField pw;
@Property
private String username;
@Property
private String password;
public onSuccessFromLogin(){
if(udao.validateUser( username, password )){
return index.initialize( username );
}else{
login.recordError(uname, "User failed to validate!");
return null;
}
}
}
UserIndex page class:
public class UserIndex {
@SessionState(create=false)
private User user;
public Object initialize(String username){
user = udao.read(username);
return this;
}
@Persist @Property
private Boolean adminUser;
@SetupRender
public void verifyPermissions(){
if(adminUser == null && user != null &&
"Admin".equalsIgnoreCase( user.getUserType() )){
adminUser = true;
}
adminUser = false;
}
@Component
private EventLink logout;
@Inject
private Request req;
@InjectPage
private Login login;
public Object onLogout(){
user = null;
Session session = req.getSession(false);
if(session != null)
session.invalidate();
return login;
}
}
UserDAO interface class:
public interface UserDAO {
public User read(String username);
public boolean validate(String username, String password);
}
UserDAOImpl service class:
public class UserDAOImpl implements UserDAO {
public User read(String username){
User user = null;
Handler handler = new Handler();
Connection conn = handler.getConnection();
PreparedStatement prep;
String read = "Select * from users WHERE username = ?";
prep = conn.prepareStatement( read );
prep.setString(1, username);
ResultSet rs = (ResultSet) prep.executeQuery();
while(rs.next()) {
user = new User();
// TODO: set fields
}
return user;
}
public boolean validate(String username, String password){
User user = null;
Handler handler = new Handler();
Connection conn = handler.getConnection();
PreparedStatement prep;
String read = "Select * from users WHERE username = ? and
password = ?";
prep = conn.prepareStatement( read );
prep.setString(1, username);
prep.setString(2, password);
ResultSet rs = (ResultSet) prep.executeQuery();
if(rs.next()) {
return true;
}
return false;
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 06 Jun 2011 14:34:20 -0300, robnangle <ro...@gmail.com> wrote:
> Eh I dont understand what you mean here. Am i not setting the user when
> somebody logs in with a valid username and password?
I'm sorry, I overlooked the only place user is set. Having been using
Tapestry since 5.0.5, almost four years ago, I'd say @SessionState works
as it should. Your code uses too much side-effects for my taste. And I
can't see the declarations of the username and password variables.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Thiago H. de Paula Figueiredo wrote:
>
> Have you noticed your page code doesn't set the user field anywhere? I
> guess you have a logic issue somewhere.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Eh I dont understand what you mean here. Am i not setting the user when
somebody logs in with a valid username and password?
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459326.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by Josh Canfield <jo...@gmail.com>.
> Well what I thought was correct. When the admin user logs in, he can view
> one correct page. After this any navigation to an admin page will print
> false, i.e. he has not passed the admin test, meaning it has reverted to the
> previous user...
@Persist'ed fields are specific to the page you are on, @SessionState
works between pages. If you leave the page then your isAdmin field for
this page is still set, but it won't be transferred to some other
page.
You should definitely take Rich M's suggestion to refactor your code.
It will make it much easier to read and maintain.
Also, I'm a bit bored so I've decided to give you a free code review:
> public Index() throws Exception {
> createDb();
> transfers = new Transfers();
> transfers.getTransferWeek();
> transfers.getCloseWeek();
> }
As others have pointed out, you should not be using the constructor.
Given that your page object is only constructed once I can only
imagine that this is here to test the database connection when the
page is constructed when your app first starts up. In that case it
should be in a method with a more fitting name:
"testDatabaseConnection".
> public boolean validUser() throws SQLException {
This method is poorly named and has side effects that no experienced
engineer would guess, such as populating the User session state
object. Perhaps "public void loadUser()" would be more appropriate,
even better IMHO would be a DAO such as Rich M outlined so you can
call user = userDAO.load() and everyone would know what you were
talking about.
> public void createDb() throws Exception {
Why is this a public method? Also, this should be handled by a DAO
service so you're not replicating this kind of code all over the
place. And you are actually just preparing the connection not actually
creating a DB right? So, if you're not going to create a proper DAO
then perhaps rename this to "public void prepareDbFields()"?
I read a great book recently which outlines a lot of solid programming
practices.
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Good luck.
Josh
On Mon, Jun 6, 2011 at 10:06 AM, robnangle <ro...@gmail.com> wrote:
>
> Rich M wrote:
>>
>> On 06/06/2011 12:48 PM, robnangle wrote:
>>> Rich M wrote:
>> Fair enough, I was trying to hypothesize at what might be your problem
>> based on the small subset of related code shown. But you're right, that
>> result does not seem to fit with what I said.
>>
>> It would be more clear to see what is happening to the User object if we
>> could see that code that stores and authorizes the User object before it
>> gets to this page where it can be cleared.
>>
>
> package FantasyGaa.pages;
>
> import java.sql.Connection;
> import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.util.ArrayList;
> import java.util.List;
>
> import org.apache.tapestry5.annotations.ApplicationState;
> import org.apache.tapestry5.annotations.Component;
> import org.apache.tapestry5.annotations.InjectPage;
> import org.apache.tapestry5.annotations.Persist;
> import org.apache.tapestry5.annotations.Property;
> import org.apache.tapestry5.annotations.SessionState;
> import org.apache.tapestry5.corelib.components.Form;
> import org.apache.tapestry5.corelib.components.PasswordField;
> import org.apache.tapestry5.ioc.annotations.Inject;
> import org.apache.tapestry5.services.ApplicationStateManager;
> import org.apache.tapestry5.services.Request;
> import org.apache.tapestry5.services.Session;
>
> import Db.AppendPlayerNames;
> import Db.GenerateFixtures;
> import Db.Handler;
> import Db.JoinLeague;
> import Db.Transfers;
> import Entities.Fixture;
> import Entities.Player;
> import Entities.PrivateLeague;
> import Entities.Team;
> import Entities.User;
> import FantasyGaa.pages.Private.JoinPrivateLeague;
> import FantasyGaa.pages.login.Login;
> import FantasyGaa.pages.team.SelectPlayers;
> import FantasyGaa.pages.user.EditUser;
>
>
> public class Index {
> private Handler handler;
> private GenerateFixtures genFix;
> private Connection conn;
> private PreparedStatement prep;
>
>
> @Property
> private Transfers transfers;
>
> private List<Fixture> fixtures;
> private Fixture temp;
>
> @Component
> private Form login;
> @Component
> private Form logout;
> @InjectPage
> private Index index;
>
> @InjectPage
> private EditUser edit;
> @InjectPage
> private Login loginPage;
>
> @SessionState(create=false)
> @Property
> private User user;
>
> @Property
> private boolean userExists;
> @Persist
> private boolean adminUser;
> @Component
> private Form side1;
> @Inject
> private Request request;
>
> public Index() throws Exception {
> createDb();
> transfers = new Transfers();
> transfers.getTransferWeek();
> transfers.getCloseWeek();
> }
>
> public void createDb() throws Exception {
> Handler handler = new Handler();
> conn = handler.getConnection();
> prep = handler.getPreparedStatement();
> }
>
> public boolean adminUser() {
> if(user.getUserType() != null &&
> user.getUserType().equalsIgnoreCase("Admin")) {
> adminUser = true;
> setAdminUser(true);
> System.out.println("true");
> }
> else {
> adminUser = false;
> System.out.println("false");
> }
> return adminUser;
> }
>
> public boolean getAdminUser() {
> return adminUser;
> }
>
> public void setAdminUser(boolean adminUser) {
> this.adminUser = adminUser;
> }
>
> public Object onSubmitFromLogin() throws Exception {
> createDb();
> if (validUser()) {
> adminUser();
> return index;
> }
> else {
> login.recordError("Invalid Login");
> return loginPage;
> }
> }
>
> public Object onSubmitFromLogout() throws Exception {
> user = null;
> Session session = request.getSession(false);
> if (session != null) {
> session.invalidate();
> }
> return index;
> }
>
> public boolean validUser() throws SQLException {
> boolean valid = false;
> String check = "Select * from users WHERE (username=?) AND (password=?)";
> prep = conn.prepareStatement(check);
> prep.setString(1, username);
> prep.setString(2, password);
> ResultSet rs = (ResultSet) prep.executeQuery();
> while(rs.next()) {
> valid = true;
> user = new User();
> user.setTitle(rs.getString("title"));
> user.setFirstName(rs.getString("firstName"));
> user.setLastName(rs.getString("lastName"));
> user.setAddress1(rs.getString("address1"));
> user.setAddress2(rs.getString("address2"));
> user.setCity(rs.getString("city"));
> user.setCounty(rs.getString("county"));
> user.setPhone(rs.getString("phone"));
> user.setEmail(rs.getString("email"));
> user.setUsername(rs.getString("username"));
> user.setPassword(rs.getString("password"));
> user.setUserType(rs.getString("userType"));
> }
> return valid;
> }
> }
>
>
>
> Rich M wrote:
>>
>> Any luck with some debugging messages to verify what methods are getting
>> called in between the working and broken states?
>>
>
> Well what I thought was correct. When the admin user logs in, he can view
> one correct page. After this any navigation to an admin page will print
> false, i.e. he has not passed the admin test, meaning it has reverted to the
> previous user...
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459274.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Have you noticed your page code doesn't set the user field anywhere? I
guess you have a logic issue somewhere.
Your JDBC usage is far from recommended. You're opening a connection in
the constructor and reusing it. If you're using Tapestry 5.2+, you'll end
up having two requests using the same connection at the same time, and
JDBC considers this an error with unpredictable results.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Rich M wrote:
>
> On 06/06/2011 12:48 PM, robnangle wrote:
>> Rich M wrote:
> Fair enough, I was trying to hypothesize at what might be your problem
> based on the small subset of related code shown. But you're right, that
> result does not seem to fit with what I said.
>
> It would be more clear to see what is happening to the User object if we
> could see that code that stores and authorizes the User object before it
> gets to this page where it can be cleared.
>
package FantasyGaa.pages;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.ArrayList;
import java.util.List;
import org.apache.tapestry5.annotations.ApplicationState;
import org.apache.tapestry5.annotations.Component;
import org.apache.tapestry5.annotations.InjectPage;
import org.apache.tapestry5.annotations.Persist;
import org.apache.tapestry5.annotations.Property;
import org.apache.tapestry5.annotations.SessionState;
import org.apache.tapestry5.corelib.components.Form;
import org.apache.tapestry5.corelib.components.PasswordField;
import org.apache.tapestry5.ioc.annotations.Inject;
import org.apache.tapestry5.services.ApplicationStateManager;
import org.apache.tapestry5.services.Request;
import org.apache.tapestry5.services.Session;
import Db.AppendPlayerNames;
import Db.GenerateFixtures;
import Db.Handler;
import Db.JoinLeague;
import Db.Transfers;
import Entities.Fixture;
import Entities.Player;
import Entities.PrivateLeague;
import Entities.Team;
import Entities.User;
import FantasyGaa.pages.Private.JoinPrivateLeague;
import FantasyGaa.pages.login.Login;
import FantasyGaa.pages.team.SelectPlayers;
import FantasyGaa.pages.user.EditUser;
public class Index {
private Handler handler;
private GenerateFixtures genFix;
private Connection conn;
private PreparedStatement prep;
@Property
private Transfers transfers;
private List<Fixture> fixtures;
private Fixture temp;
@Component
private Form login;
@Component
private Form logout;
@InjectPage
private Index index;
@InjectPage
private EditUser edit;
@InjectPage
private Login loginPage;
@SessionState(create=false)
@Property
private User user;
@Property
private boolean userExists;
@Persist
private boolean adminUser;
@Component
private Form side1;
@Inject
private Request request;
public Index() throws Exception {
createDb();
transfers = new Transfers();
transfers.getTransferWeek();
transfers.getCloseWeek();
}
public void createDb() throws Exception {
Handler handler = new Handler();
conn = handler.getConnection();
prep = handler.getPreparedStatement();
}
public boolean adminUser() {
if(user.getUserType() != null &&
user.getUserType().equalsIgnoreCase("Admin")) {
adminUser = true;
setAdminUser(true);
System.out.println("true");
}
else {
adminUser = false;
System.out.println("false");
}
return adminUser;
}
public boolean getAdminUser() {
return adminUser;
}
public void setAdminUser(boolean adminUser) {
this.adminUser = adminUser;
}
public Object onSubmitFromLogin() throws Exception {
createDb();
if (validUser()) {
adminUser();
return index;
}
else {
login.recordError("Invalid Login");
return loginPage;
}
}
public Object onSubmitFromLogout() throws Exception {
user = null;
Session session = request.getSession(false);
if (session != null) {
session.invalidate();
}
return index;
}
public boolean validUser() throws SQLException {
boolean valid = false;
String check = "Select * from users WHERE (username=?) AND (password=?)";
prep = conn.prepareStatement(check);
prep.setString(1, username);
prep.setString(2, password);
ResultSet rs = (ResultSet) prep.executeQuery();
while(rs.next()) {
valid = true;
user = new User();
user.setTitle(rs.getString("title"));
user.setFirstName(rs.getString("firstName"));
user.setLastName(rs.getString("lastName"));
user.setAddress1(rs.getString("address1"));
user.setAddress2(rs.getString("address2"));
user.setCity(rs.getString("city"));
user.setCounty(rs.getString("county"));
user.setPhone(rs.getString("phone"));
user.setEmail(rs.getString("email"));
user.setUsername(rs.getString("username"));
user.setPassword(rs.getString("password"));
user.setUserType(rs.getString("userType"));
}
return valid;
}
}
Rich M wrote:
>
> Any luck with some debugging messages to verify what methods are getting
> called in between the working and broken states?
>
Well what I thought was correct. When the admin user logs in, he can view
one correct page. After this any navigation to an admin page will print
false, i.e. he has not passed the admin test, meaning it has reverted to the
previous user...
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459274.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by Rich M <ri...@moremagic.com>.
On 06/06/2011 12:48 PM, robnangle wrote:
> Rich M wrote:
>> Most likely your page is not loading and assigning the adminUser boolean
>> like you are expecting, and after your initial login, it's not calling
>> any of that code anymore and thus your privileges appear to regress to a
>> normal user, when really you aren't calculating them at all.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
> Also it not only appears to regress, it does regress. The logged in user
> display name reverts to the previous logged in user..
Fair enough, I was trying to hypothesize at what might be your problem
based on the small subset of related code shown. But you're right, that
result does not seem to fit with what I said.
It would be more clear to see what is happening to the User object if we
could see that code that stores and authorizes the User object before it
gets to this page where it can be cleared.
Any luck with some debugging messages to verify what methods are getting
called in between the working and broken states?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Rich M wrote:
>
> Most likely your page is not loading and assigning the adminUser boolean
> like you are expecting, and after your initial login, it's not calling
> any of that code anymore and thus your privileges appear to regress to a
> normal user, when really you aren't calculating them at all.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Also it not only appears to regress, it does regress. The logged in user
display name reverts to the previous logged in user..
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459203.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Richard Hill-7 wrote:
>
> Rich's point is that pages are re-used: a fresh instance of a page is
> not instantiated for each request. So yes you'll have your transfer data
> rendering in the page, but that doesn't mean that data was
> collected/built/queried from db or whatever in response to the current
> request.
>
> AFAIK constructors are not the place to put initialisation stuff: as
> Rich suggested take a look at the @SetupRender annotation and/or the
> setupRender() method.
>
> R.
>
Yes I should be using the setupRender() method, as I have used it elsewhere.
However it does not solve the issue. The user seems to be completely
reverting to the previous logged in user after navigating through more than
one page.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459227.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by Richard Hill <ri...@su3analytics.com>.
Rich's point is that pages are re-used: a fresh instance of a page is
not instantiated for each request. So yes you'll have your transfer data
rendering in the page, but that doesn't mean that data was
collected/built/queried from db or whatever in response to the current
request.
AFAIK constructors are not the place to put initialisation stuff: as
Rich suggested take a look at the @SetupRender annotation and/or the
setupRender() method.
R.
On Mon, 2011-06-06 at 09:42 -0700, robnangle wrote:
> Rich M wrote:
> >
> > On 06/06/2011 12:20 PM, robnangle wrote:
> >> Rich M wrote:
> >>> On 06/06/2011 12:04 PM, robnangle wrote:
> >>>> No didn't seem to make a difference im afraid. I cant think of anything
> >>>> that
> >>>> would revert the user back to the previous logged in user?
> >>>>
> >>>> My updated code now looks like:
> >>>>
> >>>> @SessionState(create=false)
> >>>> @Property
> >>>> private User user;
> >>>> @Property
> >>>> private boolean userExists;
> >>>> @Property
> >>>> private Transfers transfers;
> >>>>
> >>>> private boolean adminUser;
> >>> Don't know the rest of your code, but if this boolean adminUser
> >>> determines whether or not show pages, it should be persisted shouldn't
> >>> it? Otherwise the value set here is going to clear. When is
> >>> UpdatePoints() called?
> >>>
> >
> >> Well does it have to be persisted? I call the adminUser() in every class
> >> where it is necessary. The updatePoints() is the constructor so it will
> >> be
> >> called when the page is loading?
> >>
> >
> > You might want to refresh your knowledge of the page render lifecycle
> > and how pages/components operate in T5, based on your comment here.
> >
> > http://tapestry.apache.org/page-life-cycle.html
> >
> > Someone else might be better able to explain, but to my knowledge, a
> > page is only constructed a minimal amount of times and re-used within
> > the application. The page is not constructed to render a response for a
> > request.
> >
> > You'd be looking to call the logic for a page "loading" or rather being
> > requested in the onActivate method, or a render phase like @SetupRender.
> >
> > As for persisted or not, if you are maintaining a user session in your
> > application, might I ask what the point is of recalculating their admin
> > status if that never changes within a given session?
> >
> > http://tapestry.apache.org/persistent-page-data.html
> >
> > Most likely your page is not loading and assigning the adminUser boolean
> > like you are expecting, and after your initial login, it's not calling
> > any of that code anymore and thus your privileges appear to regress to a
> > normal user, when really you aren't calculating them at all.
> >
> > You might have an easier time figuring this out using some System.out
> > commands or better yet using the built-in logging support @Inject
> > private Logger log; and provide a Log4J configuration file in
> > src/main/resources
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
> Yes I agree with you that it is pointless recalculating whether its an admin
> user or not. However that constructor is defientley being called as the
> transfers display in a sidebar and if it was not being called the transfers
> would not display (also them transfers being persisted would make more sense
> too).
>
> So I dont think its a problem of it not being called or not?
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459190.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Rich M wrote:
>
> On 06/06/2011 12:20 PM, robnangle wrote:
>> Rich M wrote:
>>> On 06/06/2011 12:04 PM, robnangle wrote:
>>>> No didn't seem to make a difference im afraid. I cant think of anything
>>>> that
>>>> would revert the user back to the previous logged in user?
>>>>
>>>> My updated code now looks like:
>>>>
>>>> @SessionState(create=false)
>>>> @Property
>>>> private User user;
>>>> @Property
>>>> private boolean userExists;
>>>> @Property
>>>> private Transfers transfers;
>>>>
>>>> private boolean adminUser;
>>> Don't know the rest of your code, but if this boolean adminUser
>>> determines whether or not show pages, it should be persisted shouldn't
>>> it? Otherwise the value set here is going to clear. When is
>>> UpdatePoints() called?
>>>
>
>> Well does it have to be persisted? I call the adminUser() in every class
>> where it is necessary. The updatePoints() is the constructor so it will
>> be
>> called when the page is loading?
>>
>
> You might want to refresh your knowledge of the page render lifecycle
> and how pages/components operate in T5, based on your comment here.
>
> http://tapestry.apache.org/page-life-cycle.html
>
> Someone else might be better able to explain, but to my knowledge, a
> page is only constructed a minimal amount of times and re-used within
> the application. The page is not constructed to render a response for a
> request.
>
> You'd be looking to call the logic for a page "loading" or rather being
> requested in the onActivate method, or a render phase like @SetupRender.
>
> As for persisted or not, if you are maintaining a user session in your
> application, might I ask what the point is of recalculating their admin
> status if that never changes within a given session?
>
> http://tapestry.apache.org/persistent-page-data.html
>
> Most likely your page is not loading and assigning the adminUser boolean
> like you are expecting, and after your initial login, it's not calling
> any of that code anymore and thus your privileges appear to regress to a
> normal user, when really you aren't calculating them at all.
>
> You might have an easier time figuring this out using some System.out
> commands or better yet using the built-in logging support @Inject
> private Logger log; and provide a Log4J configuration file in
> src/main/resources
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Yes I agree with you that it is pointless recalculating whether its an admin
user or not. However that constructor is defientley being called as the
transfers display in a sidebar and if it was not being called the transfers
would not display (also them transfers being persisted would make more sense
too).
So I dont think its a problem of it not being called or not?
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459190.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by Rich M <ri...@moremagic.com>.
On 06/06/2011 12:20 PM, robnangle wrote:
> Rich M wrote:
>> On 06/06/2011 12:04 PM, robnangle wrote:
>>> No didn't seem to make a difference im afraid. I cant think of anything
>>> that
>>> would revert the user back to the previous logged in user?
>>>
>>> My updated code now looks like:
>>>
>>> @SessionState(create=false)
>>> @Property
>>> private User user;
>>> @Property
>>> private boolean userExists;
>>> @Property
>>> private Transfers transfers;
>>>
>>> private boolean adminUser;
>> Don't know the rest of your code, but if this boolean adminUser
>> determines whether or not show pages, it should be persisted shouldn't
>> it? Otherwise the value set here is going to clear. When is
>> UpdatePoints() called?
>>
> Well does it have to be persisted? I call the adminUser() in every class
> where it is necessary. The updatePoints() is the constructor so it will be
> called when the page is loading?
>
You might want to refresh your knowledge of the page render lifecycle
and how pages/components operate in T5, based on your comment here.
http://tapestry.apache.org/page-life-cycle.html
Someone else might be better able to explain, but to my knowledge, a
page is only constructed a minimal amount of times and re-used within
the application. The page is not constructed to render a response for a
request.
You'd be looking to call the logic for a page "loading" or rather being
requested in the onActivate method, or a render phase like @SetupRender.
As for persisted or not, if you are maintaining a user session in your
application, might I ask what the point is of recalculating their admin
status if that never changes within a given session?
http://tapestry.apache.org/persistent-page-data.html
Most likely your page is not loading and assigning the adminUser boolean
like you are expecting, and after your initial login, it's not calling
any of that code anymore and thus your privileges appear to regress to a
normal user, when really you aren't calculating them at all.
You might have an easier time figuring this out using some System.out
commands or better yet using the built-in logging support @Inject
private Logger log; and provide a Log4J configuration file in
src/main/resources
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Rich M wrote:
>
> On 06/06/2011 12:04 PM, robnangle wrote:
>> No didn't seem to make a difference im afraid. I cant think of anything
>> that
>> would revert the user back to the previous logged in user?
>>
>> My updated code now looks like:
>>
>> @SessionState(create=false)
>> @Property
>> private User user;
>> @Property
>> private boolean userExists;
>> @Property
>> private Transfers transfers;
>>
>> private boolean adminUser;
> Don't know the rest of your code, but if this boolean adminUser
> determines whether or not show pages, it should be persisted shouldn't
> it? Otherwise the value set here is going to clear. When is
> UpdatePoints() called?
>
>> @Inject
>> private Request request;
>>
>> public UpdatePoints() {
>> transfers = new Transfers();
>> transfers.getTransferWeek();
>> transfers.getCloseWeek();
>> adminUser();
>> }
>>
>> public boolean adminUser() {
>> if(user.getUserType() != null&&
>> user.getUserType().equalsIgnoreCase("Admin")) {
>> adminUser = true;
>> setAdminUser(true);
>> }
>> else {
>> adminUser = false;
>> }
>> return adminUser;
>> }
>>
>> public boolean getAdminUser() {
>> return adminUser;
>> }
>>
>> public void setAdminUser(boolean adminUser) {
>> this.adminUser = adminUser;
>> }
>>
>> public Object onSubmitFromLogout() throws Exception {
>> user = null;
>> Session session = request.getSession(false);
>> if (session != null) {
>> session.invalidate();
>> }
>> return index;
>> }
>>
>>
>> --
>> View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459081.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Well does it have to be persisted? I call the adminUser() in every class
where it is necessary. The updatePoints() is the constructor so it will be
called when the page is loading?
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459132.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by Rich M <ri...@moremagic.com>.
On 06/06/2011 12:04 PM, robnangle wrote:
> No didn't seem to make a difference im afraid. I cant think of anything that
> would revert the user back to the previous logged in user?
>
> My updated code now looks like:
>
> @SessionState(create=false)
> @Property
> private User user;
> @Property
> private boolean userExists;
> @Property
> private Transfers transfers;
>
> private boolean adminUser;
Don't know the rest of your code, but if this boolean adminUser
determines whether or not show pages, it should be persisted shouldn't
it? Otherwise the value set here is going to clear. When is
UpdatePoints() called?
> @Inject
> private Request request;
>
> public UpdatePoints() {
> transfers = new Transfers();
> transfers.getTransferWeek();
> transfers.getCloseWeek();
> adminUser();
> }
>
> public boolean adminUser() {
> if(user.getUserType() != null&&
> user.getUserType().equalsIgnoreCase("Admin")) {
> adminUser = true;
> setAdminUser(true);
> }
> else {
> adminUser = false;
> }
> return adminUser;
> }
>
> public boolean getAdminUser() {
> return adminUser;
> }
>
> public void setAdminUser(boolean adminUser) {
> this.adminUser = adminUser;
> }
>
> public Object onSubmitFromLogout() throws Exception {
> user = null;
> Session session = request.getSession(false);
> if (session != null) {
> session.invalidate();
> }
> return index;
> }
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459081.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Richard Hill-7 wrote:
>
> Could there be a browser-caching issue here? If the URLs are the same,
> but with different views for logged-in and logged out, perhaps being
> cached?
>
>
>> > Thiago H. de Paula Figueiredo
>> > Independent Java, Apache Tapestry 5 and Hibernate consultant,
>> developer,
>> > and instructor
>> > Owner, Ars Machina Tecnologia da Informação Ltda.
>> > http://www.arsmachina.com.br
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>
No didn't seem to make a difference im afraid. I cant think of anything that
would revert the user back to the previous logged in user?
My updated code now looks like:
@SessionState(create=false)
@Property
private User user;
@Property
private boolean userExists;
@Property
private Transfers transfers;
private boolean adminUser;
@Inject
private Request request;
public UpdatePoints() {
transfers = new Transfers();
transfers.getTransferWeek();
transfers.getCloseWeek();
adminUser();
}
public boolean adminUser() {
if(user.getUserType() != null &&
user.getUserType().equalsIgnoreCase("Admin")) {
adminUser = true;
setAdminUser(true);
}
else {
adminUser = false;
}
return adminUser;
}
public boolean getAdminUser() {
return adminUser;
}
public void setAdminUser(boolean adminUser) {
this.adminUser = adminUser;
}
public Object onSubmitFromLogout() throws Exception {
user = null;
Session session = request.getSession(false);
if (session != null) {
session.invalidate();
}
return index;
}
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459081.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by Richard Hill <ri...@su3analytics.com>.
Could there be a browser-caching issue here? If the URLs are the same,
but with different views for logged-in and logged out, perhaps being
cached?
On Mon, 2011-06-06 at 08:30 -0700, robnangle wrote:
> Thiago H. de Paula Figueiredo wrote:
> >
> > I'm sorry, but I need to ask: have you checked what the actual user is
> > when granting access or not to the admin page? Are you sure your
> > authentication code is correct?
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> > and instructor
> > Owner, Ars Machina Tecnologia da Informação Ltda.
> > http://www.arsmachina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
> Yes the code seems to be correct. When i login after a logout the immediate
> page that loads is one which the admin user should see, which is correct.
> You can click on an admin only link and that page will load but after this
> it seems to revert back to the previous user and you will then be unable to
> view admin pages (even though I just logged in as an admin user).
>
> It seems to be setting itself to the previous user for some reason?
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459002.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Thiago H. de Paula Figueiredo wrote:
>
> I'm sorry, but I need to ask: have you checked what the actual user is
> when granting access or not to the admin page? Are you sure your
> authentication code is correct?
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Yes the code seems to be correct. When i login after a logout the immediate
page that loads is one which the admin user should see, which is correct.
You can click on an admin only link and that page will load but after this
it seems to revert back to the previous user and you will then be unable to
view admin pages (even though I just logged in as an admin user).
It seems to be setting itself to the previous user for some reason?
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459002.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 06 Jun 2011 10:18:20 -0300, robnangle <ro...@gmail.com> wrote:
> However it still does not seem to be working.
> The problem is that it still does not seem to be clearing.
> I have admin pages that only an admin user can view. The code behind
> that is working as when i login at first it determines that it is an
> admin user and grants them access. The problem arises when I log in as a
> normal user, then logout and try log in as an admin user. It will not
> grant them access as the normal user seems to be still in session.
I'm sorry, but I need to ask: have you checked what the actual user is
when granting access or not to the admin page? Are you sure your
authentication code is correct?
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by robnangle <ro...@gmail.com>.
Thiago H. de Paula Figueiredo wrote:
>
> On Mon, 06 Jun 2011 09:26:26 -0300, robnangle <robnangle@gmail.com>
> wrote:
>
>> Hi All,
>
> Hi!
>
>> I create have a @SessionState on my user but when I try logout it is not
>> fully clearing the session.
>>
>> @SessionState
>> private User user;
>
> Setting a @SessionState field to null will remove it from the session, but
> just it. And don't forget that when you use @SessionState and the object
> isn't in the session it's instantiated automatically and put in the
> session. @SessionState(create = false) prevent this.
>
> To invalidate (clear) the session, use this:
>
> @Inject
> private Request request;
>
> Session session = request.getSession(false);
> if (session != null) {
> session.invalidate();
> }
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Thanks for the reply.
However it still does not seem to be working.
The problem is that it still does not seem to be clearing.
I have admin pages that only an admin user can view. The code behind that is
working as when i login at first it determines that it is an admin user and
grants them access. The problem arises when I log in as a normal user, then
logout and try log in as an admin user. It will not grant them access as the
normal user seems to be still in session.
Any idea's?
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4458637.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 06 Jun 2011 09:26:26 -0300, robnangle <ro...@gmail.com> wrote:
> Hi All,
Hi!
> I create have a @SessionState on my user but when I try logout it is not
> fully clearing the session.
>
> @SessionState
> private User user;
Setting a @SessionState field to null will remove it from the session, but
just it. And don't forget that when you use @SessionState and the object
isn't in the session it's instantiated automatically and put in the
session. @SessionState(create = false) prevent this.
To invalidate (clear) the session, use this:
@Inject
private Request request;
Session session = request.getSession(false);
if (session != null) {
session.invalidate();
}
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by Taha Tapestry <ta...@gmail.com>.
Use session.invalidate()
Sent from my iPhone
On Jun 6, 2011, at 5:56 PM, robnangle <ro...@gmail.com> wrote:
> Hi All,
>
> I create have a @SessionState on my user but when I try logout it is not
> fully clearing the session.
>
> @SessionState
> private User user;
>
> onSubmitFromLogout(){
> user = null;
> return index;
> }
>
> Is there a specific way to do it?
> Cheers
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4458525.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by Richard Hill <ri...@su3analytics.com>.
What do you mean exactly "not clearing the session" ?
Al you are doing below is setting the user to null, the session is not
being destroyed and nothing else in the session will be affected.
On Mon, 2011-06-06 at 05:26 -0700, robnangle wrote:
> Hi All,
>
> I create have a @SessionState on my user but when I try logout it is not
> fully clearing the session.
>
> @SessionState
> private User user;
>
> onSubmitFromLogout(){
> user = null;
> return index;
> }
>
> Is there a specific way to do it?
> Cheers
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4458525.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Clearing @SessionState
Posted by ael <al...@dash.com.ph>.
Why not use TAPESTRY-SECURITY by Kalle :)
this is more advanced...
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4460330.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org