Bug 12459 – Bugzilla logs users in only on https site, and does not redirect from http to https

Logging in currently only saves the session cookie on the https:// protocol, because it is sent with the "secure" flag enabled. Bugzilla seems to be configured to redirect logged-in users from http:// to https://, but since the cookie is never visible when accessing the site via http://, the only way that redirect can happen is if someone still had a login cookie from before HTTPS was added. In effect, this means that any user who logged in since the addition of HTTPS will not be logged in when clicking on a http:// Bugzilla link. They need to either log in again, or edit the URL in their browser to point to HTTPS. A fix would be to set some cookie WITHOUT the secure flag, which would indicate the requirement to redirect to https://. I discovered this accidentally after logging out to test something.

I can't reproduce the problem. Please give a detailed set of steps. What I tried: logged out delete all cookies for puremagic.com/issues urls hit http://d.puremagic.com/issues/ was redirected to https://... was able to login just fine

Hmm, the front page seems to be redirecting just fine, but links to individual issues don't... Example: http://d.puremagic.com/issues/show_bug.cgi?id=12459 This doesn't redirect me.

It didn't redirect me either, but gave no issues when logging in from that page either. So, other than being able to view a bug via http, what's the issue here? No passwords are sent in the clear (the form submit url is https). No problems logging in.

The problem is that if you log in, then open that page again, you are not logged in. You have to log in again.

Ok.. I see what you're saying. It's a difference of expectations. You're never logged in on a plain http page. That's purposeful to avoid having any security credentials, including the cookie, passed in the clear.. ever. It doesn't prevent login, just never shows you as logged in on an https page. Not a bug.

I would consider this a problem because websites generally just don't behave this way. I don't know what's causing this behavior but I proposed a possible solution in the issue description.

Well, we'll see what the 4.x version has after the upgrade, but if you want this behavior changed, the issue tracker for bugzilla itself is the right place to lobby for this change. Personally, I believe it's correct. I'm going to close this either way since it's not an issue with this particular installation of bugzilla.

I think it's better to keep this open for as long as the issue persists, and close it when it's fixed. Even if it's not a bug, it's an annoyance that can be resolved without sacrificing security.

Reopen if and only if you can convince the bugzilla developers that the change is worth making. I believe it _is_ a security risk for the logged in cookie and it's token to be passed in the clear.

That was not what I suggested. This conversation is not headed into a constructive direction. Can we please reach a consensus before WONTFIX-ing the issue? Closed issues do not appear in most search results and get lost. Nothing is solved by closing it. If you don't want to spend time on this issue, you can unassign and unsubscribe yourself from this issue. Someone else (e.g. I) can instead look into whether the problem is reproducible on a clean Bugzilla install, whether an upgrade will fix it (or if it's fixed when this instance is upgraded), follow up to the Bugzilla developers, etc. This bug can serve to track progress towards fixing the problem. Please do not close issues unless they are fixed or can't be fixed. I don't see how doing so is useful.

It's really a pain in the ass that every time I click on a bugzilla issue and try to comment, bugzilla tells me I'm not logged in even though I am. The autotester seems to have the same issue, I have to click "Log in" multiple times per day for some reason, even though I never clear my cache or cookies. It's just one of those little things that are a consistent annoyance to a fast workflow.

This affects me too, and is quite annoying. Is it possible to just redirect all http bugzilla urls to https?

I got here by following the #d dbot link and had to prefix the URL with 'https://' in order to be able to post this comment. I think that that sums up my position on this issue.

I posted a client-side workaround here: http://wiki.dlang.org/Bugzilla#Redirect_to_HTTPS

This would be fixed by switching the require ssl setting from 'authenticated' to 'ssl'. However, doing this breaks dlang.org/bugstats.html (well, really, fetch-issue-cnt.php which that page uses) since the php install on dlang.org doesn't support https urls.

(In reply to comment #15) > This would be fixed by switching the require ssl setting from 'authenticated' > to 'ssl'. However, doing this breaks dlang.org/bugstats.html (well, really, > fetch-issue-cnt.php which that page uses) since the php install on dlang.org > doesn't support https urls. Hmm, does the puremagic server support it? I've encountered a similar problem when trying to access HTTPS resources from D code. Ultimately I wrote a small HTTP-to-HTTPS "proxy" page in PHP: <?php $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://d.puremagic.com/issues/...whatever..."); curl_exec($ch); curl_close($ch);

It's a dlang.org php configuration issue, that the site admin is aware of, rather than a d.puremagic.com issue. I don't know when it'll be fixed. I pinged the email thread with him (and a couple others) just a moment ago.

Yes, understood. My suggestion was to work around the dlang.org configuration issue by not having it access Bugzilla HTTPS resources directly, but through a HTTP proxy, so that both dlang.org wouldn't need to be able to access HTTPS, and Bugzilla can be HTTPS-only.

certainly possible, but a pretty ugly hack to a fixable situation.

Not sure how it relates to the status of the issue graphs on dlang.org, but this particular annoyance has been fixed by the Bugzilla upgrade / move. Thanks!

It was fixed by changing the config option, which has the side effect of making non-https pages no longer work. The dlang.org/bugstats page now fails because it can't make https calls. I have no idea why it's taking so long to get that fixed, but yes, this issue is resolved at the cost of the other.