Re: @RequireHttps - forms misbehaving

2010-03-22 Thread gilberthuph

I'm having the same problem and I can reproduce this in a quickstart, I just
want to check before creating a jira:

- In my quickstart I'm calling setRedirect(true) within the form submit
button's onSubmit(), is this the correct place to force a redirect?
- SignInPage has the @RequireHttps annotation, *should* the code below
result in immediate switch to https or am I missing something?

Button submitButton = new Button(submit) {
   @Override
   public void onSubmit() {
   setRedirect(true);
   setResponsePage(new SignInPage());
   }
};
-- 
View this message in context: 
http://old.nabble.com/%40RequireHttps---forms-misbehaving-tp26845496p27984631.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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



Re: @RequireHttps - forms misbehaving

2009-12-22 Thread VGJ
My redirect method isn't overriding anything, it's just there to provide a
shortcut to an external redirect, should I need it.  Could it still be doing
some damage, somehow?

I was using bookmarkable pages just before switching to Hybrids, at the same
time I started using @RequireHttps, so they did work just fine.

On Mon, Dec 21, 2009 at 4:51 PM, Jason Lea ja...@kumachan.net.nz wrote:

 yay!

 But it is odd if setRedirect(true) didn't work when using a page instance.
  I wonder if the there is an issue with HybridUrlCodingStrategy and
 RequireHttps... can you mount the page you redirect to using a simple
 bookmarkable page and see if it works?

 I also noticed you have a method on your BasePage class called
 redirect(url) that disables wicket redirect... does that get called when you
 use setRedirect(true)?



 VGJ wrote:

 Jason...excellent!  setResponsePage(UserAccount.class) did the trick!
 Thanks!  Using setRedirect(true) didn't have any effect however.  I had to
 redirect to the page class rather than a new instance of it.

 This works for me right now...but what happens when I'd like to pass
 parameters into the constructor of the page I'm redirecting to?

 -v


 --
 Jason Lea



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




Re: @RequireHttps - forms misbehaving

2009-12-21 Thread bht
VGJ,
You might have discovered a limitation of the system or a bug. As I
wrote, I would recommend you make a testcase with all distracting
detail removed and submit it as a jira issue, then post a link to the
the issue here.

I understand your frustration, but I think the above would be the best
investment of your own efforts.

Regards,

Bernard.

On Mon, 21 Dec 2009 11:13:49 -0700, you wrote:

