Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#533 closed Bug/Something is broken (fixed)

User has trouble sending email via webmail from public computer

Reported by: https://id.mayfirst.org/jackaponte Owned by: https://id.mayfirst.org/jamie
Priority: Medium Component: Tech
Keywords: webmail Cc:
Sensitive: no

Description

Hey folks,

One of the ALP staff (username orgpv) called me today because she couldn't send email via webmail. She said that when she clicked on "new message" or "compose" or whatever it is, a pop-up window appeared within which she wrote her new message. But when she clicked "send," instead of the message sending, she was asked to log in again. She said this became an endless cycle with the message never actually being sent.

I logged into her account and was able to send a message successfully; I asked about the computer she was using and she said she was using Firefox on a public computer at her school. At that point my somewhat uneducated guess was that something about how cookies were set up on that public computer was making the browser "forget" that she was logged in, thus resulting in the repeated request for authentication.

I guess I have two questions: 1) is this probably what was happening, and 2) is there anything that May First can change on your end to avoid the problem? Because I know that people will continue to attempt to use their webmail from public computers and other computers over which we don't have control, and I hope that there's a solution that'll allow them to send mail, regardless.

Thanks!

Change History (18)

comment:1 Changed 10 years ago by https://id.mayfirst.org/jamie

Thanks for posting Jack.

That sounds incredibly frustrating. I think your assessment is correct - I would imagine that Firefox was configured to reject all cookies. In the earlier days of web development, applications were designed to pass the session key via the URL or via a post setting so you didn't actually need cookies - however, I'm not sure if that is being done any more or whether Horde has that option. Another approach could be to put a message at the top of the login saying: Cookies must be enabled with a link to a page that explains how to enable cookies.

What do you think?

comment:2 Changed 10 years ago by https://id.mayfirst.org/jackaponte

The "cookies must be enabled" link may help, though I'd make it fairly explicit, adding that "If you find yourself being logged out again and again, please follow these instructions to enable cookies in your browser." Would including a link to a page explaining cookies [0] be too much? Might assuage the fears of people encountering the message and not knowing what cookies are.

Anyhow, yes, that sort of message might help, but I'd imagine that there'd be cases where people couldn't change the settings (public computers might have that locked down) or were too afraid to do so. So a workaround that eliminated the need for users to do anything to get things working would be best, of course, though perhaps impossible. Let me know if you make any headway on other solutions.

[0] Maybe this? http://computer.howstuffworks.com/cookie.htm

comment:3 follow-up: Changed 10 years ago by https://id.mayfirst.org/dkg

It probably makes sense to verify that missing cookies is actually the cause of the misbehavior, and not something else, like weird caching, proxies, bad extensions, etc. Note that if the webapp runs entirely in HTTPS (which is not in principle cacheable by any machine but the origin server and the client) then we should be able to rule out proxies entirely.

That said, it's also pretty easy to do a simple test to see whether cookies are allowed. If you're willing to require that the browser is running javascript (or its required to use javascript anyway), you can just test for allowable cookies directly by manipulating the document.cookie construct.

If you're not sure if the browser is running javascript, the simple way to do that is to always include a large, unavoidable div that says something like:

Warning! You appear to have Javascript disabled. This site may not work correctly without Javascript enabled.

and then use javascript itself to hide/collapse/remove the warning div during pageload. So if they have javascript: no warning; if they don't have it, or it is not enabled: they should see it clearly.

If you don't want to assume/require javascript, you could do a similar test for cookies with HTTP redirection:

  • visiting the home page with a cookie already set lets you access the site cleanly with no issues.
  • visiting the home page without any cookies set causes the server to issue a cookie, and then redirect you to a separate page called, say, nocookies.
  • visiting nocookies with a cookie already set redirects you to the home page with your cookie intact.
  • visiting nocookies without cookies set causes the server to try to set a cookie, and also display a warning message about "please allow cookies in your browser and then refresh this page", along with links for more info like Jack suggests.

If you wanna get fancier, the nocookie page could take a path or URL as a GET parameter (filtered to allow only the current domain to avoid redirection attacks), and if a cookie is cleanly present, it could redirect the user to the URL indicated by the parameter instead of returning them just to the home page.

