For anyone interested in this thread, I did figure out how to secure the "Edit
Account" page.
First I edited the top.vm file and put a hard-link to the https:// version of the
EditAccount template. I used $data.User.UserName in the URL to pick up the user's
login name.
I then created my own UpdateAccount class which extended Jetspeed's module of the same
name. I just put the class in my modules\actions directory (same directory that I put
my custom LoginSSLUser class). The original UpdateAccount class has an empty
updateUser(RunData data) class which I simply put my
data.setRedirectURI("http://xxxxxxxxxxxx") into.
Now when the user clicks on "Edit account" he/she is directed to the SSL version of
the page. And, when the user clicks on "Update Account" he/she is redirected back to
the non-SSL version of the portal.
Only problem here is that the "Cancel" button will not work properly on the "Edit
Account" page because it will bypass the "updateUser()" mentioned above. Solution:
Override completely Jetspeed's UpdateAccount class and add the redirect when Cancel is
selected.
Suggestion for developers:
UpdateAccount.java
Change the following in Jetspeed's modules/actions/UpdateAccount.java
if ( cancelBtn.equalsIgnoreCase( "Cancel" ) )
{
doCancel(data); // NEW instead of just return
}
protected void doCancel(RunData data) // NEW METHOD
{
// Allows user customization
}
The above will allow users to extend UpdateAccount properly and handle both Cancel and
Update.
Michael Dalton
[EMAIL PROTECTED]
Internet Business Manager
Computing Systems Services Branch
Information Technology Directorate
IT-D3-A / CIF 394B
Kennedy Space Center, FL 32899
(W) 321-861-2207 (F) 321-867-7133
-----Original Message-----
From: Dalton-1, Michael [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 10:45 AM
To: 'Jetspeed Users List'
Subject: RE: Using SSL (e.g. https:) with Jetspeed and IE annoyances
No, you didn't miss something. Looks like I have to make the "Edit Account"
page secure to protect any changing of passwords, etc, then switch back.
The idea was to protect a user's password only. Once logged on, that
password is no longer required.
I do understand that someone could snoop the session id though.
One of the primary reasons I am going along this path is due to performance
concerns. Non-SSL performance is much better then SSL.
Thanks for the comment.
Michael Dalton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]