Well, I'm still unable to spot anything strange.  No matter what page I
annotate, it doesn't switch to https until the form is submitted.  It then
goes to https (as if it's redirecting to itself?) and triggers the
validation on the page, even if the correct fields are filled in.  No matter
what page I annotate on this site, it happens the same way.

Here's an example from this app:

The login or create a new account page:

@RequireHttps
public class UserAccount extends BasePage
{
public UserAccount()
{
//get user from session
User user = ((UserSession)getSession()).getUser();

//pass go, collect $200
if (user != null)
throw new RestartResponseException(new ContactInfo());

add(new FeedbackPanel(feedbackPanel));

//get cart in session
ShoppingCartLocal cart = ((UserSession)getSession()).getCart();

//entities
Order order = cart.getOrder();
Customer customer = order.getCustomer();
String email = (order != null  customer != null) ? customer.getEmail()
: ;

//form model (entity)
if (user == null) user = new User();

//if email exists, pre-populate form
if (email != null  !email.equals())
user.setUsername(email);

final Form returnUserForm = new Form(retUserAccountForm, new
CompoundPropertyModel(user));
final Form newUserForm = new Form(newUserAccountForm, new
CompoundPropertyModel(user));

//add form components
returnUserForm.add(new TextField(username)
.setRequired(true)
.add(EmailAddressPatternValidator.getInstance()));
returnUserForm.add(new PasswordTextField(password));

returnUserForm.add(new Button(userAcctButton)
{
  public void onSubmit()
  {
ShoppingCartLocal  cart = null;

try
{
  //save form values, redirect
  User user = (User)returnUserForm.getModelObject();

  //get cart from session
  cart = ((UserSession)getSession()).getCart();

  //create order in session
  cart = CartProxy.authUserAccount(cart, user);

  //set cart back to session  log user in
  ((UserSession)getSession()).setCart(cart);
  ((UserSession)getSession()).setUser(
  cart.getOrder().getCustomer().getUser());

  //redirect
  setResponsePage(new ContactInfo());
}
catch (Exception exp)
{
  info(exp.getMessage());
  LogProxy.saveEntry(exp);
}
  }
});

returnUserForm.add(new Link(forgotPasswordLink)
{
  public void onClick()
  {
setResponsePage(new ForgotPassword());
  }
});


//add form components
newUserForm.add(new TextField(username)
.setRequired(true)
.add(EmailAddressPatternValidator.getInstance()));

newUserForm.add(new Button(userAcctButton)
{
  public void onSubmit()
  {
ShoppingCartLocal  cart = null;

try
{
  //save form values, redirect
  User user = (User)newUserForm.getModelObject();

  //get cart from session
  cart = ((UserSession)getSession()).getCart();

  //create order in session
  cart = CartProxy.createUserAccount(cart, user);

  //set cart back to session  log user in
  ((UserSession)getSession()).setCart(cart);
  ((UserSession)getSession()).setUser(
  cart.getOrder().getCustomer().getUser());

  //redirect
  setResponsePage(new ContactInfo());
}
catch (Exception exp)
{
  info(exp.getMessage());
  LogProxy.saveEntry(exp);
}
  }
});

//add forms
add(returnUserForm);
add(newUserForm);
}
}

...the BasePage class:

public abstract class BasePage extends WebPage
{
  private String pageTitle = My page title!;

  public BasePage()
  {
//add page title
add(new Label(title, new PropertyModel(this, pageTitle)));

//add page components
add(new TrailPanel(trailPanel,
  TrailFactory.getUserPageTrail(this.getPageClass().getSimpleName(;
add(new HeaderPanel(headerPanel));
add(new FooterPanel(footerPanel));
  }

  public final String getPageTitle()
  {
return pageTitle;
  }

  public final void setPageTitle(String title)
  {
this.pageTitle = title;
  }

  protected void redirect(String url)
  {
//disable wicket redirecting
getRequestCycle().setRedirect(false);

//make sure no output for the current cycle is sent

Re: @RequireHttps - forms misbehaving

2009-12-21 Thread VGJ
I see, I guess I misunderstood you.  I wasn't able to reproduce it in a
separate test application, however.  It has to be encountering something in
this particular application that is causing a problem.  I just can't figure
out what that might be, exactly.

I would submit the small test case I made but it works just fine.  I can't
submit the application with the issue I've described, it's company code.

-v

On Mon, Dec 21, 2009 at 12:45 PM, b...@actrix.gen.nz wrote:

 VGJ,
 You might have discovered a limitation of the system or a bug. As I
 wrote, I would recommend you make a testcase with all distracting
 detail removed and submit it as a jira issue, then post a link to the
 the issue here.

 I understand your frustration, but I think the above would be the best
 investment of your own efforts.

 Regards,

 Bernard.

 On Mon, 21 Dec 2009 11:13:49 -0700, you wrote:

 Well, I'm still unable to spot anything strange.  No matter what page I
 annotate, it doesn't switch to https until the form is submitted.  It then
 goes to https (as if it's redirecting to itself?) and triggers the
 validation on the page, even if the correct fields are filled in.  No
 matter
 what page I annotate on this site, it happens the same way.
 
 Here's an example from this app:
 
 The login or create a new account page:
 
 @RequireHttps
 public class UserAccount extends BasePage
 {
 public UserAccount()
 {
 //get user from session
 User user = ((UserSession)getSession()).getUser();
 
 //pass go, collect $200
 if (user != null)
 throw new RestartResponseException(new ContactInfo());
 
 add(new FeedbackPanel(feedbackPanel));
 
 //get cart in session
 ShoppingCartLocal cart = ((UserSession)getSession()).getCart();
 
 //entities
 Order order = cart.getOrder();
 Customer customer = order.getCustomer();
 String email = (order != null  customer != null) ?
 customer.getEmail()
 : ;
 
 //form model (entity)
 if (user == null) user = new User();
 
 //if email exists, pre-populate form
 if (email != null  !email.equals())
 user.setUsername(email);
 
 final Form returnUserForm = new Form(retUserAccountForm, new
 CompoundPropertyModel(user));
 final Form newUserForm = new Form(newUserAccountForm, new
 CompoundPropertyModel(user));
 
 //add form components
 returnUserForm.add(new TextField(username)
 .setRequired(true)
 .add(EmailAddressPatternValidator.getInstance()));
 returnUserForm.add(new PasswordTextField(password));
 
 returnUserForm.add(new Button(userAcctButton)
 {
   public void onSubmit()
   {
 ShoppingCartLocal  cart = null;
 
 try
 {
   //save form values, redirect
   User user = (User)returnUserForm.getModelObject();
 
   //get cart from session
   cart = ((UserSession)getSession()).getCart();
 
   //create order in session
   cart = CartProxy.authUserAccount(cart, user);
 
   //set cart back to session  log user in
   ((UserSession)getSession()).setCart(cart);
   ((UserSession)getSession()).setUser(
   cart.getOrder().getCustomer().getUser());
 
   //redirect
   setResponsePage(new ContactInfo());
 }
 catch (Exception exp)
 {
   info(exp.getMessage());
   LogProxy.saveEntry(exp);
 }
   }
 });
 
 returnUserForm.add(new Link(forgotPasswordLink)
 {
   public void onClick()
   {
 setResponsePage(new ForgotPassword());
   }
 });
 
 
 //add form components
 newUserForm.add(new TextField(username)
 .setRequired(true)
 .add(EmailAddressPatternValidator.getInstance()));
 
 newUserForm.add(new Button(userAcctButton)
 {
   public void onSubmit()
   {
 ShoppingCartLocal  cart = null;
 
 try
 {
   //save form values, redirect
   User user = (User)newUserForm.getModelObject();
 
   //get cart from session
   cart = ((UserSession)getSession()).getCart();
 
   //create order in session
   cart = CartProxy.createUserAccount(cart, user);
 
   //set cart back to session  log user in
   ((UserSession)getSession()).setCart(cart);
   ((UserSession)getSession()).setUser(
   cart.getOrder().getCustomer().getUser());
 
   //redirect
   setResponsePage(new ContactInfo());
 }
 catch (Exception exp)
 {
   info(exp.getMessage());
   LogProxy.saveEntry(exp);
 }
   }
 });
 
 //add forms
 add(returnUserForm);
 add(newUserForm);
 }
 }
 
 ...the BasePage class:
 
 public abstract class BasePage extends WebPage
 {
   private String pageTitle = My page title!;
 
   public BasePage()
   {
 //add page title
 add(new Label(title, new 

Re: @RequireHttps - forms misbehaving

2009-12-21 Thread VGJ
Jason...excellent!  setResponsePage(UserAccount.class) did the trick!
Thanks!  Using setRedirect(true) didn't have any effect however.  I had to
redirect to the page class rather than a new instance of it.

This works for me right now...but what happens when I'd like to pass
parameters into the constructor of the page I'm redirecting to?

-v

On Mon, Dec 21, 2009 at 1:52 PM, Jason Lea ja...@kumachan.net.nz wrote:

 Here are a couple of things to try...

 @RequireHttps checks when the request comes into wicket and issues a
 redirect if it is on the wrong protocol.

 I wonder if it is because you are using setResponsePage(new ContactInfo());
 without a redirect, so the @RequireHttps annotation is not checked but the
 page still renders.
 When you do actually submit the form on the page, wicket can then process
 the @RequireHttps annotation and redirects to the page and maybe loses the
 posted form values?

 If this was happening you would probably see url has not changed from http
 to https.

 Try adding setRedirect(true) or better yet use the
 setResponsePage(ContactInfo.class); method instead which will do a redirect
 for you.

 If the problem is still occuring, try the HttpFox plugin and look at the
 requests and redirects that occur and see if it does issue redirects to
 change to https somewhere.  The other place redirects occur is with your use
 of HybridUrlCodingStrategy... try a different strategy to see if that causes
 the problem to go away.

 If there are still problems, you could check the session id to make sure it
 is not being lost when switching from http-https  (HttpFox is good for
 seeing the cookies, and see if the jsessionid cookie changed or not)


 VGJ wrote:

 I see, I guess I misunderstood you.  I wasn't able to reproduce it in a
 separate test application, however.  It has to be encountering something
 in
 this particular application that is causing a problem.  I just can't
 figure
 out what that might be, exactly.

 I would submit the small test case I made but it works just fine.  I can't
 submit the application with the issue I've described, it's company code.

 -v



 --
 Jason Lea




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




Re: @RequireHttps - forms misbehaving

2009-12-21 Thread Jason Lea

yay!

But it is odd if setRedirect(true) didn't work when using a page 
instance.  I wonder if the there is an issue with 
HybridUrlCodingStrategy and RequireHttps... can you mount the page you 
redirect to using a simple bookmarkable page and see if it works?


I also noticed you have a method on your BasePage class called 
redirect(url) that disables wicket redirect... does that get called when 
you use setRedirect(true)?



VGJ wrote:

Jason...excellent!  setResponsePage(UserAccount.class) did the trick!
Thanks!  Using setRedirect(true) didn't have any effect however.  I had to
redirect to the page class rather than a new instance of it.

This works for me right now...but what happens when I'd like to pass
parameters into the constructor of the page I'm redirecting to?

-v
  

--
Jason Lea



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



Re: @RequireHttps - forms misbehaving

2009-12-20 Thread bht
Hi VGJ,

If, as you say you can reproduce this in your storefront app no matter
where you use it then you may want to reduce this to a testcase and
create a jira issue from it.

You are already writing that you can reproduce it and consequently it
would be only a matter of removing all distracting detail from your
storefront until further simplification is no longer possible. I can't
see how otherwise anyone could help you with your issue.

In any case, glitches like you mention should not happen whether the
problem is in the Wicket framework domain or in the application
domain. If it is in the application domain, as it would usually be the
case because Wicket is mature, then there would still be a benefit of
publishing the issue e.g. in a Wiki article so that others would not
make the same mistake.

Good luck!

Bernard

On Fri, 18 Dec 2009 14:58:15 -0700, you wrote:

I was unable to re-create it in a simple web app w/ a few pages.  However,
no matter where I use it in my storefront app, it happens.

It's very strange because it starts a page late.  I put the annotation on
the User Account page, yet it doesn't switch to https until I reach the
*following* page in the checkout process.  I just stuck it on the general
Login page that exists outside of the checkout process...and when I click
the link from the home page to go to the Login page using
setResponsePage(new Login()), it doesn't switch to https.  Instead, I enter
the user/pass and submit...THEN it goes to https, then I'm able to re-enter
and login.

Very strange behavior...I have no idea what might be causing it.

I use various Panels throughout the side, would that have any influence on
it?  For example, the link in the header to go to the Login page is inside
of a straightforward Panel.  The entire site uses markup inheritance as
well.

On Fri, Dec 18, 2009 at 9:29 AM, VGJ zambi...@gmail.com wrote:

 I'll create one and post it, if I can.

 -v


 On Fri, Dec 18, 2009 at 9:21 AM, Igor Vaynberg 
 igor.vaynb...@gmail.comwrote:

 can you recreate in a quickstart?

 -igor

 On Fri, Dec 18, 2009 at 7:56 AM, VGJ zambi...@gmail.com wrote:
  I'm now using @RequireHttps to switch to https on certain pages but it's
 not
  quite working right.
 
  In our storefront app, I'm switching to https at the point in the
 checkout
  process where you view your cart, and then proceed to a page to either
 login
  or create an account.  When I submit my username and password, the
  validation fires as if I entered nothing into the form.  Enter it a
 second
  time and it works - the validation doesn't trigger.  Everything was
 entered
  correctly the first time around...so it's as if the form is being posted
 on
  its own, when the page loads?  Every page with @RequireHttps that has a
  form, does this.
 
  What do I need to do to change to accommodate validation under
 @RequireHttps
  pages?
 
  Currently you just see a lot of forms w/ fields like this:
 
  add(new TextField(username).setRequired(true));
 
  ...with a pretty common feedback panel:
 
 div id=feedbackPanel
   span wicket:id=feedbackPanel class=warning /
 /div
 
  Thanks!
 
  -v
 

 -
 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: @RequireHttps - forms misbehaving

2009-12-18 Thread Igor Vaynberg
can you recreate in a quickstart?

-igor

On Fri, Dec 18, 2009 at 7:56 AM, VGJ zambi...@gmail.com wrote:
 I'm now using @RequireHttps to switch to https on certain pages but it's not
 quite working right.

 In our storefront app, I'm switching to https at the point in the checkout
 process where you view your cart, and then proceed to a page to either login
 or create an account.  When I submit my username and password, the
 validation fires as if I entered nothing into the form.  Enter it a second
 time and it works - the validation doesn't trigger.  Everything was entered
 correctly the first time around...so it's as if the form is being posted on
 its own, when the page loads?  Every page with @RequireHttps that has a
 form, does this.

 What do I need to do to change to accommodate validation under @RequireHttps
 pages?

 Currently you just see a lot of forms w/ fields like this:

 add(new TextField(username).setRequired(true));

 ...with a pretty common feedback panel:

            div id=feedbackPanel
              span wicket:id=feedbackPanel class=warning /
            /div

 Thanks!

 -v


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



Re: @RequireHttps - forms misbehaving

2009-12-18 Thread VGJ
I'll create one and post it, if I can.

-v

On Fri, Dec 18, 2009 at 9:21 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 can you recreate in a quickstart?

 -igor

 On Fri, Dec 18, 2009 at 7:56 AM, VGJ zambi...@gmail.com wrote:
  I'm now using @RequireHttps to switch to https on certain pages but it's
 not
  quite working right.
 
  In our storefront app, I'm switching to https at the point in the
 checkout
  process where you view your cart, and then proceed to a page to either
 login
  or create an account.  When I submit my username and password, the
  validation fires as if I entered nothing into the form.  Enter it a
 second
  time and it works - the validation doesn't trigger.  Everything was
 entered
  correctly the first time around...so it's as if the form is being posted
 on
  its own, when the page loads?  Every page with @RequireHttps that has a
  form, does this.
 
  What do I need to do to change to accommodate validation under
 @RequireHttps
  pages?
 
  Currently you just see a lot of forms w/ fields like this:
 
  add(new TextField(username).setRequired(true));
 
  ...with a pretty common feedback panel:
 
 div id=feedbackPanel
   span wicket:id=feedbackPanel class=warning /
 /div
 
  Thanks!
 
  -v
 

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




Re: @RequireHttps - forms misbehaving

2009-12-18 Thread VGJ
I was unable to re-create it in a simple web app w/ a few pages.  However,
no matter where I use it in my storefront app, it happens.

It's very strange because it starts a page late.  I put the annotation on
the User Account page, yet it doesn't switch to https until I reach the
*following* page in the checkout process.  I just stuck it on the general
Login page that exists outside of the checkout process...and when I click
the link from the home page to go to the Login page using
setResponsePage(new Login()), it doesn't switch to https.  Instead, I enter
the user/pass and submit...THEN it goes to https, then I'm able to re-enter
and login.

Very strange behavior...I have no idea what might be causing it.

I use various Panels throughout the side, would that have any influence on
it?  For example, the link in the header to go to the Login page is inside
of a straightforward Panel.  The entire site uses markup inheritance as
well.

On Fri, Dec 18, 2009 at 9:29 AM, VGJ zambi...@gmail.com wrote:

 I'll create one and post it, if I can.

 -v


 On Fri, Dec 18, 2009 at 9:21 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 can you recreate in a quickstart?

 -igor

 On Fri, Dec 18, 2009 at 7:56 AM, VGJ zambi...@gmail.com wrote:
  I'm now using @RequireHttps to switch to https on certain pages but it's
 not
  quite working right.
 
  In our storefront app, I'm switching to https at the point in the
 checkout
  process where you view your cart, and then proceed to a page to either
 login
  or create an account.  When I submit my username and password, the
  validation fires as if I entered nothing into the form.  Enter it a
 second
  time and it works - the validation doesn't trigger.  Everything was
 entered
  correctly the first time around...so it's as if the form is being posted
 on
  its own, when the page loads?  Every page with @RequireHttps that has a
  form, does this.
 
  What do I need to do to change to accommodate validation under
 @RequireHttps
  pages?
 
  Currently you just see a lot of forms w/ fields like this:
 
  add(new TextField(username).setRequired(true));
 
  ...with a pretty common feedback panel:
 
 div id=feedbackPanel
   span wicket:id=feedbackPanel class=warning /
 /div
 
  Thanks!
 
  -v
 

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