656219 - log-in does not stick if when users go back to the page they logged in on if not hosted on '/'

Status: RESOLVED INVALID

(Webtools Graveyard :: Elmo, defect, P5)

Description

[Axel Hecht [:Pike]]

The current /test/ install on playdoh/develop logs me out when doing

Log-in, surf along, all is fine.

Go back, click on a link, logged out.

This is at least happening when back gets me to /teams/.

I'm testing that on a profile that doesn't have any cookies or tabs open for the production site, cleared cookies before, too.

cookies before going back are:

WT_FPC:id
csrftoken:6090a1a3653ef313b8bb89c2d7011289
dloadday:93.210.164.185.1293757790739567
sessionid:1ae065832d84c531cee95e7c3d69a74c

after they're:

WT_FPC:id
csrftoken:6090a1a3653ef313b8bb89c2d7011289
dloadday:93.210.164.185.1293757790739567
sessionid:2b3a0dea445dac629f3383d19740a0df

I blame the different sessionid. No idea why this happens.

Comment 1

[Peter Bengtsson [:peterbe]]

Attachment: coverage result

Look ma' no uncovered lines

Comment 2

[Peter Bengtsson [:peterbe]]

(In reply to comment #1)
> Created attachment 531569 [details]
> coverage result
> 
> Look ma' no uncovered lines
Crap! Wrong bug. Ignore attachment.

Comment 3

[Peter Bengtsson [:peterbe]]

For the record, I can reproduce this again and again with FF4. 

0) Be logged out
1) go to https://l10n-stage-sj.mozilla.org/test/
2) Log in 
3) Click the Teams link
4) Click Back button
5) Reload

These same steps don't reproduce it in Chrome or Safari.

Comment 4

[Axel Hecht [:Pike]]

Also, confirmed with Firefox 3.6.

Comment 5

[Staś Małolepszy :stas]

Now that we moved 'test' over to https://l10n-dev-sj.mozilla.org/, should we mark this one as fixed?

Comment 6

[Axel Hecht [:Pike]]

We shouldn't close this, it's still a bug.

But it doesn't block the master merge, thus removing the block there.

Comment 7

[Staś Małolepszy :stas]

(In reply to comment #6)
> We shouldn't close this, it's still a bug.

Is it really?  We're not going to be using the site in a /subdir/, and I don't think we should make any efforts in order to make it work properly in such a setup.  It's a wasted energy IMHO.  The site is not supposed to be run from a /subdir/.  It's a feature, not a bug.

Removing P1 for sure.  I'd like to wontfix this, but let's make the call together during the next triage meeting.

Comment 8

[Peter Bengtsson [:peterbe]]

We'll try to reproduce this after https://bugzilla.mozilla.org/show_bug.cgi?id=658966 is resolved.

Comment 9

[Peter Bengtsson [:peterbe]]

Can we resolve this now? We're not using a sub-directory to serve any more. And we've also re-written the way the log in works entirely with a new AJAX (using JSON) solution.

Comment 10

[Axel Hecht [:Pike]]

This bug is still open despite the fact that we're not using /foo installs anymore, so us not doing that shouldn't make us close this bug.

Did we ever manage to reproduce this bug outside of a bm-l10n-dashboard01 install? If so, we can check if the new login logic fixed this.

Comment 11

[Peter Bengtsson [:peterbe]]

Nope. Not tried to reproduce it by running it from a subdirectory locally. I don't think there is any other way to reproduce it.

Comment 12

[Peter Bengtsson [:peterbe]]

Can we resolve this bug now please?

Running apps in subdirectories is a, to begin with, never a good idea. Also, it was not reproduce-able and could easily have happened because we used to run two different Django instances (dev & stage) on the same domain both fronted by a load balancer.

Comment 13

[Peter Bengtsson [:peterbe]]

The bug is moot because you shouldn't run it as a sub-directory. 

Re-open and re-assign if you still think it's important.