http://jakarta.apache.org/tapestry/doc/api/org/apache/tapestry/IRequestCycle.html#encodeURL(java.lang.String)
I suspect that the issue has to do with the use of cookies and your transition between http and https. Try disabling cookies in Tomcat and see if your application bahaves correctly. Let me know what happens.
Paul
Rob Bugh wrote:
Taking Paul's lead I decided to add the session id to the redirect URL, see code below, and this works, which begs several questions. How is the session id normally preserved between calls to the ApplicationServlet (doGet or doPost)? And why did my original redirect not work? Can I use the getAbsoluteURL() api to build the URL with the session id added?
// Build a URL with session id to the Account Page
RequestContext request = cycle.getRequestContext();
StringBuffer strbuf = new StringBuffer();
strbuf.append("http://";).append(request.getServerName()).append(cycle.getEngine().getServletPath());
HttpSession session = request.getSession(); if (session != null) { strbuf.append(";jsessionid=").append(session.getId()); }
strbuf.append("?service=page/Account");
Thanks, Rob
On Fri, 01 Apr 2005 23:06:28 -0600, Rob Bugh <[EMAIL PROTECTED]> wrote:
Hi Paul,
Here are the details as to how I'm redirecting on each step
step 2. Home page -> Logon page. This is a @PageLink with a renderer="ognl:beans.httpsRenderer" in the html template.
step 3. Logon page -> Account page. The Logon page uses the following code to redirect to the Account Page:
RequestContext request = cycle.getRequestContext();
ILink link = cycle.getEngine().getService(Tapestry.PAGE_SERVICE).getLink(cycle, cycle.getPage(), new String[] { "Account" });
throw new RedirectException(link.getAbsoluteURL("http", request.getServerName(), 80, null, true));
The difference from yours being the second parameter to the call to getAbsoluteURL().
Rob
On Fri, 01 Apr 2005 18:20:54 -0800, Paul Ferraro <[EMAIL PROTECTED]> wrote:
I suspect that your issue has to do with the way you are generating your url for RedirectException(). I would guess that the user's session id is not being encoded properly.
Can you explain how you are generating your redirect url in step 3?
To properly generate a non-SSL redirect to your login page from an SSL request, you should use something like this:
IEngineService service = cycle.getEngine().getService(Tapestry.PAGE_SERVICE);
ILink link = service.getLink(cycle, cycle.getPage(), new Object[] { "Account" });
throw new RedirectException(link.getAbsoluteURL("http", null, "80", null, true));
Paul
Rob Bugh wrote:
Hi All,
Has anyone delt with this problem before? If so, I could use some hand-holding. I'm having a problem during logon of my Tapestry application after a session timeout. Here is the scenario that I use to recreate the problem. I realize there is much detail missing here but I'm not sure where else to begin. I'll provide more detail as needed.
0. Using Tapestry 3.0.1 and Tomcat 5
1. I browse to my Home page and let the browser sit until the session times out
2. Click on the logon button, PageRedirect (using https) to the Logon page
3. Fill in the name and password and hit enter. At this point I see from debug messages that the user is authenticated, their credentials are stuffed into the Visit object, and a RedirectException (using http) is thrown to send the user to the Account page.
4. The pageValidate() method of the Account page complains, however, that the Visit object is null (using the (Visit)getEngine().getVisit() api) and redirects the user back to the Home page.
If I immediately try this scenario again logon succeeds and the Account page is displayed. The problem appears to be related to the fact that I started with a timed out session. I tried tracing through the Tapestry code to see what was going on and as best as I could determine, when the failure occurs, the session is not being preserved from step 3 to 4, i.e., no session exists when the doGet() method of ApplicationServlet is called for step 4. This leads to a new engine being created which explains why the Visit object was null in the pageValidate() call in step 4.
Your thoughs are appreciated.
Thanks, Rob
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
