Redirects to external URLs do not work as expected when cookies are forbidden

2013-04-04 Thread Oliver Zemann
Hi

I created a wicket quickstart:
https://github.com/olze/WicketRedirect.git

The SC_SEE_OTHER which is defined in the RFC for HTTP 1.1 (iirc Jan. 1997)
was explaining that this should work (sending a post to the application
which uses GET to get the page from the redirected URL) is not working, it
says only 301 and 302 are allowed.
Why?

When using 301 it works as expected when cookies are disabled. When cookies
are disabled and 302 is used, it redirects to the local site and not to the
external one because of the missing Location header. Is this a bug or did i
understand something wrong? I thought 302 should be used when wicket should
redirect to an external URL.

Thanks
Oliver


Re: Redirects to external URLs do not work as expected when cookies are forbidden

2013-04-04 Thread Oliver Zemann
But the warning is thrown by wicket itself that 303 is not allowed. So i am
very sure this is a wicket problem. I use jetty 9 as web server. So the
problems with 301/302 could be related to jetty, but the not working 303 (i
get that exception in wicket) is some kind of problem in wicket.


2013/4/4 Martin Grigorov mgrigo...@apache.org

 Hi,

 I'm not familiar with http code 303 (see other) but if there is a problem
 then you should ask in the forums of the used web container or web browser.
 Wicket just sets response headers via Servlet APIs but the actual work is
 done by the container - to set the header, and by the browser - to read the
 value and interpret it.


 On Thu, Apr 4, 2013 at 10:04 AM, Oliver Zemann oliver.zem...@gmail.com
 wrote:

  Hi
 
  I created a wicket quickstart:
  https://github.com/olze/WicketRedirect.git
 
  The SC_SEE_OTHER which is defined in the RFC for HTTP 1.1 (iirc Jan.
 1997)
  was explaining that this should work (sending a post to the application
  which uses GET to get the page from the redirected URL) is not working,
 it
  says only 301 and 302 are allowed.
  Why?
 
  When using 301 it works as expected when cookies are disabled. When
 cookies
  are disabled and 302 is used, it redirects to the local site and not to
 the
  external one because of the missing Location header. Is this a bug or
 did i
  understand something wrong? I thought 302 should be used when wicket
 should
  redirect to an external URL.
 
  Thanks
  Oliver
 



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/



Re: Redirects to external URLs do not work as expected when cookies are forbidden

2013-04-04 Thread Oliver Zemann
303 would execute a GET instead of POST on the new url. More over, i need
*something* which works when cookies are rejected by the browser. I would
prefer 302 but 302 does not work when cookies are disabled because wicket
checks if its a temporarly or permanent move - if its permanent it sets the
Location header, otherwise not (which makes troubles). And i still dont
think this is jetty related. I will test this in a few days when i find
some time on glassfish. As workaround i use 301 but i guess the customer
will notice that and complain, because 301 has some impact on URLs
(bookmarks, cache etc.) in the browser.


