329638 - https login page switches to http on submit if ssl_redirect = false

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect, P1)

Description

[Ronny Freigang]

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

Comment 1

[Frédéric Buclin]

'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.

Comment 2

[Ronny Freigang]

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!

Comment 3

[Ronny Freigang]

Status of bug/issue is still unconfirmed.

No further comments to the ssl behavior? 

Comment 4

[Darren]

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?

Comment 6

[Max Kanat-Alexander]

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".

Comment 7

[Marek Fort]

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.

Comment 8

[Ronny Freigang]

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?

Comment 9

[Vitaly Fedrushkov]

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.

Comment 10

[Marek Fort]

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.

Comment 11

[Max Kanat-Alexander]

No, no new parameter. I think comment 9 is the way to go.

Comment 12

[Max Kanat-Alexander]

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.

Comment 13

[Ronny Freigang]

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.

Comment 14

[Max Kanat-Alexander]

(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.

Comment 16

[Vitaly Fedrushkov]

(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?

Comment 17

[Max Kanat-Alexander]

(In reply to comment #16)
> Is this still valid, after bug 38862?

  Yes.

Comment 18

[Vitaly Fedrushkov]

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.

Comment 20

[Frédéric Buclin]

Attachment: patch, v1

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).

Comment 21

[Max Kanat-Alexander]

Have we thought about removing "authenticated sessions" and just making this "always" or "never" now that we have a login form on every page?

Comment 22

[Frédéric Buclin]

(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.

Comment 23

[Max Kanat-Alexander]

(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.

Comment 24

[Frédéric Buclin]

What's the difficult part in this patch? :)

Comment 25

[Max Kanat-Alexander]

Comment on attachment 392797 [details] [diff] [review]
patch, v1

This is obsolete now that I've checked in the patch for bug 514913.

Comment 26

[Frédéric Buclin]

Attachment: patch, v2

The fix is now very simple. :)

Comment 27

[Max Kanat-Alexander]

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).

Comment 28

[Frédéric Buclin]

Checking in Bugzilla/Util.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v  <--  Util.pm
new revision: 1.98; previous revision: 1.97
done

Comment 29

[Max Kanat-Alexander]

Added to the release notes in bug 547466.