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:220.127.116.11.1293757790739567 sessionid:1ae065832d84c531cee95e7c3d69a74c after they're: WT_FPC:id csrftoken:6090a1a3653ef313b8bb89c2d7011289 dloadday:18.104.22.168.1293757790739567 sessionid:2b3a0dea445dac629f3383d19740a0df I blame the different sessionid. No idea why this happens.
(In reply to comment #1) > Created attachment 531569 [details] > coverage result > > Look ma' no uncovered lines Crap! Wrong bug. Ignore attachment.
Attachment #531569 - Attachment is obsolete: true
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.
Also, confirmed with Firefox 3.6.
Now that we moved 'test' over to https://l10n-dev-sj.mozilla.org/, should we mark this one as fixed?
We shouldn't close this, it's still a bug. But it doesn't block the master merge, thus removing the block there.
No longer blocks: 652793
Summary: playdoh-based develop branch logs me out on back → log-in does not stick if when users go back to the page they logged in on if not hosted on '/'
(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.
Priority: P1 → --
Severity: minor → normal
Depends on: 658966
Priority: P5 → --
We'll try to reproduce this after https://bugzilla.mozilla.org/show_bug.cgi?id=658966 is resolved.
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.
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.
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.
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.
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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.