470517 - Either set SUMOv1 cookie on support.mozilla.com to be valid for not just https (preferred), or if not possible, at least clear netscalar cache

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[Nelson Ko [:nkoth]]

Logging into SUMO is now appearing to not work in https. The reason is explained in bug 470516.

Can IT take one of the actions suggested in that bug? Of course set the SUMOv1 cookie on support.mozilla.com is the preferred solution. Because the other solution is just a temporary thing (since it breaks https login which we want for users).

Comment 1

[Aravind Gottipati [:aravind]]

"If IT can set the SUMOv1 cookie on support.mozilla.com to be
valid for all types of connections, that will be great."

So we currently have "php_flag session.cookie_secure off" for the http version of the site.  I am assuming that you want that set to on.  I can do that, but I am not sure what the ramifications of that would be.  Let me try to track down folks in my team that know more about this.

Comment 2

[Aravind Gottipati [:aravind]]

I have cleared NS cache in the meantime.

Comment 3

[Nelson Ko [:nkoth]]

strange. clearing NS cache did not have any effect.

This is the test case:

1) clear browser cookies/cache.

2) Type http://support.mozilla.com/tiki-login.php?locale=en-US into the browser. It should redirect you to http://support.mozilla.com/tiki-login_scr.php, but instead it goes to https://support.mozilla.com/tiki-login_scr.php

Does the NS cache redirects? Were the redirects cache cleared?

Comment 4

[Nelson Ko [:nkoth]]

I just checked the https versions of the site: This is what we have on support-stage:

session.cookie_secure	Local value: Off (SUMOv1) 

on production:

session.cookie_secure	Local value: On (SUMOv1)

So if anything, what we want might be  the opposite of what you describe below, where the value should be Off for the https version of the site. I am not sure if there is any security or other implication of this that means this should not be done...

(In reply to comment #1)
> "If IT can set the SUMOv1 cookie on support.mozilla.com to be
> valid for all types of connections, that will be great."
> 
> So we currently have "php_flag session.cookie_secure off" for the http version
> of the site.  I am assuming that you want that set to on.  I can do that, but I
> am not sure what the ramifications of that would be.  Let me try to track down
> folks in my team that know more about this.

Comment 5

[Nelson Ko [:nkoth]]

The other solution for this is for me to reopen bug 398239 and modify that so that users that login to SUMO use https for ALL pages. I am not sure what the performance or other implications are of that.

In my opinion, https for all pages is not really needed for SUMO, but I do note that bugzilla for example seems to do this.

Comment 6

[Reed Loden [:reed]]

Even though you may be submitting your password over https, if you swap to http, you're still just endangering the user, as you have to send a cookie with a login token in it, which could easily be intercepted by anybody and abused. Should just stay in https for logged-in users.

Comment 7

[Nelson Ko [:nkoth]]

OK Reed, the patch in Bug 470516 fixes that. 

(In reply to comment #6)
> Even though you may be submitting your password over https, if you swap to
> http, you're still just endangering the user, as you have to send a cookie with
> a login token in it, which could easily be intercepted by anybody and abused.
> Should just stay in https for logged-in users.

Comment 8

[Nelson Ko [:nkoth]]

OK, this is now superceded by fix in Bug 470516, and the remaining question as to why clearing caches in comment #3 had no effect is now Bug 470538.

Thanks Aravind/Reed for the help.

Comment 9

[matthew zeier [:mrz]]

(In reply to comment #5)
> In my opinion, https for all pages is not really needed for SUMO, but I do note
> that bugzilla for example seems to do this.

I agree with you wrt to SUMO and would like to avoid pushing all of sumo under SSL.