Closed Bug 639438 Opened 13 years ago Closed 13 years ago

Wiki and Perch on getfirebug.com require login again and again.

Categories

(Websites Graveyard :: getfirebug.com, defect)

Product:
Websites Graveyard
Component:
getfirebug.com
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: Honza, Unassigned)

Details

Both. getfirebug.com/wiki and getfirebug.com/perch require login again and again. 

In case of Perch (CMS) I need to often login 5-10 times to perform a single edit. It's just logout-ing me in the middle of the task.

Honza
I have got following error today:

Login error
There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again. 

Could it be related?

Honza
Another error message I am seeing:

Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in. 

Both comment #1 and comment #2 are related to getfirebug.com/wiki

Honza
I am getting the same error messages and that's really annoying.
Could this be a conflict with page caching?
Lately I realized, that the images, I uploaded inside Perch some time ago, suddenly disappeared now.
Could it be the same problem as we have with the login?

Maybe updating Perch (bug 650212) would fix that problem?
Also I believe, this issue deserves a higher priority, because also all our wiki editors are affected by that.
Neil, what we should do to get more attention for this issue?

I almost can't use Firebug wiki, since I need to login dozens of times to make a simple change....

Honza
Another 20 logins today...

It's so frustrating to improve/create any Firebug documentation.

Please, please, pretty please, could this be fixed?

Honza
I can just emphasize this. So a big PLEASE from me, too.
Neil, I thought maybe you can also help in this case...
Hi guys, sorry it took me so long to respond. This sounds like bug 542418 - maybe someone made a server-side change that broke that fix?
(In reply to comment #10)
> Hi guys, sorry it took me so long to respond.
Hi Neil, thanks for the effort to fix this one, I really appreciate that!

> This sounds like bug 542418 -
> maybe someone made a server-side change that broke that fix?
We don't have an access to the server side wiki installation files so, I don't know. I guess you need to check the log...?

Honza
Neil, I'd be VERY, VERY thankful, if this could be fixed soon. Currently it's almost impossible to work on the pages.

Also I realized, that when uploading new versions for images in the wiki, they are not updated (even when the size is shown correctly), e. g. http://getfirebug.com/wiki/index.php/File:Net_Panel.png

Could that be related?
I thought I mentioned this earlier but I guess I didn't - I haven't worked for Mozilla for over a year, so I have about the same access to everything as you guys do. Less, actually, as I don't have SVN access any more either.

I cc'ed Mike Morgan as he might be able to at least direct this to the proper queue, but I can't do much more to move this forward. Sorry guys!
You already mentioned, that you're not working for Mozilla anymore, but I was in the hope, that you at least still have access.
Non-the-less redirecting this to the right people is already helping. Thanks for that!
This smells like something on the server side. I had a similar problem before on getpersonas. Shyam or Jeremy, can you tell us how getfirebug is deployed? If it runs on several webheads (which I assume):
- can we set the PHP session handler to either store sessions in a shared directory, or hook it up to memcache? The goal is to share sessions between app heads.
- for file uploads from perch, where do those get stored? If the directory is not shared between webheads, then this would explain why uploads can be seen if they happen to be served by one server, but not the other. If so, we'd need to merge the existing upload folders onto a common, shared directory as well.

Let me know what you find, perhaps my guess is completely off...
session.save_path => /mnt/netapp/php_sessions => /mnt/netapp/php_sessions

so that should be shared.

Path related config in perch:

    define('PERCH_LOGINPATH', '/perch');
    define('PERCH_PATH', str_replace(DIRECTORY_SEPARATOR.'config', '', dirname(__FILE__)));

    define('PERCH_RESFILEPATH', PERCH_PATH . DIRECTORY_SEPARATOR . 'resources');
    define('PERCH_RESPATH', PERCH_LOGINPATH . '/resources');


I'm not sure if any of those correlate to where uploads are stored.
I'd need an account on the wiki to help diagnose this. Can someone create one for me?
(In reply to comment #17)
> I'd need an account on the wiki to help diagnose this. Can someone create
> one for me?

I can help too if someone makes me an account, if you need a second set of eyes.
I created accounts for you both. You should have got an email.
I've been clicking around and editing pages (in my user namespace, mind you) for the last 20 minutes and have yet to see any session problems.
The typical demo effect. :-)
Maybe it's just happening on longer pages. You can try it on any other page. Just don't forget to delete your changes again. :-)
Looks like one of the app servers had an incorrectly configured session directory. I've checked the change in to puppet, so this shouldn't come up again.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
I will try that the next days for the wiki, but I can already say, that your change doesn't have any effect to Perch. So this issue unfortunately is not fixed yet.
I looked at the perch source code and it seems to wrap the built-in PHP session handler, so a) the server error mentioned above would cause this bug and b) the fix should have fixed it for both apps--I am reluctant to jump to conclusions about a bug hidden deep inside the code. Perhaps Apache needs kicked?
Please also note bug 650212, which I already mentioned in comment 4. Maybe updating the version of Perch will also solve that problem. Though I didn't have a look at the new version's sources yet.
Also was Apache restarted after making the changes mentioned in comment 22?
Obviously there's no issue regarding the wiki anymore. Thanks for that! Though Perch is still giving me headache.

Jeremy, please either reopen this issue or let me know, if I should create a new one for it. But also please first regard the last two comments.
I created bug 687288 in the hope to get the Perch issues fixed soon.
Product: Websites → Websites Graveyard
You need to log in before you can comment on or make changes to this bug.