continueToOriginalDestination seems to be incorrectly retaining destination across multiple logins

2012-02-08 Thread Evan Sable
Hi,

 

I'm using wicket 1.5-SNAPSHOT along with Shiro for
authentication/authorization security, and when an unauthorized user tries
to go to a page, Shiro calls redirectToInterceptPage behind the scenes, and
during the login process, after a successful login, there is code that says:

if (!continueToOriginalDestination()) {

   setResponsePage(getApplication().getHomePage());

}

 

It is working in the sense that if a user gets redirected to login, they are
taken to the correct destination afterwards, and if a user just clicks the
login link in a new browser they are redirected to the homepage after login.

 

BUT, the problem is, if an initial user tries to go to a protected page,
gets redirected to the login, logs in, and then logs out, and then, without
closing the browser, clicks the login link and logs in with the same user
again or even another user, it still redirects to the prior original
destination, which should no longer take effect.  I would think that this
should be forgotten upon logging out, which replaces the wicket session
with:

Session session = Session.get();

session.replaceSession();

 

I think I must be misunderstanding how continueToOriginalDestination is
working - I thought it was placing the original destination url into the
users session, which is why I figured that after the login which redirects,
followed by the logout which replaces the session, it would be gone.

 

Can someone please explain what I'm thinking about wrongly here and why the
destination is being retained across multiple logins.  Also, how can I avoid
this so that the original destination is only used the first time?Btw,
just to be clear, if I logout and then click to a new protected url, the
original destination value is properly replaced with the new protected
destination which redirects back to the intercept page.  The problem is only
if I click directly to the login page without a new intercept, but after
having previously utilized the continueToOriginalDestination in the prior
login.

Thanks very much for any help!

-Evan



RE: continueToOriginalDestination seems to be incorrectly retaining destination across multiple logins

2012-02-15 Thread Evan Sable
Thanks for your response Martin, and sorry for my delayed reply!

