or just put @requireshttps on your base page

-igor

On Sat, Apr 30, 2011 at 6:49 PM, Alec Swan <alecs...@gmail.com> wrote:
> Thank you for the great hint! It seems like a lot of people have a
> problem JSESSIONID cookie being lost by Tomcat when switching from
> HTTPS to HTTP. We are switching in the opposite direction, but I
> assume the could be problematic as well.
>
> At this point we are willing to force HTTPS for the entire webapp in
> order to avoid this problem. What's the recommended way to force all
> requests to go over HTTPS in production and go over HTTP in
> development?
>
> Should we use <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> in web.xml and also override protected IRequestCycleProcessor
> newRequestCycleProcessor() as explained here:
> https://cwiki.apache.org/WICKET/how-to-switch-to-ssl-mode.html
>
> Thanks,
>
> Alec
>
> On Sat, Apr 30, 2011 at 7:10 PM, Igor Vaynberg <igor.vaynb...@gmail.com> 
> wrote:
>> this is because cookies created in http are not transferred to https
>> and viceversa afair. i think this can be changed by turning off secure
>> cookies in tomcat or something like that.
>>
>> -igor
>>
>>
>> On Sat, Apr 30, 2011 at 6:06 PM, Alec Swan <alecs...@gmail.com> wrote:
>>> Even if the next request is made from inside an IFrame? If so, is this
>>> problem definitely a problem with the load balancer setup?
>>>
>>> Our hosting company ran HTTP trace and said this:
>>>
>>>> Customer connects to the cluster via HTTP, in this case they are routed to 
>>>> web2.
>>>>This packet passes through the load balancer, where a cookie is added by 
>>>>the LB. It adds a cookie to every packet that comes back from the server, so
>>>> that the next connection goes to the same server.
>>>>
>>>> In the next request from the client to the server, we see both cookies in 
>>>> place.
>>>>
>>>> This continues on normally for a while with all packet headers containing 
>>>> the Cookies above.
>>>>
>>>> web1 suddenly gets a request for https, that does not contain any cookies, 
>>>> this has to be a new connection, there are no LB or JSESSION
>>>> Cookies in these packets.
>>>>
>>>> Then, the next request goes back to web2 at this point we know we're going 
>>>> to get an error, after the above happens.
>>>
>>> What happens is that the user is browsing the web site and then clicks
>>> a link which pops up a modal window with @RequireHttps annotation on
>>> it. This is when the modal window shows an error saying that page
>>> cannot be found in the page map.
>>>
>>> We continue working with the hosting company, but we would appreciate
>>> any thoughts on this.
>>>
>>> Thanks,
>>>
>>> Alec
>>>
>>> On Sat, Apr 30, 2011 at 6:16 PM, Igor Vaynberg <igor.vaynb...@gmail.com> 
>>> wrote:
>>>> one does not need to copy cookies because browsers retain them across 
>>>> requests.
>>>>
>>>> -igor
>>>>
>>>>
>>>> On Sat, Apr 30, 2011 at 5:01 PM, Alec Swan <alecs...@gmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> I tried copying all cookies from the HTTP request to HTTP response and
>>>>> it seemed to have a positive effect (unless our hosting company fixed
>>>>> something on their load balancer). However, I would expect Wicket to
>>>>> copy cookies from request to response by default, is this true?
>>>>>
>>>>> Here is the code I added trying to fix the problem with the load
>>>>> balancer cookie being lost:
>>>>>
>>>>> // copy all cookies from parent page to modal window in order to
>>>>> support sticky sessions on load balancer
>>>>>                    Cookie[] cookies = ((WebRequest)
>>>>> getRequestCycle().getRequest()).getCookies();
>>>>>                    for (Cookie cookie : cookies) {
>>>>>                        ((WebResponse)
>>>>> getRequestCycle().getResponse()).addCookie(cookie);
>>>>>                    }
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Alec
>>>>>
>>>>> On Fri, Apr 29, 2011 at 4:17 PM, Alec Swan <alecs...@gmail.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> We just put our webapp behind a load balancer with sticky sessions.
>>>>>> After that we started noticing that load balancer cookie gets lost
>>>>>> when a modal window is popped up by a link click. Here is the code we
>>>>>> use to display the modal window:
>>>>>>
>>>>>> new AjaxLink("editLink")
>>>>>>                    {
>>>>>>                        @Override
>>>>>>                        public void onClick(AjaxRequestTarget target) {
>>>>>>                            modalWindow.setPageCreator(new
>>>>>> ModalWindow.PageCreator() {
>>>>>>                            @Override
>>>>>>                             public Page createPage() {
>>>>>>                                  ....
>>>>>>                             }
>>>>>>                        }
>>>>>>                    });
>>>>>>
>>>>>> How can we make sure that cookies get preserved when we pop up a modal 
>>>>>> window?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Alec
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to