2013/4/4 Martin Grigorov mgrigo...@apache.org

 OK, I see

 public RedirectRequestHandler(final String redirectUrl, final int status)
 {
 if ((status != HttpServletResponse.SC_MOVED_PERMANENTLY) 
  (status != HttpServletResponse.SC_MOVED_TEMPORARILY))
 {
 throw new IllegalStateException(Status must be either 301 or 302, but was:
  + status);
  }

 I'm not sure why there is such restriction. Maybe Igor can explain, git
 blames him.

 What is your reason to use code 303 ? How its semantics are better than 302
 in your case ?



 On Thu, Apr 4, 2013 at 4:35 PM, Oliver Zemann oliver.zem...@gmail.com
 wrote:

  But the warning is thrown by wicket itself that 303 is not allowed. So i
 am
  very sure this is a wicket problem. I use jetty 9 as web server. So the
  problems with 301/302 could be related to jetty, but the not working 303
 (i
  get that exception in wicket) is some kind of problem in wicket.
 
 
  2013/4/4 Martin Grigorov mgrigo...@apache.org
 
   Hi,
  
   I'm not familiar with http code 303 (see other) but if there is a
 problem
   then you should ask in the forums of the used web container or web
  browser.
   Wicket just sets response headers via Servlet APIs but the actual work
 is
   done by the container - to set the header, and by the browser - to read
  the
   value and interpret it.
  
  
   On Thu, Apr 4, 2013 at 10:04 AM, Oliver Zemann 
 oliver.zem...@gmail.com
   wrote:
  
Hi
   
I created a wicket quickstart:
https://github.com/olze/WicketRedirect.git
   
The SC_SEE_OTHER which is defined in the RFC for HTTP 1.1 (iirc Jan.
   1997)
was explaining that this should work (sending a post to the
 application
which uses GET to get the page from the redirected URL) is not
 working,
   it
says only 301 and 302 are allowed.
Why?
   
When using 301 it works as expected when cookies are disabled. When
   cookies
are disabled and 302 is used, it redirects to the local site and not
 to
   the
external one because of the missing Location header. Is this a bug or
   did i
understand something wrong? I thought 302 should be used when wicket
   should
redirect to an external URL.
   
Thanks
Oliver
   
  
  
  
   --
   Martin Grigorov
   jWeekend
   Training, Consulting, Development
   http://jWeekend.com http://jweekend.com/
  
 



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/



Re: Ajax based panel replacement

2012-11-25 Thread Oliver Zemann
As suggested i created the JIRA issue 
https://issues.apache.org/jira/browse/WICKET-4886

I will test the diff tomorrow.

Am 25.11.2012 15:41, schrieb Martin Grigorov:

Hi,


On Sun, Nov 25, 2012 at 9:51 AM, Sven Meier s...@meiers.net wrote:


Make a copy of AbstractAjaxTimerBehavior and let it be stoppable from
onTimer():

diff --git 
a/wicket-core/src/main/java/**org/apache/wicket/ajax/**AbstractAjaxTimerBehavior.java
b/wicket-core/src/main/java/**org/apache/wicket/ajax/**
AbstractAjaxTimerBehavior.java
index 3071875..b982a39 100644
--- a/wicket-core/src/main/java/**org/apache/wicket/ajax/**
AbstractAjaxTimerBehavior.java
+++ b/wicket-core/src/main/java/**org/apache/wicket/ajax/**
AbstractAjaxTimerBehavior.java
@@ -131,8 +131,11 @@
  {
  onTimer(target);

-target.getHeaderResponse().**render(
- OnLoadHeaderItem.forScript(**getJsTimeoutCall(**updateInterval)));
+if (!isStopped())


But this code is already in : if (!isStopped()  isEnabled(getComponent()))
How the second if (!isStopped()) fixes the issue ?



+{
+target.getHeaderResponse().**render(
+ OnLoadHeaderItem.forScript(**getJsTimeoutCall(**updateInterval)));
+}
  }
  }

You could create a jira issue too.


Additionally there are two global Ajax listeners at the bottom of
wicket-ajax-jquery.js which purpose is to remove any obsolete timers.
I haven't debugged the application so I'm not sure where exactly is the
problem.




Sven



On 11/25/2012 01:13 AM, Oliver Zemann wrote:


Unfortunately this is not a solution as i have about 30 different panels.
And i guess at least 10 of them should later use JS. With the approach you
suggested i would have to check which panel should be displayed and load
that (switch/case with 10 different panels). I guess that would also lead
in heavy mixing the panels with the HomePage (BasePage) (destroying
reusability).

There is also no way for me to create a flow based dialogue as this is
done in the backend controller which only tells me which panel to load.

So there is no other way to go?

Am 24.11.2012 22:57, schrieb Sven Meier:


After the timer has fired, AbstractAjaxTimerBehavior automatically
registers another timeout for the form inside PanelOne.
But at that point PanelOne is no longer in the component tree, it's
replaced by PanelTwo already.

I'd recommend adding the behavor to the container instead:

 final WebMarkupContainer wmc = new WebMarkupContainer(container
**);
 wmc.add(new AbstractAjaxTimerBehavior(**Duration.seconds(5)) {
 @Override
 protected void onTimer(AjaxRequestTarget target) {
 PanelTwo two = new PanelTwo(panel);
 wmc.addOrReplace(two);
 target.add(wmc);

 stop(target);
 }
 });
 add(wmc);

 wmc.add(new PanelOne(panel));

This way you won't have to pass 'wmc' to PanelOne any longer.

Sven

On 11/24/2012 10:04 PM, Oliver Zemann wrote:


The problem is that this leads to a Page not found error. The problem
is that the Panel which should be replaced is still looked up in the
findPage() method. But findPage() returns null on that component, so this
error is thrown.

Am 24.11.2012 21:48, schrieb Sven Meier:


What is the problem?

Sven

On 11/24/2012 08:22 PM, Oliver Zemann wrote:


Hi,

i created a small wicket application to show my problem:
https://github.com/olze/**WicketPanelReplacehttps://github.com/olze/WicketPanelReplace

The first panel gets displayed, after a few seconds it should be
replaced by the second panel. Is there any way to achieve this behavior
with that kind of architecture?

If not, how should a ajax based panel wizard work? Any
recommendations?

Thanks in advance.

Oli

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



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



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



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



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

Re: Ajax based panel replacement

2012-11-25 Thread Oliver Zemann


Am 25.11.2012 18:58, schrieb Martin Grigorov:

I see now what Sven meant with the second check for isStopped().

But additionally I see that the quickstart is very broken.

PanelOne does:
form.add(new AbstractAjaxTimerBehavior(Duration.seconds(5)) {
 @Override
 protected void onTimer(AjaxRequestTarget target) {
 PanelTwo two = new PanelTwo(panel);
 wmc.addOrReplace(two);
 }
 });

But it doesn't use 'target' to repaint any component, so the registered JS
timer continues with its original Url which uses the old pageId and
component path to PanelOne. And as expected the second call triggered by
the obsolete timer fails with The behavior's component (a Form which is no
more connected to the Page) cannot find its page.
This is a plain error in the application.
I am pretty new to wicket. If there is a better way to do that, please 
feel free to give me hints :)
I see no other way of doing what i want without using ajax that way 
(directly in the panel instead of the base page).




On Sun, Nov 25, 2012 at 6:34 PM, Oliver Zemann oliver.zem...@gmail.comwrote:


As suggested i created the JIRA issue https://issues.apache.org/**
jira/browse/WICKET-4886https://issues.apache.org/jira/browse/WICKET-4886
I will test the diff tomorrow.

Am 25.11.2012 15:41, schrieb Martin Grigorov:


Hi,


On Sun, Nov 25, 2012 at 9:51 AM, Sven Meier s...@meiers.net wrote:

  Make a copy of AbstractAjaxTimerBehavior and let it be stoppable from

onTimer():

diff --git a/wicket-core/src/main/java/org/apache/wicket/ajax/
AbstractAjaxTimerBehavior.java
b/wicket-core/src/main/java/org/apache/wicket/ajax/**
AbstractAjaxTimerBehavior.java
index 3071875..b982a39 100644
--- a/wicket-core/src/main/java/org/apache/wicket/ajax/**
AbstractAjaxTimerBehavior.java
+++ b/wicket-core/src/main/java/org/apache/wicket/ajax/**

AbstractAjaxTimerBehavior.java
@@ -131,8 +131,11 @@
   {
   onTimer(target);

-target.getHeaderResponse().render(
- OnLoadHeaderItem.forScript(getJsTimeoutCall(updateInterval)));
+if (!isStopped())

  But this code is already in : if (!isStopped() 

isEnabled(getComponent()))
How the second if (!isStopped()) fixes the issue ?


  +{

+target.getHeaderResponse().render(
+ OnLoadHeaderItem.forScript(getJsTimeoutCall(updateInterval)));

+}
   }
   }

You could create a jira issue too.


Additionally there are two global Ajax listeners at the bottom of
wicket-ajax-jquery.js which purpose is to remove any obsolete timers.
I haven't debugged the application so I'm not sure where exactly is the
problem.




Sven



On 11/25/2012 01:13 AM, Oliver Zemann wrote:

  Unfortunately this is not a solution as i have about 30 different

panels.
And i guess at least 10 of them should later use JS. With the approach
you
suggested i would have to check which panel should be displayed and load
that (switch/case with 10 different panels). I guess that would also
lead
in heavy mixing the panels with the HomePage (BasePage) (destroying
reusability).

There is also no way for me to create a flow based dialogue as this is
done in the backend controller which only tells me which panel to load.

So there is no other way to go?

Am 24.11.2012 22:57, schrieb Sven Meier:

  After the timer has fired, AbstractAjaxTimerBehavior automatically

registers another timeout for the form inside PanelOne.
But at that point PanelOne is no longer in the component tree, it's
replaced by PanelTwo already.

I'd recommend adding the behavor to the container instead:

  final WebMarkupContainer wmc = new
WebMarkupContainer(container
**);
  wmc.add(new AbstractAjaxTimerBehavior(Duration.seconds(5))
{

  @Override
  protected void onTimer(AjaxRequestTarget target) {
  PanelTwo two = new PanelTwo(panel);
  wmc.addOrReplace(two);
  target.add(wmc);

  stop(target);
  }
  });
  add(wmc);

  wmc.add(new PanelOne(panel));

This way you won't have to pass 'wmc' to PanelOne any longer.

Sven

On 11/24/2012 10:04 PM, Oliver Zemann wrote:

  The problem is that this leads to a Page not found error. The problem

is that the Panel which should be replaced is still looked up in the
findPage() method. But findPage() returns null on that component, so
this
error is thrown.

Am 24.11.2012 21:48, schrieb Sven Meier:

  What is the problem?

Sven

On 11/24/2012 08:22 PM, Oliver Zemann wrote:

  Hi,

i created a small wicket application to show my problem:
https://github.com/olze/WicketPanelReplacehttps://github.com/olze/**WicketPanelReplace
https://**github.com/olze/**WicketPanelReplacehttps://github.com/olze/WicketPanelReplace

The first panel gets displayed, after a few seconds it should be
replaced by the second panel. Is there any way

Re: Ajax based panel replacement

2012-11-25 Thread Oliver Zemann
Are the changes pushed to the git repo? Or is this only a solution which 
will work in my case but will not be pushed because of side effects, no 
necessity etc.?


Thanks in advance.

Oli

Am 25.11.2012 20:25, schrieb Sven Meier:

Without the 'true ||'.


Great :)

Sven

On 11/25/2012 07:15 PM, Martin Grigorov wrote:
On Sun, Nov 25, 2012 at 7:14 PM, Martin Grigorov 
mgrigo...@apache.orgwrote:



diff --git
a/wicket-core/src/main/java/org/apache/wicket/ajax/AbstractAjaxTimerBehavior.java 

b/wicket-core/src/main/java/org/apache/wicket/ajax/AbstractAjaxTimerBehavior.java 


index 3071875..0651c33 100644
---
a/wicket-core/src/main/java/org/apache/wicket/ajax/AbstractAjaxTimerBehavior.java 


+++
b/wicket-core/src/main/java/org/apache/wicket/ajax/AbstractAjaxTimerBehavior.java 


@@ -21,6 +21,7 @@ import
org.apache.wicket.core.util.string.JavaScriptUtils;
  import org.apache.wicket.markup.head.IHeaderResponse;
  import org.apache.wicket.markup.head.JavaScriptHeaderItem;
  import org.apache.wicket.markup.head.OnLoadHeaderItem;
+import org.apache.wicket.markup.html.WebPage;
  import org.apache.wicket.request.http.WebRequest;
  import org.apache.wicket.util.time.Duration;

@@ -127,15 +128,25 @@ public abstract class AbstractAjaxTimerBehavior
extends AbstractDefaultAjaxBehav
 @Override
 protected final void respond(final AjaxRequestTarget target)
 {
-   if (!isStopped()  isEnabled(getComponent()))
+   if (shouldTrigger())
  {
 onTimer(target);

-   target.getHeaderResponse().render(
-
OnLoadHeaderItem.forScript(getJsTimeoutCall(updateInterval)));
+   if (true || shouldTrigger())


Without the 'true ||'.



+   {
+ target.getHeaderResponse().render(
+
OnLoadHeaderItem.forScript(getJsTimeoutCall(updateInterval)));
+   }
 }
 }

+   private boolean shouldTrigger()
+   {
+   return isStopped() == false 
+   isEnabled(getComponent()) 
+ getComponent().findParent(WebPage.class)
!= null;
+   }
+
 /**



On Sun, Nov 25, 2012 at 7:07 PM, Sven Meier s...@meiers.net wrote:


Of course the component should be added to the ART.
But the example already fails when the behavior tries to write out the
next timeout after #onTimer().

This is why I think it should re-check #isStopped(), since the user 
might

stop the timer in #onTimer().

I'll take a look at WICKET-4886.

Sven


On 11/25/2012 06:58 PM, Martin Grigorov wrote:


I see now what Sven meant with the second check for isStopped().

But additionally I see that the quickstart is very broken.

PanelOne does:
form.add(new AbstractAjaxTimerBehavior(**Duration.seconds(5)) {
  @Override
  protected void onTimer(AjaxRequestTarget target) {
  PanelTwo two = new PanelTwo(panel);
  wmc.addOrReplace(two);
  }
  });

But it doesn't use 'target' to repaint any component, so the 
registered

JS
timer continues with its original Url which uses the old pageId and
component path to PanelOne. And as expected the second call 
triggered by
the obsolete timer fails with The behavior's component (a Form 
which is

no
more connected to the Page) cannot find its page.
This is a plain error in the application.



On Sun, Nov 25, 2012 at 6:34 PM, Oliver Zemann 
oliver.zem...@gmail.com

**wrote:

  As suggested i created the JIRA issue https://issues.apache.org/**

jira/browse/WICKET-4886https:**//issues.apache.org/jira/**
browse/WICKET-4886 
https://issues.apache.org/jira/browse/WICKET-4886


I will test the diff tomorrow.

Am 25.11.2012 15:41, schrieb Martin Grigorov:

  Hi,


On Sun, Nov 25, 2012 at 9:51 AM, Sven Meier s...@meiers.net 
wrote:


   Make a copy of AbstractAjaxTimerBehavior and let it be 
stoppable from



onTimer():

diff --git a/wicket-core/src/main/java/
**org/apache/wicket/ajax/
AbstractAjaxTimerBehavior.java
b/wicket-core/src/main/java/**org/apache/wicket/ajax/**
AbstractAjaxTimerBehavior.java
index 3071875..b982a39 100644
--- a/wicket-core/src/main/java/**org/apache/wicket/ajax/**
AbstractAjaxTimerBehavior.java
+++ b/wicket-core/src/main/java/**org/apache/wicket/ajax/**


AbstractAjaxTimerBehavior.java
@@ -131,8 +131,11 @@
{
onTimer(target);

- target.getHeaderResponse().**render(
- OnLoadHeaderItem.forScript(**getJsTimeoutCall(**
updateInterval)));

+if (!isStopped())

   But this code is already in : if (!isStopped() 


isEnabled(getComponent()))
How the second if (!isStopped()) fixes the issue ?


   +{


+ target.getHeaderResponse().**render(
+ OnLoadHeaderItem.forScript(**getJsTimeoutCall(**
updateInterval)));


+}
}
}

You could create a jira issue too.

  Additionally there are two global Ajax listeners at the 
bottom

Re: Ajax based panel replacement

2012-11-24 Thread Oliver Zemann
The problem is that this leads to a Page not found error. The problem is 
that the Panel which should be replaced is still looked up in the 
findPage() method. But findPage() returns null on that component, so 
this error is thrown.


Am 24.11.2012 21:48, schrieb Sven Meier:

What is the problem?

Sven

On 11/24/2012 08:22 PM, Oliver Zemann wrote:

Hi,

i created a small wicket application to show my problem:
https://github.com/olze/WicketPanelReplace

The first panel gets displayed, after a few seconds it should be 
replaced by the second panel. Is there any way to achieve this 
behavior with that kind of architecture?


If not, how should a ajax based panel wizard work? Any recommendations?

Thanks in advance.

Oli

-
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



Re: Ajax based panel replacement

2012-11-24 Thread Oliver Zemann
Unfortunately this is not a solution as i have about 30 different 
panels. And i guess at least 10 of them should later use JS. With the 
approach you suggested i would have to check which panel should be 
displayed and load that (switch/case with 10 different panels). I guess 
that would also lead in heavy mixing the panels with the HomePage 
(BasePage) (destroying reusability).


There is also no way for me to create a flow based dialogue as this is 
done in the backend controller which only tells me which panel to load.


So there is no other way to go?

Am 24.11.2012 22:57, schrieb Sven Meier:
After the timer has fired, AbstractAjaxTimerBehavior automatically 
registers another timeout for the form inside PanelOne.
But at that point PanelOne is no longer in the component tree, it's 
replaced by PanelTwo already.


I'd recommend adding the behavor to the container instead:

final WebMarkupContainer wmc = new 
WebMarkupContainer(container);

wmc.add(new AbstractAjaxTimerBehavior(Duration.seconds(5)) {
@Override
protected void onTimer(AjaxRequestTarget target) {
PanelTwo two = new PanelTwo(panel);
wmc.addOrReplace(two);
target.add(wmc);

stop(target);
}
});
add(wmc);

wmc.add(new PanelOne(panel));

This way you won't have to pass 'wmc' to PanelOne any longer.

Sven

On 11/24/2012 10:04 PM, Oliver Zemann wrote:
The problem is that this leads to a Page not found error. The problem 
is that the Panel which should be replaced is still looked up in the 
findPage() method. But findPage() returns null on that component, so 
this error is thrown.


Am 24.11.2012 21:48, schrieb Sven Meier:

What is the problem?

Sven

On 11/24/2012 08:22 PM, Oliver Zemann wrote:

Hi,

i created a small wicket application to show my problem:
https://github.com/olze/WicketPanelReplace

The first panel gets displayed, after a few seconds it should be 
replaced by the second panel. Is there any way to achieve this 
behavior with that kind of architecture?


If not, how should a ajax based panel wizard work? Any 
recommendations?


Thanks in advance.

Oli

-
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