Do these strategies make sense? I'm surprised that horde doesn't implement something like this already, if it does actually require cookies.

comment:4 in reply to: ↑ 3 Changed 10 years ago by https://id.mayfirst.org/jamie

Replying to https://id.mayfirst.org/dkg:

It probably makes sense to verify that missing cookies is actually the cause of the misbehavior,

Good point. Huh. I just configured firefox to not accept cookies and I wasn't able to login to Horde at all. So I actually think this problem might be something else entirely.

That doesn't mean your strategies aren't good ones. I tried to reply to this ticket before re-enabling cookies and pretty much realized that I can't do anything without cookies. If we implement your strategy, it should probably be implemented on the members page rather than in Horde.

comment:5 Changed 10 years ago by https://id.mayfirst.org/jamie

This still raises the question: what happened to the ALP user at the public terminal?

comment:6 Changed 10 years ago by https://id.mayfirst.org/dkg

  • Keywords webmail added

Do we have a specific time that the failure occurred? Can we look at the logs for that time to see what the session looked like from the server's perspective?

comment:7 Changed 10 years ago by https://id.mayfirst.org/jackaponte

Ejeris let me know that the problem was happening on 1/28/08 at 8:24pm. That should be pretty close to when she was actually experiencing the problem, as she wrote to me from that computer lab from her hotmail account. I'd look at the logs from a little bit earlier than that specific time.

comment:8 follow-up: Changed 10 years ago by https://id.mayfirst.org/josuepp

oh goodie, here's an opportunity to learn a little about debian logs.

auth.log

Jan 28 20:32:28 viewsic authdaemond: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=orgpv

Jan 28 20:32:58 viewsic last message repeated 5 times

Jan 28 20:33:04 viewsic authdaemond: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=orgpv

Jan 28 20:33:28 viewsic last message repeated 7 times

Jan 28 20:33:33 viewsic authdaemond: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=orgpv

Jan 28 20:33:56 viewsic last message repeated 3 times

Jan 28 20:34:20 viewsic authdaemond: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=orgpv

Jan 28 20:34:50 viewsic last message repeated 4 times

Jan 28 20:34:57 viewsic authdaemond: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=orgpv

Jan 28 20:35:06 viewsic authdaemond: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=orgpv

Jan 28 20:35:13 viewsic authdaemond: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=orgpv

Jan 28 20:35:20 viewsic authdaemond: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=orgpv

Jan 28 20:36:42 viewsic authdaemond: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=orgpv

Jan 28 20:37:40 viewsic last message repeated 8 times

ejeris was not having fun...

where else should i look? nothing in error.log, server-wide-error.log or server-wide-access.log

comment:9 in reply to: ↑ 8 ; follow-up: Changed 10 years ago by https://id.mayfirst.org/jamie

Thanks Josue for posting the logs. Hm. I would try grepping the /var/log/mail.log on viewsic for the username. It should indicate if there was any successful logins (grepping for imapd-ssl and the username should show the relevant entries).

You can also grep on stallman.mayfirst.org (ssh as root - your key is there) for the apache logs (in /var/log/apache2).

When posting - it would be great if you could post both the command line of the grep that you execute (so we can see your arguments and re-use) and the command line after the command execute (to look for error codes). Also - putting it between:

{{{
log file
}}}

We'll make the display prettier :). Thanks Josue!

Jamie

comment:10 in reply to: ↑ 9 Changed 10 years ago by https://id.mayfirst.org/jackaponte

Just want to note that at some point that night, I logged into Ejeris' account from my computer, so a successful login in the logs might be mine, not hers.

comment:11 follow-up: Changed 10 years ago by https://id.mayfirst.org/josuepp

okay, will try to make things prettier (thx dkg and jamie!).

successful logins during the same time period, using this command:

grep orgpv mail.log.3 |grep imapd-ssl|less in viewsic

(cuz i could not get this to work: egrep "imapd-ssl|orgpv")

Jan 28 20:32:13 viewsic imapd-ssl: LOGIN, user=orgpv, ip=[::ffff:209.51.163.17], protocol=IMAP

Jan 28 20:32:13 viewsic imapd-ssl: LOGOUT, user=orgpv, ip=[::ffff:209.51.163.17], headers=0, body=0, rcvd=38, sent=261, time=0, starttls=1

