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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
