Mailing-List: contact jetspeed-user-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Users List" <jetspeed-user@portals.apache.org>
Received-SPF: pass (nike.apache.org: domain of jennford@southernco.com
 designates 146.126.51.99 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Redirects and ActionURL
Date: Mon, 19 Nov 2007 11:19:05 -0600
Message-ID: 
 <5B9FB9EE480EC34F80679BAD14344EAC012CE29B@ALXAPEX46.southernco.com>
In-Reply-To: <4741948C.2090502@hippo.nl>
Thread-Topic: Redirects and ActionURL
thread-index: AcgqszolKDsNVl82R7yKOEKkyLTDYAAG1pxg
References: 
 <5B9FB9EE480EC34F80679BAD14344EAC012CE295@ALXAPEX46.southernco.com>
 <4741948C.2090502@hippo.nl>
From: "Ford, Jennifer M." <JENNFORD@SOUTHERNCO.COM>
To: "Jetspeed Users List" <jetspeed-user@portals.apache.org>

Thanks for explaining this, Dennis.  We're using Jetspeed-2.1.2.  We
didn't extend the original or even implement a doAction at all, only a
processAction method.  (And also, I don't see a doAction method on the
GenericPortlet to override, where would that go?  Is it specific to the
standard ChangePasswordPortlet?)

I know my processAction never gets the action when the submit button is
called using the standard actionURL that is available in the doView
method.  It does get the action if I add "/my-account.psml" to the end
of that URL, but as you mentioned, when the password change is
successful, they stay on the "Update My Account" page, which isn't the
most user friendly behavior.  But it's an effective workaround for now.

As Ate suggested, I am putting in a JIRA now with steps to reproduce.

Thanks,
Jennifer


-----Original Message-----
From: Dennis Dam [mailto:d.dam@hippo.nl]=20
Sent: Monday, November 19, 2007 7:50 AM
To: Jetspeed Users List
Subject: Re: Redirects and ActionURL

Hi Jennifer,

The "redirect" to the change password portlet is not a "real" browser
redirect, that's why the encoded action URL contains your original url.=20
It works differently. The moment Jetspeed detects that a password should
be updated (see PassWordCredentialValveImpl), it overrides the default
profiling rules for the original url with the "security" rule, which
points to /my-account.psml by default (might be different in your case).

So no matter where you navigate to, this psml will always be selected
when your password needs to be updated. The action url which is created
for the changed password portlet thus contains your original url, but
that's no problem AFAICS, because the doAction() of the ChangePassword
portlet will be called. Could it be that you have extended the default
ChangePasswordPortlet, but forgot to call super.doAction() or so? What
happens if you use the original ChangePasswordPortlet instead of your
custom one? What version of Jetspeed are you using by the way ?

regards,
Dennis

Ford, Jennifer M. wrote:
> I just uncovered a problem with one of our custom portlets, and I was=20
> wondering if anyone could tell me if this is the intended behavior or=20
> if it is a bug.
>
> When the user's password expires, they are thrown to the Change=20
> Password Portlet, which we rewrote to add some additional=20
> functionality.  The actionURL provided by the response object at that=20
> point is the actionURL for the original page, and not the my-account=20
> page that the user is currently on.  The result of this is that when=20
> they press the submit button, they're not actually taken to the=20
> processAction method, so they can't change their password.
>
> Of course, if the user manually goes to the ChangePassword portlet by=20
> clicking the 'Change Password' link in the login portlet, the=20
> actionURL is correct.
>
> Is this something to be expected, that if a redirect happens that the=20
> actionURL given is not for the currently displayed page?
>
> Thanks,
> Jennifer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>  =20


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org