User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030128 Chimera/0.6+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:13b) Gecko/20030212 Multiuser SideCar is a program that works with Kerberos for non-Kerberized applications. In order to distinquish between multiple users, it uses outgoing port numbers. Mozilla 1.3b seem to do something different with ports so that the SideCar request cannot distinquish which user's credentials are being requested. Here is the error in the log: 02/21/03 08:14:45 184.108.40.206:59554 getKAT ftp_cit-agent.ftp@CIT.CORNELL.EDU * 1039904 can't find client associated with uid, 1039904. According to the main developer of Cornell's Mac OS X SideCar, the problem can be summarized as "Looks like when v 1.3b of mozilla makes the server connection it either uses a port that is assigned to another user or a port that isn't in use anymore when the sidecar request comes in." Testing out the classic (OS 9) SideCar works fine, because that is not a multiuser version of SideCar and therefore doesn't need to worry about port numbers. Most evidence says 1.3a worked fine, including redownloading the old version. I thought it didn't work in either, but I am not now sure which version I was using a couple weeks ago when I first noticed the problem. I realize this might be hard for you to solve, not having access to Cornell's OS X SideCar, so I am providing you with the information of the developer. Her name is Joy Veronneau and her email is email@example.com . Reproducible: Always Steps to Reproduce: 1. Open OS X SideCar 2. Go to a SideCar protected web page 3. There's no step 3 :-) Actual Results: Got a "SideCar Required" page. Expected Results: Should have been prompted for my Kerberos name and password.
Fred, Mozilla's developers aren't likely to contact SideCar's developer by e-mail. If you like, you may invite her to contribute to this bug, though. Is this "SideCar" something you can provide a link to?
Here is the basic idea behind how sidecar works.A department here at cornell can set up a webserver which requires kerberos authentication to view a page. They run special authentication software to do this.A user on Mac OS X that wants to view a protected page first starts up the sidecar program on their mac. This program listens for special messages on port 913. Then the user will type in the address of the web page they want to get to using any browser.If the page is protected, the web server says "Oh, I need authentication for this page" and sends a special message to the client's sidecar program on port 913. Encoded in this message is the OUTGOING PORT number that the webserver received the request from. Sidecar looks through mac os x process table to see which user is associated with that port. So, on a multiuser system, multiple users can each be authenticated individually based on this port number.With 1.3b of Mozilla, this outgoing port number is invalid by the time sidecar gets the message, so it can not authenticate based on port number.Hope this helps explain the problem.Joy
As for getting your hands on SideCar, I could send you the link, but you need to authenticate with a web form to download it off campus (or with SideCar itself if you're just upgrading/reinstalling), so it won't do you any good. You could certainly ask Joy (firstname.lastname@example.org, that is) if we're able to provide you with a copy, I'm not 100% sure of the policy of that. I'm sure we can't provide you with a username / password, but it might be okay to have the software to install it and at least watch how it works, and see if it prompts you with an unconfigured Kerb dialog. Again, Joy'll need to figure out the policy on that.
Ok, I was just reading through Fred's comments. I don't think it is necessary for you to have the SideCar program in order to solve this bug. You should be able to look at code differences and network statistics between versions 1.3a and 1.3b and figure out why/how the connection port numbers are behaving differently.Thanks,Joy
I just wanted to report that the bug still exists in the final 1.3 release. Have you had any luck. I've been a long time Mozilla user, but if this continues I'll be forced to pick something else.
marking NEW looks like a regression from the async IO landing
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: dougt → darin
Hi,I have new information on this. A user at dartmouth wrote me the following:-----------It appears to me that the port number is getting passed to the web server & cgi correctly.The problem may be that Mozilla is using IPv6.If I do an "lsof" of Explorer while it's talking to the web server I see:LaunchCFM 7955 davidg 24u inet 0x01c4b50c 0t0 TCP rocky.kiewit.dartmouth.edu:52045->lemitar.dartmouth.edu:http (ESTABLISHED)Mozilla looks like:mozilla-b 7952 davidg 27u sock 0t0 no further information on AF_INET6i.e., lsof doesn't know how to interpret the IPv6 address. Maybe casd can't do it either?-------casd that is mentioned in the above quote is a daemon that is part of the SideCar program. It uses some lsof code to look up the outgoing port number and match it back to a userid.I am wondering if one of you developers would be willing to open up a conversation with me so that we could possibly get this fixed in SideCar if possible. It is now affecting users at both Cornell and Dartmouth.I have questions like "what changed between 1.3a and 1.3b that might cause this problem?" I find it hard to believe that you would make a change as big as going to IPv6 between 1.3a and 1.3b so I suspect that may not be the problem?ThanksJoyjv11@cornell.edu
Would you guys please communicate with our developers on what changed that might be causing this to happen. It's been nearly two months since we heard anything from you. I've been less than impressed with the your responsiveness lately. -Fred
fred: my appologies, but please understand that we are quite swamped with a large number of bugs. if anyone can help debug this problem it would be most appreciated. i have futured this bug because i know that i will not have time to work on this bug anytime soon (Target Milestone = Future). one thing you could do to help is to try the most recent nightly build of mozilla that you can get your hands on. please see http://ftp.mozilla.org/pub/mozilla/nightly/latest it would be helpful to know whether or not the latest nightly build has this bug. thanks!
Hi, I don't really think this is a BUG in Mozilla. Rather, something has changed in Mozilla between 1.3a and 1.3b that afffects how my program works. When Mozilla opens a port and contacts a server on our campus, the server will send that client's outgoing port number BACK to the client in the authentication request. My program then uses lsof to link 'the port the request went out on' to a UID on the client machine. The problem is that Mozilla seems to now be using IPv6 and the latest lsof I can get for MacOSX doesn't support that yet... at least that is my theory. Can someone just tell me please if Mozilla has recently begun to use IPv6. Or, any other ideas about what changed between Mozilla versions 1.3a and 1.3b. I just tried 1.3.1 and the behavior is the same. Thank you! email@example.com
Assignee: darin → nobody
QA Contact: benc → networking
Target Milestone: Future → ---
Is this still issue when using latest version?
Well, it doesn't matter any more. we have retired sidecar. Thanks. Joy
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.