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

RESOLVED FIXED

Status

mozilla.org Graveyard
Server Operations
--
blocker
RESOLVED FIXED
9 years ago
3 years ago

People

(Reporter: nkoth, Assigned: aravind)

Tracking

Details

(Reporter)

Description

9 years ago
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).
(Reporter)

Updated

9 years ago
Blocks: 470516
(Reporter)

Updated

9 years ago
Summary: Either set SUMOv1 cookie on support.mozilla.com to be valid for not just https, or clear netscalar cache → 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
(Assignee)

Updated

9 years ago
Assignee: server-ops → aravind
(Assignee)

Comment 1

9 years ago
"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.
(Assignee)

Comment 2

9 years ago
I have cleared NS cache in the meantime.
(Reporter)

Comment 3

9 years ago
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?
(Reporter)

Comment 4

9 years ago
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.
(Reporter)

Comment 5

9 years ago
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.
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.
(Reporter)

Comment 7

9 years ago
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.
(Reporter)

Comment 8

9 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 9

9 years ago
(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.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.