Jan 28 20:32:20 viewsic imapd-ssl: LOGIN, user=orgpv, ip=[::ffff:209.51.163.17], protocol=IMAP

Jan 28 20:32:21 viewsic imapd-ssl: LOGIN, user=orgpv, ip=[::ffff:209.51.163.17], protocol=IMAP

Jan 28 20:32:21 viewsic imapd-ssl: LOGOUT, user=orgpv, ip=[::ffff:209.51.163.17], headers=0, body=0, rcvd=96, sent=471, time=0, starttls=1

Jan 28 20:32:21 viewsic imapd-ssl: LOGOUT, user=orgpv, ip=[::ffff:209.51.163.17], headers=0, body=0, rcvd=334, sent=2718, time=1, starttls=1

Jan 28 20:32:22 viewsic imapd-ssl: LOGIN, user=orgpv, ip=[::ffff:209.51.163.17], protocol=IMAP

Jan 28 20:32:22 viewsic imapd-ssl: LOGOUT, user=orgpv, ip=[::ffff:209.51.163.17], headers=0, body=0, rcvd=106, sent=383, time=0, starttls=1

Jan 28 20:32:22 viewsic imapd-ssl: LOGIN, user=orgpv, ip=[::ffff:209.51.163.17], protocol=IMAP

Jan 28 20:32:29 viewsic imapd-ssl: LOGOUT, user=orgpv, ip=[::ffff:209.51.163.17], headers=0, body=0, rcvd=309, sent=198753, time=7, starttls=1

Jan 28 20:33:18 viewsic imapd-ssl: LOGIN, user=orgpv, ip=[::ffff:209.51.163.17], protocol=IMAP

Jan 28 20:33:30 viewsic imapd-ssl: LOGOUT, user=orgpv, ip=[::ffff:209.51.163.17], headers=0, body=0, rcvd=284, sent=149161, time=12, starttls=1

Jan 28 20:33:45 viewsic imapd-ssl: LOGIN, user=orgpv, ip=[::ffff:209.51.163.17], protocol=IMAP

Jan 28 20:33:45 viewsic imapd-ssl: LOGOUT, user=orgpv, ip=[::ffff:209.51.163.17], headers=0, body=0, rcvd=183, sent=1391, time=0, starttls=1

Jan 28 20:33:59 viewsic imapd-ssl: LOGIN, user=orgpv, ip=[::ffff:209.51.163.17], protocol=IMAP

Jan 28 20:34:01 viewsic imapd-ssl: LOGOUT, user=orgpv, ip=[::ffff:209.51.163.17], headers=0, body=61050, rcvd=2623, sent=84127, time=2, starttls=1

Jan 28 20:34:09 viewsic imapd-ssl: LOGIN, user=orgpv, ip=[::ffff:209.51.163.17], protocol=IMAP

Jan 28 20:34:09 viewsic imapd-ssl: LOGOUT, user=orgpv, ip=[::ffff:209.51.163.17], headers=0, body=0, rcvd=38, sent=261, time=0, starttls=1

Jan 28 20:34:23 viewsic imapd-ssl: LOGIN, user=orgpv, ip=[::ffff:209.51.163.17], protocol=IMAP

Jan 28 20:34:23 viewsic imapd-ssl: LOGOUT, user=orgpv, ip=[::ffff:209.51.163.17], headers=0, body=0, rcvd=38, sent=261, time=0, starttls=1

did "grep orgpv webmail.ssl.access.log" in stallman and found these:

