Index: openacs-4/packages/acs-subsite/www/pvt/home.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-subsite/www/pvt/home.adp,v
diff -u -r1.10 -r1.11
--- openacs-4/packages/acs-subsite/www/pvt/home.adp	12 Sep 2003 13:25:19 -0000	1.10
+++ openacs-4/packages/acs-subsite/www/pvt/home.adp	15 Sep 2003 10:31:25 -0000	1.11
@@ -9,7 +9,7 @@
 
 <if @form_request_p@ true>
   <p>
-    <b>&raquo;</b> <a href="../user/password-update?return_url=@pvt_home_url@">#acs-subsite.Change_my_Password#</a>
+    <b>&raquo;</b> <a href="../user/password-update">#acs-subsite.Change_my_Password#</a>
   </p>
 
   <p>
Fisheye: Tag 1.2 refers to a dead (removed) revision in file `openacs-4/packages/acs-subsite/www/register/display-message.adp'.
Fisheye: No comparison available.  Pass `N' to diff?
Index: openacs-4/packages/acs-subsite/www/user/password-update.tcl
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-subsite/www/user/password-update.tcl,v
diff -u -r1.13 -r1.14
--- openacs-4/packages/acs-subsite/www/user/password-update.tcl	4 Sep 2003 16:35:04 -0000	1.13
+++ openacs-4/packages/acs-subsite/www/user/password-update.tcl	15 Sep 2003 10:31:25 -0000	1.14
@@ -9,6 +9,10 @@
     {old_password ""}
 }
 
+if { $user_id == 0 } {
+    ad_redirect_for_registration
+}
+
 # This is a bit confusing, but old_password is what we get passed in here,
 # whereas password_old is the form element.
 
@@ -98,16 +102,32 @@
         }
     }
 
-    # Make sure the user is logged in
-    # LARS: This looks fairly dangerous to me
-    if { [ad_conn user_id] == 0 } {
+    # If we get here, it means the user's password was successfully changed, which
+    # means the user knew this account's old password (and now also knows the new password).
+    # So all in all, we must consider this user now properly authenticated, and htus, we log him/her in.
+    # However, this doesn't verify the user's account status ...
+    # LARS: We should check to see if we can rid ourselves of this mechanism. 
+    # I think that what we need it for is the "user must change password  now" usecase,
+    # where we don't want to let people in until after they've changed password, 
+    # but then when they have, we don't want them to have to authenticate once again
+    # (besides, with external authentication, passwords may have a time lag from they're 
+    # chnaged until they're effective ...)
+    # Should we change the password management API to optionally check and return account_status?
+    # In which case we'd have to also check local account status
+
+    if { [ad_conn user_id] } {
         ad_user_login $user_id
     }
     
 } -after_submit {
     if { [empty_string_p $return_url] } {
         set return_url [ad_pvt_home]
+        set continue_label "Return to [ad_pvt_home_name]"
+    } else {
+        set continue_label "Continue"
     }
-    ad_returnredirect $return_url
-    ad_script_abort
+    set message "You have successfully chosen a new Password."
+    set continue_url $return_url
+
+    ad_return_template /packages/acs-subsite/www/register/display-message
 }