I too find the implementation of this particular feature confusing and struggled to get it to work as expected. I don't think this is the place for an official bug report, but to get the discussion going clearly, here is how I would describe the problem:
Preconditions:
- SSL is enabled and configured in System->Preferences
- User is not logged in and is viewing any page on the site
- "System->Preferences->General Settings->URL where SSL login page is located" is set to
https://www.yoursite.com/extras/login.php (but this should be given the default URL of XOOPS_URL."/extras/login.php")
- login.php has its $path variable properly set
Expected behavior:
1. User clicks "Secure Login" link
2. System opens new window with SSL connection
3. System displays simple login form (username, password, submit button)
4. User fills in form and clicks "Submit" (or "Login" or whatever)
5. System authenticates user
6. System refreshes main page (now that user is logged in)
7. System closes the login window opened by the system in step 2
Actual behavior (2.0.7 and current CVS):
1. User clicks "Secure Login" link
2. System opens new window with SSL connection
3. System displays simple login form
4. User enters credentials and clicks Submit
5. System authenticates user
6. System displays text asking user to either log in or cancel
7. User clicks User Login button
+ Some browsers will complain at this point that the form is being sent in a non-secure way
8. System displays Close button
9. User clicks Close button
10. System refreshes main page with user now logged in
Postcondition:
- User is logged in in original window and has access to all password protected content
Recommendations:
- drop the new window login method in leiu of an SSL login module
- pop-up blockers may make this login method impossible
- user may simply close the login window (rather than clicking the Close button)
- a module integrates better with XOOPS than an extra