You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by "Ford, Jennifer M." <JE...@SOUTHERNCO.COM> on 2007/11/15 18:02:49 UTC
Redirects and ActionURL
I just uncovered a problem with one of our custom portlets, and I was
wondering if anyone could tell me if this is the intended behavior or if
it is a bug.
When the user's password expires, they are thrown to the Change Password
Portlet, which we rewrote to add some additional functionality. The
actionURL provided by the response object at that point is the actionURL
for the original page, and not the my-account page that the user is
currently on. The result of this is that when they press the submit
button, they're not actually taken to the processAction method, so they
can't change their password.
Of course, if the user manually goes to the ChangePassword portlet by
clicking the 'Change Password' link in the login portlet, the actionURL
is correct.
Is this something to be expected, that if a redirect happens that the
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
Re: Redirects and ActionURL
Posted by Dennis Dam <d....@hippo.nl>.
I agree that the feature of redirecting to the original page would be a
nice thing to have. I just tested whether it already works like this (in
a full default deploy of Jetspeed 2.1.3), which it didn't! I think the
reason for that is that the ChangedPortlet is configured in portlet.xml
with an expiration-cache value of -1, which means the portlet output
will be cached *forever*. This means the actionURL will always be the
one created during the first time the portlet was rendered. If you set
expiration-cache = 0 (i.e. disable cache), a new action url will be
created every time, resulting in reloading the original page correctly.
But ... the url still contains the action url, which is kind of ugly.
Dennis
Ate Douma wrote:
> Hmm, I'm not so sure this isn't a bug.
>
> If the generated ActionURL does point to the original page this could
> lead to errors/unexpected behavior indeed.
> I've to test this myself but I can see how this could be going wrong.
> My expectancy would be that when a serverside "forward" is done to a
> different page than requested, the PortletURL generated for portlets
> on that page should point back to the forwarded psml, or at least have
> some reference to the actual rendered psml.
>
> The main "feature" at play here is, that once a user did update its
> password, the original target url would still be the target url.
> So after the update the user would actually be send back to the url as
> originally requested.
> That by itself is a nice feature I'd definitely want (and need) to
> maintain, but it shouldn't break the proper PortletURL interactions.
>
> Jennifer, if you can please create a JIRA issue for this with the
> smallest set of interactions how to reproduce this case?
> I'll pick this up then and see if/how we can solve this one (if indeed
> a bug).
>
> Regards,
>
> Ate
>
> Dennis Dam wrote:
>> 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. 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
>>> wondering if anyone could tell me if this is the intended behavior
>>> or if
>>> it is a bug. When the user's password expires, they are thrown to
>>> the Change Password
>>> Portlet, which we rewrote to add some additional functionality. The
>>> actionURL provided by the response object at that point is the
>>> actionURL
>>> for the original page, and not the my-account page that the user is
>>> currently on. The result of this is that when they press the submit
>>> button, they're not actually taken to the processAction method, so they
>>> can't change their password.
>>>
>>> Of course, if the user manually goes to the ChangePassword portlet by
>>> clicking the 'Change Password' link in the login portlet, the actionURL
>>> is correct. Is this something to be expected, that if a redirect
>>> happens that the
>>> 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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: Redirects and ActionURL
Posted by "Ford, Jennifer M." <JE...@SOUTHERNCO.COM>.
Thanks for responding to me on this! I will create a JIRA to reproduce
the issue. I had a feeling this would all come down to wanting to be
able to return to the original page. It seems like it would violate
the boundary of what a portlet instance would need to know about itself,
but based on your response I'm assuming there's not a method to call on
the portlet to find out on which page it is currently rendered. That
in itself would be very helpful in this situation.
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
Sent: Monday, November 19, 2007 8:56 AM
To: Jetspeed Users List
Subject: Re: Redirects and ActionURL
Hmm, I'm not so sure this isn't a bug.
If the generated ActionURL does point to the original page this could
lead to errors/unexpected behavior indeed.
I've to test this myself but I can see how this could be going wrong.
My expectancy would be that when a serverside "forward" is done to a
different page than requested, the PortletURL generated for portlets on
that page should point back to the forwarded psml, or at least have some
reference to the actual rendered psml.
The main "feature" at play here is, that once a user did update its
password, the original target url would still be the target url.
So after the update the user would actually be send back to the url as
originally requested.
That by itself is a nice feature I'd definitely want (and need) to
maintain, but it shouldn't break the proper PortletURL interactions.
Jennifer, if you can please create a JIRA issue for this with the
smallest set of interactions how to reproduce this case?
I'll pick this up then and see if/how we can solve this one (if indeed a
bug).
Regards,
Ate
Dennis Dam wrote:
> 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.
> 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
>> wondering if anyone could tell me if this is the intended behavior or
>> if it is a bug.
>> When the user's password expires, they are thrown to the Change
>> Password Portlet, which we rewrote to add some additional
>> functionality. The actionURL provided by the response object at that
>> point is the actionURL for the original page, and not the my-account
>> page that the user is currently on. The result of this is that when
>> they press the submit button, they're not actually taken to the
>> processAction method, so they can't change their password.
>>
>> Of course, if the user manually goes to the ChangePassword portlet by
>> clicking the 'Change Password' link in the login portlet, the
>> actionURL is correct.
>> Is this something to be expected, that if a redirect happens that the
>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Redirects and ActionURL
Posted by Ate Douma <at...@douma.nu>.
Hmm, I'm not so sure this isn't a bug.
If the generated ActionURL does point to the original page this could lead to errors/unexpected behavior indeed.
I've to test this myself but I can see how this could be going wrong.
My expectancy would be that when a serverside "forward" is done to a different page than requested, the PortletURL generated for portlets on that page should
point back to the forwarded psml, or at least have some reference to the actual rendered psml.
The main "feature" at play here is, that once a user did update its password, the original target url would still be the target url.
So after the update the user would actually be send back to the url as originally requested.
That by itself is a nice feature I'd definitely want (and need) to maintain, but it shouldn't break the proper PortletURL interactions.
Jennifer, if you can please create a JIRA issue for this with the smallest set of interactions how to reproduce this case?
I'll pick this up then and see if/how we can solve this one (if indeed a bug).
Regards,
Ate
Dennis Dam wrote:
> 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.
> 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
>> wondering if anyone could tell me if this is the intended behavior or if
>> it is a bug.
>> When the user's password expires, they are thrown to the Change Password
>> Portlet, which we rewrote to add some additional functionality. The
>> actionURL provided by the response object at that point is the actionURL
>> for the original page, and not the my-account page that the user is
>> currently on. The result of this is that when they press the submit
>> button, they're not actually taken to the processAction method, so they
>> can't change their password.
>>
>> Of course, if the user manually goes to the ChangePassword portlet by
>> clicking the 'Change Password' link in the login portlet, the actionURL
>> is correct.
>> Is this something to be expected, that if a redirect happens that the
>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
RE: Redirects and ActionURL
Posted by Dennis Dam <d....@hippo.nl>.
Sorry Jennifer, I meant processAction.
________________________________
Van: Ford, Jennifer M. [mailto:JENNFORD@SOUTHERNCO.COM]
Verzonden: ma 19-11-2007 18:19
Aan: Jetspeed Users List
Onderwerp: RE: Redirects and ActionURL
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]
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.
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
> wondering if anyone could tell me if this is the intended behavior or
> if it is a bug.
>
> When the user's password expires, they are thrown to the Change
> Password Portlet, which we rewrote to add some additional
> functionality. The actionURL provided by the response object at that
> point is the actionURL for the original page, and not the my-account
> page that the user is currently on. The result of this is that when
> they press the submit button, they're not actually taken to the
> processAction method, so they can't change their password.
>
> Of course, if the user manually goes to the ChangePassword portlet by
> clicking the 'Change Password' link in the login portlet, the
> actionURL is correct.
>
> Is this something to be expected, that if a redirect happens that the
> 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
>
>
---------------------------------------------------------------------
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
RE: Redirects and ActionURL
Posted by "Ford, Jennifer M." <JE...@SOUTHERNCO.COM>.
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]
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.
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
> wondering if anyone could tell me if this is the intended behavior or
> if it is a bug.
>
> When the user's password expires, they are thrown to the Change
> Password Portlet, which we rewrote to add some additional
> functionality. The actionURL provided by the response object at that
> point is the actionURL for the original page, and not the my-account
> page that the user is currently on. The result of this is that when
> they press the submit button, they're not actually taken to the
> processAction method, so they can't change their password.
>
> Of course, if the user manually goes to the ChangePassword portlet by
> clicking the 'Change Password' link in the login portlet, the
> actionURL is correct.
>
> Is this something to be expected, that if a redirect happens that the
> 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
>
>
---------------------------------------------------------------------
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
Re: Redirects and ActionURL
Posted by Dennis Dam <d....@hippo.nl>.
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.
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
> wondering if anyone could tell me if this is the intended behavior or if
> it is a bug.
>
> When the user's password expires, they are thrown to the Change Password
> Portlet, which we rewrote to add some additional functionality. The
> actionURL provided by the response object at that point is the actionURL
> for the original page, and not the my-account page that the user is
> currently on. The result of this is that when they press the submit
> button, they're not actually taken to the processAction method, so they
> can't change their password.
>
> Of course, if the user manually goes to the ChangePassword portlet by
> clicking the 'Change Password' link in the login portlet, the actionURL
> is correct.
>
> Is this something to be expected, that if a redirect happens that the
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org