Closed Bug 329638 Opened 15 years ago Closed 12 years ago
https login page switches to http on submit if ssl
_redirect = false
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7 I upgrade from 2.18.4 to Bugzilla 2.20.1 last week and now i have a problem with the new ssl behavior. We use http/https for connections from intranet and block http via firewall from internet, only https is allowed. But we have customers, who need to connect with http (didn't accept self signed certificates in proxy configuration), so this customer ip is special configured in the firewall to accept connects with http. Until the upgrade all work fine, but now i can connect the login page with https and if you submit the login data, the submit is send with http, that is blocked by the firewall. I've try parameter sslbase and ssl with several combinations but nothing works. Either it switch at submit from https to http (ssl=never) or i will be redirected to https even if i start the connection with http (ssl=always or auth). The right behavior for ssl force redirection = never should be, that i connect with http and stay at http and if i connect with https i stay at https. There was a similar bug in 2.16.x if i remember correct. Reproducible: Always Steps to Reproduce: 1.connect via https (parameters sslbase=https://bugzilla.mydomain.com/;ssl=never) 2.fill out login data and submit Actual Results: get redirected to http Expected Results: stay at https
'never' means never. Now all login forms check the 'ssl' parameter to know where to redirect. I'm not sure that's a restriction we want to relax. CCing justdave and myk to get their opinion.
if never means never, why i get redirected to http although i initial connect with https? never has to be never change the initial connection protocol!
Status of bug/issue is still unconfirmed. No further comments to the ssl behavior?
Hi I have been experiencing this issue too, while it makes sense to either login through ssl or not through ssl we have a need to be able to do both, we used to be able to do it in the older version but since updating we can no longer do this. We allow non-secure Intranet access to our bugzilla server through http://192.168.0.200 and allow ssl secure external access through https://bugzilla.ourdomain.com. We need to be able to access bugzilla from both urls, in previous versions this was not a problem and we denied non-secure external access to bugzilla using security policies on our firewall and in the webserver configuration. Is there a way in which we can easily run bugzilla from both URLS?
Yeah, I think if you access a page with SSL, you shouldn't get redirected to an http page forcibly. We shouldn't be using absolute URLs in Bugzilla, and we shouldn't force a redirect to non-SSL if you're using SSL, even if "ssl eq never".
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: https login page switch to http on submit → https login page switches to http on submit if the ssl parameter is set to "never"
Not all the places case be fixed to use relative URLs. An example where absolute URL is a must is email generator. The link from email must be absolute. In this case it is good question what type to use, http or https? I replaced most of URL to relative in my local version and it seems to work fine.
I have add both absolute URLs to the default email template to fix the problem with absolute URLs in email generator. But i didn't want to patch the files from bugzilla to remove absolute URLs, because on every update of bugzilla you need to patch again. Is the ssl redirect problem still alive in current version, i didn't try again since version 3.0?
IMHO emails should contain 'https:' if ssl=always and 'http:' otherwise. With redirection problems fixed -- authenticated users will get SSL anyway. The only reason for 'https:' is that HTTP access may be blocked at all when ssl=always, which will break redirects.
what about to make a new config parameter, lets say 'email_ssl'. Forcing https in emails by enabling email_ssl would not hurt much. If you read the mail from office - well little bit higher overhead with HTTPS on the server. But it works fine. If you read the mail from outside - https is the only option.
No, no new parameter. I think comment 9 is the way to go.
Also, as pointed out in our meeting, we should probably rename the ssl parameter to be clearer--something like ssl_redirect or force_ssl_redirect.
But renaming the parameter doesn't fix the bug and i think the current behavior is a bug. The comment for the parameter is sufficient to get the meaning. The bug is, that if the parameter set to NEVER, it enforces to use HTTP and that is definitely not the function of the parameter. If set to NEVER it should not redirect the client anywhere. HTTP stays HTTP and HTTPS stays HTTPS, the connection protocol is never changed.
(In reply to comment #13) > But renaming the parameter doesn't fix the bug No, right. I mean we need to rename the parameter and fix the bug. Sorry, we were having a discussion in the Bugzilla Meeting and my comment was mostly a reminder for whoever fixes this bug.
(In reply to comment #6) > We shouldn't be using absolute URLs in Bugzilla, and we > shouldn't force a redirect to non-SSL if you're using SSL, even if "ssl eq > never". Is this still valid, after bug 38862?
Doesn't comment 4 contain a separate feature request: to make all links relative in order to allow multiple domains? This bug is just about changing rules between urlbase and sslbase: do not enforce urlbase if 'never', instead use Bugzilla::CGI data for selection.
If force_ssl_redirect (renamed from 'ssl') is not 'never', the behavior is unchanged. Else we look at the current protocol (HTTP vs HTTPS) to decide between urlbase and sslbase. This way, you are free to choose one of both protocols, and Bugzilla will respect that. Note that Bugzilla will still redirect you to urlbase or sslbase, as 1) you need an absolute URL for bugmails, and 2) we don't want to reproduce bug 325079. So this means that you can now again have one internal and one external URL for the same installation, if you want to (as long as they don't use the same protocol, i.e. one must use HTTP and the other one HTTPS).
Assignee: general → LpSolit
Status: NEW → ASSIGNED
Attachment #392797 - Flags: review?(mkanat)
Target Milestone: --- → Bugzilla 3.6
Version: unspecified → 2.20.1
Have we thought about removing "authenticated sessions" and just making this "always" or "never" now that we have a login form on every page?
(In reply to comment #21) > Have we thought about removing "authenticated sessions" and just making this > "always" or "never" now that we have a login form on every page? That's out of the topic of this bug, IMO.
(In reply to comment #22) > That's out of the topic of this bug, IMO. In that case, let's do it first, in another bug, because it would enormously simplify this one.
What's the difficult part in this patch? :)
Comment on attachment 392797 [details] [diff] [review] patch, v1 This is obsolete now that I've checked in the patch for bug 514913.
Attachment #392797 - Flags: review?(mkanat) → review-
The fix is now very simple. :)
Summary: https login page switches to http on submit if the ssl parameter is set to "never" → https login page switches to http on submit if ssl_redirect = false
Comment on attachment 413390 [details] [diff] [review] patch, v2 This is OK, although the better solution would be to stop pre-pending the urlbase to the login form (because then we're not forcing them to $sslbase if they're using some other https url).
Attachment #413390 - Flags: review?(mkanat) → review+
Checking in Bugzilla/Util.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v <-- Util.pm new revision: 1.98; previous revision: 1.97 done
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.