I was right, the root reason for different behavior depending on if the site is hit first by http or https is the presence/absence of the security token. This is definitely a bug.
In the documentation by Richard Li at doc/security-notes.html he specifically says that a secure token should never be issued unless a user has already authenticated himself over https. However, if you hit the site first with https, then sec_session_setup generates a secure token regardless of whether you are logged in or not. Oops.
So I think that can be fixed with a one-line patch to sec_session_setup that does not issue the token unless the user is logged in.
Now, there are two scenarios that don't appear to be supported by the toolkit's security model:
- Visiting parts of a site https, but not logged in. (parts that shouldn't require login, that is).
- A true permanent login if https is in use.
1. is disallowed by the code in Li's document that he says you can remove if you want a weaker security model. That code sends you to /register if you hit the site anywhere with https and you are not logged in. I guess the theory is "why would you want to talk to my site with https if you are not logged in?"
2. is disallowed because the security model assumes you *could* login over http or https. The tk makes you re-login if you switch from http to https (even if your target page does not require login).
So, in our case at least, we only allow logins over https. Thus if the user has a valid ad_user_login_secure cookie, we can re-issue his secure token if it is not present.
This appears to fix all of our issues.
I've generated a patch against 4.5 that fixes this and uploaded it to SDM. It's attached to the original bug report # 1549 I'm pretty sure the patch will be transparent to sites that allow unencrypted login over http, and will still enforce the requirement that a login via http should be re-requested should the user switch to https.
Allowing access to parts of a site via https that do not require login still requires that the code that Richard Li documents in /doc/security-notes.html be removed from the sec_handler proc.
Or, again in our case, we only cared about that because our images were broken on our register page. That was easy to fix (and Richard actually documented that) by changing ad_login_page to say that the /graphics directory is part of the "login" page.
Whew. What a mouthful.
Anyone out there who knows more about the security model than I do or indeed more about achieving good security with web sites, feel free to speak up if I have broken things terribly here.