[Wicket-user] Redirection bug?
Hi All,
When a browser does not support cookies (or has cookies turned off) we
all know that session state is maintained using URL rewriting. This is
achieved by calling the following Servlet API method:
javax.servlet.http.HttpServletResponse.encodeURL(http://blahblah;);
According to the servlet API, if the URL being encoded is for
redirection, the following method should be called instead:
javax.servlet.http.HttpServletResponse.encodeRedirectURL(http://blahblah;);
In the source code for wicket.protocol.http.WicketResponse, it can be
seen that wicket always uses the encodeURL method for redirects. The
result is that the 'Location' header set in redirects does not include
the jsessionid URL parameter and so session state is not maintained
(resulting in new sessions or session time-outs etc).
I have implemented a fix for wicket 1.2.1 (see attachment), which seems
to resolve the issue, but I'm unsure if this will cause any other
issues, so I would appreciate any suggestions or feedback.
Kind regards,
/james
===
James Carnegie
Senior Analyst Programmer/Development Team Leader
Tel:(+44) (0) 1179081253
Fax:(+44) (0) 1179081494
Email: James Carnegie [EMAIL PROTECTED]
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Although this e-mail
and any attachments are believed to be free of any virus, or any other
defect which might affect any computer or IT system into which they are
received and opened, it is the responsibility of the recipient to ensure
that they are virus free and no responsibility is accepted by Multicom
Products Limited for any loss or damage arising in any way from receipt
or use thereof.
/*
* $Id: WebResponse.java 5231 2006-04-01 15:34:49 -0800 (Sat, 01 Apr 2006)
* joco01 $ $Revision: 6064 $ $Date: 2006-04-01 15:34:49 -0800 (Sat, 01 Apr
* 2006) $
*
* ==
* Licensed under the Apache License, Version 2.0 (the License); you may not
* use this file except in compliance with the License. You may obtain a copy of
* the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations under
* the License.
*/
package wicket.protocol.http;
import java.io.IOException;
import java.io.OutputStream;
import java.util.Locale;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import wicket.Response;
import wicket.WicketRuntimeException;
import wicket.util.string.AppendingStringBuffer;
import wicket.util.string.Strings;
import wicket.util.time.Time;
/**
* Implements responses over the HTTP protocol by holding an underlying
* HttpServletResponse object and providing convenience methods for using that
* object. Convenience methods include methods which: add a cookie, close the
* stream, encode a URL, redirect a request to another resource, determine if a
* redirect has been issued, set the content type, set the locale and, most
* importantly, write a String to the response output.
*
* @author Jonathan Locke
*/
public class WebResponse extends Response
{
/** Log. */
private static final Log log = LogFactory.getLog(WebResponse.class);
/** True if response is a redirect. */
protected boolean redirect;
/** The underlying response object. */
private final HttpServletResponse httpServletResponse;
/**
* Constructor for testing harness.
*/
public WebResponse()
{
this.httpServletResponse = null;
}
/**
* Package private constructor.
*
* @param httpServletResponse
*The servlet response object
*/
public WebResponse(final HttpServletResponse httpServletResponse)
{
this.httpServletResponse = httpServletResponse;
}
/**
* Add a cookie to the web response
*
* @param cookie
*/
public void addCookie(final Cookie cookie)
{
getHttpServletResponse().addCookie(cookie);
}
/**
* Convenience method for clearing a cookie.
*
* @param cookie
*The cookie to set
* @see WebResponse#addCookie(Cookie)
*/
public void clearCookie(final Cookie cookie)
{
cookie.setMaxAge(0);
cookie.setValue(null);
addCookie(cookie);
}
/**
* Closes response output.
*/
public void close()
{
// NOTE: Servlet container will close the response output stream
// automatically, so we do nothing here.
}
/**
* Returns the given url encoded.
*
*
Re: [Wicket-user] Redirection bug?
hmm this is a good one. Why nobody else pointed out this before. But one problem, it could be that the url was already encoded by the call encodeURL because it is possible that the url was already encoded. Because it is called for example in WebRequestCycle.redirectTo(final Page page) And that gets the url by calling urlFor() that ens up at: WebRequestCodingStrategy.encode(final RequestCycle requestCycle, final IRequestTarget requestTarget) which does: return requestCycle.getOriginalResponse().encodeURL(buffer); and at that point we don't know that it becomes an redirect url or a normal link... So the question is what is the end result? What does encodeRedirectURL do and return? even if encodeURL is already called before on that same url? johan On 12/13/06, James Carnegie [EMAIL PROTECTED] wrote: Hi All, When a browser does not support cookies (or has cookies turned off) we all know that session state is maintained using URL rewriting. This is achieved by calling the following Servlet API method: javax.servlet.http.HttpServletResponse.encodeURL(http://blahblah;); According to the servlet API, if the URL being encoded is for redirection, the following method should be called instead: javax.servlet.http.HttpServletResponse.encodeRedirectURL(http://blahblah ); In the source code for wicket.protocol.http.WicketResponse, it can be seen that wicket always uses the encodeURL method for redirects. The result is that the 'Location' header set in redirects does not include the jsessionid URL parameter and so session state is not maintained (resulting in new sessions or session time-outs etc). I have implemented a fix for wicket 1.2.1 (see attachment), which seems to resolve the issue, but I'm unsure if this will cause any other issues, so I would appreciate any suggestions or feedback. Kind regards, /james === James Carnegie Senior Analyst Programmer/Development Team Leader Tel:(+44) (0) 1179081253 Fax:(+44) (0) 1179081494 Email: James Carnegie [EMAIL PROTECTED] This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Although this e-mail and any attachments are believed to be free of any virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Multicom Products Limited for any loss or damage arising in any way from receipt or use thereof. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Redirection bug?
Below is the Servlet 2.4 API Javadoc for encodeRedirectURL: -- Encodes the specified URL for use in the sendRedirect method or, if encoding is not needed, returns the URL unchanged. The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL. Because the rules for making this determination can differ from those used to decide whether to encode a normal link, this method is separated from the encodeURL method. All URLs sent to the HttpServletResponse.sendRedirect method should be run through this method. Otherwise, URL rewriting cannot be used with browsers which do not support cookies. -- I think this means that it shouldn't break if the URL has already been encoded for redirection, but it is unclear about what might happen if it has already been encoded using the other method. Kind regards, /james Johan Compagner wrote: hmm this is a good one. Why nobody else pointed out this before. But one problem, it could be that the url was already encoded by the call encodeURL because it is possible that the url was already encoded. Because it is called for example in WebRequestCycle.redirectTo(final Page page) And that gets the url by calling urlFor() that ens up at: WebRequestCodingStrategy.encode(final RequestCycle requestCycle, final IRequestTarget requestTarget) which does: return requestCycle.getOriginalResponse().encodeURL(buffer); and at that point we don't know that it becomes an redirect url or a normal link... So the question is what is the end result? What does encodeRedirectURL do and return? even if encodeURL is already called before on that same url? johan On 12/13/06, *James Carnegie* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi All, When a browser does not support cookies (or has cookies turned off) we all know that session state is maintained using URL rewriting. This is achieved by calling the following Servlet API method: javax.servlet.http.HttpServletResponse.encodeURL(http://blahblah http://blahblah); According to the servlet API, if the URL being encoded is for redirection, the following method should be called instead: javax.servlet.http.HttpServletResponse.encodeRedirectURL( http://blahblah;); In the source code for wicket.protocol.http.WicketResponse, it can be seen that wicket always uses the encodeURL method for redirects. The result is that the 'Location' header set in redirects does not include the jsessionid URL parameter and so session state is not maintained (resulting in new sessions or session time-outs etc). I have implemented a fix for wicket 1.2.1 (see attachment), which seems to resolve the issue, but I'm unsure if this will cause any other issues, so I would appreciate any suggestions or feedback. Kind regards, /james === James Carnegie Senior Analyst Programmer/Development Team Leader Tel:(+44) (0) 1179081253 Fax:(+44) (0) 1179081494 Email: James Carnegie [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Although this e-mail and any attachments are believed to be free of any virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Multicom Products Limited for any loss or damage arising in any way from receipt or use thereof. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share
Re: [Wicket-user] Redirection bug?
do you have a test system where you can easily see what the results are exactly? String url = ; String normalEncoded = request.encodeURL(url); String redirectEncoded = request.encodeRedirectURL(url); String normalAndRedirectEncoded = request.encodeRedirectURL(normalEncoded); what is the result of this? johan On 12/13/06, James Carnegie [EMAIL PROTECTED] wrote: Below is the Servlet 2.4 API Javadoc for encodeRedirectURL: -- Encodes the specified URL for use in the sendRedirect method or, if encoding is not needed, returns the URL unchanged. The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL. Because the rules for making this determination can differ from those used to decide whether to encode a normal link, this method is separated from the encodeURL method. All URLs sent to the HttpServletResponse.sendRedirect method should be run through this method. Otherwise, URL rewriting cannot be used with browsers which do not support cookies. -- I think this means that it shouldn't break if the URL has already been encoded for redirection, but it is unclear about what might happen if it has already been encoded using the other method. Kind regards, /james Johan Compagner wrote: hmm this is a good one. Why nobody else pointed out this before. But one problem, it could be that the url was already encoded by the call encodeURL because it is possible that the url was already encoded. Because it is called for example in WebRequestCycle.redirectTo(final Page page) And that gets the url by calling urlFor() that ens up at: WebRequestCodingStrategy.encode(final RequestCycle requestCycle, final IRequestTarget requestTarget) which does: return requestCycle.getOriginalResponse().encodeURL(buffer); and at that point we don't know that it becomes an redirect url or a normal link... So the question is what is the end result? What does encodeRedirectURL do and return? even if encodeURL is already called before on that same url? johan On 12/13/06, *James Carnegie* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi All, When a browser does not support cookies (or has cookies turned off) we all know that session state is maintained using URL rewriting. This is achieved by calling the following Servlet API method: javax.servlet.http.HttpServletResponse.encodeURL(http://blahblah http://blahblah); According to the servlet API, if the URL being encoded is for redirection, the following method should be called instead: javax.servlet.http.HttpServletResponse.encodeRedirectURL( http://blahblah;); In the source code for wicket.protocol.http.WicketResponse, it can be seen that wicket always uses the encodeURL method for redirects. The result is that the 'Location' header set in redirects does not include the jsessionid URL parameter and so session state is not maintained (resulting in new sessions or session time-outs etc). I have implemented a fix for wicket 1.2.1 (see attachment), which seems to resolve the issue, but I'm unsure if this will cause any other issues, so I would appreciate any suggestions or feedback. Kind regards, /james === James Carnegie Senior Analyst Programmer/Development Team Leader Tel:(+44) (0) 1179081253 Fax:(+44) (0) 1179081494 Email: James Carnegie [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Although this e-mail and any attachments are believed to be free of any virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Multicom Products Limited for any loss or damage arising in any way from receipt or use thereof. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net