128.122.253.229 - - [28/Jan/2008:20:32:13 -0500] "GET /imp/login.php?imapuser=orgpv&server=viewsic.m
ayfirst.org&port=993&protocol=imap%2Fssl%2Fnovalidate-cert&smtphost=localhost&smtpport=25&logout_rea
son=sessionip&url=%2Fimp%2Fmailbox.php%3Fmailbox%3DINBOX HTTP/1.1" 200 3444 "https://webmail.mayfirs
t.org/imp/search.php?no_match=1&mailbox=%2A%2Asearch_e4rmxf3acfcog8gggcwcc" "Mozilla/5.0 (Windows; U
; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

128.122.253.229 - - [28/Jan/2008:20:32:13 -0500] "GET /imp/login.php?imapuser=orgpv&server=viewsic.m
ayfirst.org&port=993&protocol=imap%2Fssl%2Fnovalidate-cert&smtphost=localhost&smtpport=25&logout_rea
son=sessionip&url=%2Fimp%2Fmailbox.php%3Fmailbox%3DINBOX HTTP/1.1" 200 3444 "https://webmail.mayfirs
t.org/imp/login.php?imapuser=orgpv&server=viewsic.mayfirst.org&port=993&protocol=imap%2Fssl%2Fnovali
date-cert&smtphost=localhost&smtpport=25&logout_reason=sessionip&url=%2Fimp%2Fmailbox.php%3Fmailbox%
3DINBOX" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.
11"

128.122.253.229 - - [28/Jan/2008:20:32:20 -0500] "POST /imp/redirect.php HTTP/1.1" 302 39 "https://w
ebmail.mayfirst.org/imp/login.php?imapuser=orgpv&server=viewsic.mayfirst.org&port=993&protocol=imap%
2Fssl%2Fnovalidate-cert&smtphost=localhost&smtpport=25&logout_reason=sessionip&url=%2Fimp%2Fmailbox.
php%3Fmailbox%3DINBOX" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127
Firefox/2.0.0.11"

128.122.253.229 - - [28/Jan/2008:20:32:21 -0500] "GET /index.php?url=https%3A%2F%2Fwebmail.mayfirst.
org%2Fimp%2Fmailbox.php%3Fmailbox%3DINBOX HTTP/1.1" 200 356 "https://webmail.mayfirst.org/imp/login.
php?imapuser=orgpv&server=viewsic.mayfirst.org&port=993&protocol=imap%2Fssl%2Fnovalidate-cert&smtpho
st=localhost&smtpport=25&logout_reason=sessionip&url=%2Fimp%2Fmailbox.php%3Fmailbox%3DINBOX" "Mozill
a/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

71.255.57.104 - - [28/Jan/2008:20:34:04 -0500] "GET /imp/login.php?imapuser=orgpv&server=viewsic&log
out_reason=failed HTTP/1.1" 200 3363 "https://members.mayfirst.org/" "Mozilla/5.0 (Macintosh; U; Int
el Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

71.255.57.104 - - [28/Jan/2008:20:34:04 -0500] "GET /imp/login.php?imapuser=orgpv&server=viewsic&log
out_reason=failed HTTP/1.1" 200 3363 "https://members.mayfirst.org/" "Mozilla/5.0 (Macintosh; U; Int
el Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

71.255.57.104 - - [28/Jan/2008:20:34:04 -0500] "GET /js/prototype.js HTTP/1.1" 200 72726 "https://we
bmail.mayfirst.org/imp/login.php?imapuser=orgpv&server=viewsic&logout_reason=failed" "Mozilla/5.0 (M
acintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

71.255.57.104 - - [28/Jan/2008:20:34:05 -0500] "GET /js/horde-prototype.js HTTP/1.1" 200 2529 "https
://webmail.mayfirst.org/imp/login.php?imapuser=orgpv&server=viewsic&logout_reason=failed" "Mozilla/5
.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

71.255.57.104 - - [28/Jan/2008:20:34:06 -0500] "GET /imp/js/login.js HTTP/1.1" 200 1303 "https://web
mail.mayfirst.org/imp/login.php?imapuser=orgpv&server=viewsic&logout_reason=failed" "Mozilla/5.0 (Ma
cintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

71.255.57.104 - - [28/Jan/2008:20:34:06 -0500] "GET /themes/screen.css HTTP/1.1" 200 16217 "https://
webmail.mayfirst.org/imp/login.php?imapuser=orgpv&server=viewsic&logout_reason=failed" "Mozilla/5.0
(Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

71.255.57.104 - - [28/Jan/2008:20:34:06 -0500] "GET /themes/bluewhite/screen.css HTTP/1.1" 200 3042
"https://webmail.mayfirst.org/imp/login.php?imapuser=orgpv&server=viewsic&logout_reason=failed" "Moz
illa/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

71.255.57.104 - - [28/Jan/2008:20:34:06 -0500] "GET /imp/themes/screen.css HTTP/1.1" 200 7421 "https
://webmail.mayfirst.org/imp/login.php?imapuser=orgpv&server=viewsic&logout_reason=failed" "Mozilla/5
.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

71.255.57.104 - - [28/Jan/2008:20:34:06 -0500] "GET /imp/themes/bluewhite/screen.css HTTP/1.1" 200 6
45 "https://webmail.mayfirst.org/imp/login.php?imapuser=orgpv&server=viewsic&logout_reason=failed" "
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

71.255.57.104 - - [28/Jan/2008:20:34:06 -0500] "GET /themes/graphics/alerts/message.png HTTP/1.1" 20
0 477 "https://webmail.mayfirst.org/imp/login.php?imapuser=orgpv&server=viewsic&logout_reason=failed
" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

what does it mean?

comment:12 Changed 10 years ago by https://id.mayfirst.org/jamie

Hm. I started by fixing the no-validate-cert issue. I experienced problems when I initially setup viewsic because, unlike the other servers, for historical reasons we had installed the SSL certificate on viewsic to be mail.mayfirst.org (not viewsic.mayfirst.org), so in Horde the connection failed without the no-validate-cert option. The better solution (which I just did) is to validate the cert and change the domain to mail.mayfirst.org.

comment:13 Changed 10 years ago by https://id.mayfirst.org/dkg

Thanks, jamie, for fixing the novalidatecert business. i was just about to open another ticket about that. Sounds like you've done the right thing.

The apache logs (which appear to be line-wrapped in josue's post) show someone attempting to access the orgpv user account in rapid succession from what appears to be two different machines on two different IP addresses.

The first connection seems to be from a Windows machine at IP address 128.122.253.229. The second connection (two minutes later) comes from a Mac OS X computer at IP address 71.255.57.104.

The logout_reason given in the first instance is sessionip, which (according to the horde framework authentication source implies "Logout due to change of IP address during session".

Could it be that there were two people accessing horde/imp for this account at the same time, or that a session was left open on another computer? I don't know the horde framework well enough to know whether it allows multiple concurrent sessions for a single user account. If it doesn't, then a session open one place could easily kick off another user's session elsewhere. Are there two users accessing this account? or does the main user leave themselves logged in on multiple machines?

Some possible (not mutually exclusive) avenues to pursue on this:

  • configure/patch horde to not bind a session to a single IP address. See #185 for reasons why this might be desirable.
  • track down those IP addresses and see if they make sense as far as where the user was connecting from.
  • configure/patch horde to allow multiple sessions for a given user account (i'm not sure this is a good idea)

comment:14 in reply to: ↑ 11 Changed 10 years ago by https://id.mayfirst.org/dkg

Replying to https://id.mayfirst.org/josuepp:

grep orgpv mail.log.3 |grep imapd-ssl|less in viewsic

(cuz i could not get this to work: egrep "imapd-ssl|orgpv")

egrep "imapd-ssl|orgpv" will only match lines that contain either the string imapd-ssl or orgpv (or both!). So you're going to get a lot of imapd-ssl hits that are irrelevant to the orgpv user with that query.

fwiw, i see 80 IMAP connections from stallman to viewsic on behalf of the orgpv user in the 10 minutes after 2008-01-28T20:30-0500:

[0 dkg@viewsic ~]$ zgrep -h orgpv /var/log/mail.log.{6,5,4,3,2,1}.gz | grep imapd | grep '^Jan 28 20:3' | wc -l
78
[0 dkg@viewsic ~]$ 

However, jack noted that she heard about the problem at 2008-01-28T20:28-0500, which is earlier than this time. So i think the pasted logs above are from the wrong time slot. It does look like orgv was using the system from 7:40pm onwards, but not in the previous hour:

[0 dkg@viewsic ~]$ zgrep -h orgpv /var/log/mail.log.{6,5,4,3,2,1}.gz | grep imapd | egrep '^Jan 28 (18|19|20):' | cut -b 1-11 | sort | uniq -c
     40 Jan 28 19:4
     44 Jan 28 19:5
     12 Jan 28 20:0
     36 Jan 28 20:1
     66 Jan 28 20:2
     78 Jan 28 20:3
     38 Jan 28 20:4
    108 Jan 28 20:5
[0 dkg@viewsic ~]$ 

So this gives us a time frame to look in the apache logs: we want to look between 19:40 and 20:28 on 2008-01-28, right?

comment:15 Changed 10 years ago by https://id.mayfirst.org/dkg

Hrm. the apache logs show fewer instances of the username:

0 dkg@stallman:~$ egrep '28/Jan/2008:(18|19|20):' /var/log/apache2/webmail.ssl.access.log | grep orgpv | cut -f4 -d\ | cut -b 2-17 | sort | uniq -c
     11 28/Jan/2008:19:4
      4 28/Jan/2008:20:2
     20 28/Jan/2008:20:3
      4 28/Jan/2008:20:4
     19 28/Jan/2008:20:5
0 dkg@stallman:~$ 

Perhaps that's because the username is only in the the requested URL (or REFERER) during (or immediately after) login.

Combining the IP addresses with the timestamps (ignoring seconds), a pattern of behavior emerges:

0 dkg@stallman:~$ egrep '28/Jan/2008:(18|19|20):' /var/log/apache2/webmail.ssl.access.log | grep orgpv | cut -f1,4 '-d ' | sed 's/:[[:digit:]]*$//' | uniq -c
      6 128.122.253.228 [28/Jan/2008:19:47
      5 128.122.253.229 [28/Jan/2008:19:48
      4 128.122.253.228 [28/Jan/2008:20:28
      4 128.122.253.229 [28/Jan/2008:20:32
     11 71.255.57.104 [28/Jan/2008:20:34
      2 71.255.57.104 [28/Jan/2008:20:35
      1 71.255.57.104 [28/Jan/2008:20:36
      2 71.255.57.104 [28/Jan/2008:20:37
      4 128.122.253.228 [28/Jan/2008:20:40
      4 128.122.253.229 [28/Jan/2008:20:50
      7 128.122.253.196 [28/Jan/2008:20:52
      4 128.122.253.229 [28/Jan/2008:20:54
      4 128.122.253.228 [28/Jan/2008:20:58
0 dkg@stallman:~$ 

Looking up the IP addresses involved, i think i know what happened:

[0 dkg@squeak ~]$ dig +short -x 128.122.253.228 -x 128.122.253.229 -x 71.255.57.104
PROXY1.NYU.EDU.
PROXY4.NYU.EDU.
pool-71-255-57-104.nycmny.east.verizon.net.
[0 dkg@squeak ~]$ 

Here's my working theory:

orgpv connected to the IMP from a computer in an NYU lab, which uses a farm of proxies to connect to the outside. Whether these proxies try to proxy HTTPS via a MITM attack or just pass through the TCP session untampered with, i don't know. Anyway, during the course of the session, the user was suddenly handed off to a different proxy in the farm (either the transition at 19:48 or at 20:28). This switch in apparent source IP address probably caused Horde/IMP to terminate the session. At 20:34, i suspect that Jack, after having been contacted, tried to connect as the user from a totally different machine to verify the problem.

This is probably happening to other users stuck behind proxies as well (note that the user often can't know whether a proxy is in use without significant effort, due to transparent proxying, etc).

comment:16 Changed 10 years ago by https://id.mayfirst.org/dkg

comment:17 Changed 10 years ago by https://id.mayfirst.org/jamie

  • Resolution set to fixed
  • Status changed from new to closed

Wow - your sleuthing skills are amazing dkg! Based on the evidence, I think your theory is dead on.

And the fix is so easy. I just changed:

# $conf['auth']['checkip'] = true;

To:

# $conf['auth']['checkip'] = false;

In /usr/local/share/horde-live/config/conf.php

I feel pretty confident that this is the fix so I'm going to change the status to fixed. Jack: would you mind telling the user that we made a change and ask them to try again the next time they are at NYU? Please re-open if the user reports the same problem.

Thanks Jack, Josue, and dkg for contributing to this fix!!

comment:18 Changed 10 years ago by https://id.mayfirst.org/jackaponte

Thanks Jamie, Josue and dkg! I let Ejeris know about the fix and asked her to let us know what happens next time she's at NYU.

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.