I added the breakpoint (it's line 210 in my 1.5-SNAPSHOT).  I also put one at 
line 197, at the start of the mapRequest method, to see if it was getting into 
the method and finding a null value for the data variable.  But neither 
breakpoint gets reached so the method is not being called.  Does this mean that 
something is wrong with my wicket/shiro integration code, regarding the wicket 
request processing not being used correctly?  I should add that I'm using a 
library from this fifyfive-wicket project (see 
https://github.com/55minutes/fiftyfive-wicket#readme) that pretty much sets up 
the wicket/shiro integration for me.  Does it sound like the problem is most 
likely coming from there, or might something else be going on?  

Thanks again,
-Evan

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org] 
Sent: Thursday, February 09, 2012 3:12 AM
To: users@wicket.apache.org
Subject: Re: continueToOriginalDestination seems to be incorrectly retaining 
destination across multiple logins

Hi,

The intercept data should be cleaned at
org.apache.wicket.RestartResponseAtInterceptPageException, line 211 - 
InterceptData.clear(); Put a breakpoint there and see what happens.

On Wed, Feb 8, 2012 at 7:55 PM, Evan Sable e...@novelution.com wrote:
 Hi,



 I'm using wicket 1.5-SNAPSHOT along with Shiro for 
 authentication/authorization security, and when an unauthorized user 
 tries to go to a page, Shiro calls redirectToInterceptPage behind the 
 scenes, and during the login process, after a successful login, there is code 
 that says:

 if (!continueToOriginalDestination()) {

   setResponsePage(getApplication().getHomePage());

 }



 It is working in the sense that if a user gets redirected to login, 
 they are taken to the correct destination afterwards, and if a user 
 just clicks the login link in a new browser they are redirected to the 
 homepage after login.



 BUT, the problem is, if an initial user tries to go to a protected 
 page, gets redirected to the login, logs in, and then logs out, and 
 then, without closing the browser, clicks the login link and logs in 
 with the same user again or even another user, it still redirects to the 
 prior original
 destination, which should no longer take effect.  I would think that 
 this should be forgotten upon logging out, which replaces the wicket 
 session
 with:

 Session session = Session.get();

 session.replaceSession();



 I think I must be misunderstanding how continueToOriginalDestination 
 is working - I thought it was placing the original destination url 
 into the users session, which is why I figured that after the login 
 which redirects, followed by the logout which replaces the session, it would 
 be gone.



 Can someone please explain what I'm thinking about wrongly here and 
 why the destination is being retained across multiple logins.  Also, 
 how can I avoid this so that the original destination is only used the 
 first time?Btw, just to be clear, if I logout and then click to a 
 new protected url, the original destination value is properly 
 replaced with the new protected destination which redirects back to 
 the intercept page.  The problem is only if I click directly to the 
 login page without a new intercept, but after having previously 
 utilized the continueToOriginalDestination in the prior login.

 Thanks very much for any help!

 -Evan




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



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



RE: Wicket jQuery Validator integration

2012-02-29 Thread Evan Sable
Hi Zac, this sounds great - I would be very appreciative if you make this
code public, and I imagine it would be useful for many.  I was just about to
take a look at the wicketstuff-client-and-server-validation project which
seems to be a similar idea, but it would be great to check out what you have
done using wiquery.  Have you had a chance to post this somewhere?
Thanks,
-Evan

-Original Message-
From: Zachary Bedell [mailto:zacl...@thebedells.org] 
Sent: Wednesday, February 15, 2012 10:52 AM
To: users@wicket.apache.org
Subject: Wicket jQuery Validator integration

Good morning,

Reading a recent thread about accessing jQuery Validation from Wicket
reminded me that I've developed some code that might be of use.  I'm not
sure if this is something anyone else would be interested in or if it's
something that might eventually be integrated into Wicket core or if it
would be more appropriate for one of the existing jQuery/Wicket integration
libraries.  I wanted to describe what I've cooked up so far.  If this is
anything that would be useful, I'd be willing to clean the code up a bit to
extract a few bits that are specific to our environment and post the code
somewhere.

My intent was to get client-side validation using Wicket's existing
validation classes without requiring AJAX calls to make them work and
preferably without requiring Page's to include lots of unsightly JavaScript.
Also, not duplicating validation logic on the client  server tiers was
desirable.  The code was originally developed for a site that was expected
to receive a high amount of traffic in a short period of time, and avoiding
unnecessary server calls was a priority.  

I created a subclass of Form (ClientSideValidatingForm) which examines each
FormComponent (and sub-Form) added to it and extracts information about the
standard Wicket validations.  It generates JavaScript which uses jQuery's
Validator library to apply client-side checks equivalent to the Wicket
server side checks.  The nice thing about this is that you get client-side
validation for free just by adding the normal Wicket validations plus you
still get all your validations backed up in the server side in case
JavaScript is unavailable or disabled.

The implementation of the class does lack a bit in terms of elegance
unfortunately.  As the Wicket validation interface doesn't currently know
anything about JavaScript, it was necessary to run a chain of instanceof
checks against all the known Wicket validations and emit JavaScript to
mirror their logic.  I also created an extension of the Wicket IValidator
interface which can provide JavaScript functions to perform validation
equivalent to the server-side Java code.  The extraction code in
ClientSideValidatingForm preferentially checks for this interface and uses
provided JavaScript if available.  Otherwise, it's a bunch of instanceof's
to check for known validations or log an error if an unknown instance of
IValidator is found.

Long term, it would be helpful if the stock Wicket IValidator interface
could include a method to get JavaScript validations for all of the stock
validations.

The code is pretty tightly bound to jQuery Validator at this point, but it's
likely the methodology could be abstracted to other validation frameworks.
It's also built using WiQuery, though that's mostly as a convenience to get
the same version of jQuery that we use elsewhere.  The same could easily be
implemented without WiQuery provided a version of jQuery was contributed to
the response via some other mechanism.

Is this something anyone would be interested in?  

Best regards,
Zac Bedell

(Apologies if this is a dupe. I had some email client config issues this
morning...)




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



RE: AjaxFormComponentUpdatingBehavior after validation problem

2012-03-18 Thread Evan Sable
Hello,

I think the problem is just that you're calling setValues on your
genericModelObject, which is set as the compoundpropertymodel for your
form, but you're not adding the form back to the ajax response - with the
AjaxRequestTarget, you're only adding the component dropDownId to get
re-rendered into the page, not the form with the updated model.  So, the
change made directly on the dropdown which is added to the ajaxRequestTarget
(calling setEnabled) is taking effect, but it's not finding the updated
model.  It should work if you add:
target.addComponent(get(formId));

Hope that helps,
-Evan

-Original Message-
From: Gytis [mailto:lietuvis...@mail.ru] 
Sent: Friday, March 16, 2012 5:32 AM
To: users@wicket.apache.org
Subject: AjaxFormComponentUpdatingBehavior after validation problem

Hello, I have such a problem with AjaxFormComponentUpdatingBehavior. 
I have some DropDownChoice and a CheckBox on a Form. I need to make a change
to DropDown, when I click on CheckBox. But as I try to submit a Form, got
some error, and then click CheckBox DropDown doesn`t change. The code looks
like this: 

   DropDownChoiceSomeEnum dropDownz = new
DropDownChoiceSomeEnum(dropDownId,
Arrays.asList(SomeEnum.values()), new
EnumChoiceRendererSomeEnum(this));
   getGenericModelObject().setValues(SomeEnum.FIRSTVALUE);
   CheckBox boxz = new CheckBox(BoxId);
   boxz.add(new AjaxFormComponentUpdatingBehavior(onchange)
{
@Override
protected void onUpdate(AjaxRequestTarget target) {
if (boxz.getModelObject())
{

getGenericModelObject().setValues(SomeEnum.SECONDVALUE);
get(dropDownId).setEnabled(false);

target.addComponent(get(dropDownId));
}
else
{
get(dropDownId).setEnabled(true);

target.addComponent(get(dropDownId));
}
}
@Override
protected void onError(AjaxRequestTarget target,
RuntimeException e) {
if (boxz.getModelObject())
{

getGenericModelObject().setValues(SomeEnum.SECONDVALUE);
get(dropDownId).setEnabled(false);

target.addComponent(get(dropDownId));
}
else
{
get(dropDownId).setEnabled(true);

target.addComponent(get(dropDownId));
}
super.onError(target, e);
}
});
 Form form = new Form(formId, getGenericModel());
 form.add(dropDownz);
 form.add(boxz);

So as I said, after form validation, if errors occur, it won`t change
dropdown to SECONDVALUE, but sets it as setEnabled(false), why this happens?

--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/AjaxFormComponentUpdatingBehavior
-after-validation-problem-tp4477705p4477705.html
Sent from the Users forum 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



how to modify internal JavascriptResourceReference packaged with component

2013-02-13 Thread Evan Sable
Hi,

I'm working on a project that's on wicket 1.4.  It's using
the MultiFileUploadField class.  I see in the code for that class that in
renderHead, it calls:
response.renderJavascriptReference(JS);
and earlier it defines:
private static final ResourceReference JS = new JavascriptResourceReference(
MultiFileUploadField.class, MultiFileUploadField.js);

But, I'd like to make a minor modification to the actual javascript in
MultiFileUploadField.js.  Specifically, I want to modify that code to
remove the c:/fakepath prefix that appears in the box with the list of
selected files below the field (in chrome and safari - not a problem in
firefox and ie).  If I could just over-ride the javascript contents of that
file, it would be an easy fix.  But, more generally, I'd like to know not
just for this specific issue, is there a wicket way to override the
packaged javascript resource that comes with a component?  Perhaps is there
a simple way to extend the MultiFileUploadField class with my own class,
and somehow keep the rest of the code as is, but specify an alternate
resource?  It's private in that class, so I don't see how I'd do this, but
maybe I'm missing something obvious.  Or maybe is there some way to keep
using the same class but to tell the application that I want to replace the
corresponding javascript file with my own?  Or is there some other approach
I should be taking when this type of issue comes up?

Thanks very much for any advice,
-Evan