Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#11142 closed defect (fixed)

AIM/ICQ not logging in as of 2010-01-12

Reported by: dburkard Owned by: MarkDoliner
Milestone: 2.7.0 Component: AIM
Version: 2.6.5 Keywords:
Cc: dburkard@…, BMintern, ihitf13anddied, pva, datallah, rayvd, nmx, gagern, stoile, glite, mshancock, jlsddmar, rouilj, pajamian, jsuelwald, jdashton, kentyman, jadefirefly, Dakusan, KnotBigEnuf, javaJake, Leak, breaux, johnalewis, jason237, AndyRazz, ben

Description

Received unexpected response from http://api.oscar.aol.com/aim/startOSCARSession

Attachments (4)

Pidgin_ICQ_fault.pcap (7.7 KB) - added by walter 9 years ago.
purple-debug.log (8.6 KB) - added by DHn82 9 years ago.
Log of failed login attempt
purple-debug.2.log (8.7 KB) - added by javaJake 9 years ago.
"useTLS=1 is not allowed for non secure requests" error log
purple-debug.3.log (5.9 KB) - added by Leak 9 years ago.
Failed connection attempt to ICQ with clientLogon off

Download all attachments as: .zip

Change History (93)

comment:1 follow-up: Changed 9 years ago by BMintern

comment:2 Changed 9 years ago by QuLogic

Ticket #11144 has been marked as a duplicate of this ticket.

comment:3 Changed 9 years ago by QuLogic

Ticket #11145 has been marked as a duplicate of this ticket.

comment:4 Changed 9 years ago by QuLogic

Ticket #11146 has been marked as a duplicate of this ticket.

comment:5 Changed 9 years ago by QuLogic

Ticket #11147 has been marked as a duplicate of this ticket.

comment:6 Changed 9 years ago by QuLogic

Ticket #11148 has been marked as a duplicate of this ticket.

comment:7 in reply to: ↑ 1 ; follow-up: Changed 9 years ago by ihitf13anddied

Replying to BMintern:

See http://ubuntuforums.org/showthread.php?t=1379409&page=1 for a workaround

confirmed workaround in Ubuntu 9.10 Karmic

comment:8 Changed 9 years ago by BMintern

The workaround worked for me in Vista, so it should probably work for any platform.

comment:9 Changed 9 years ago by MarkDoliner

  • Cc pva removed

I'm not sure what the best fix is here. The error AOL is giving us is "useTLS=1 is not allowed for non secure requests." Which is reasonable--we probably shouldn't be requesting a secure session by making a request to http:api.oscar.aol.com/aim/startOSCARSession.

Their documentation (http://dev.aol.com/aim/web/serverapi_reference#startOSCARSession) does list useTLS, but doesn't mention using https. So their documentation doesn't quite jive with this recent change in server behavior.

If I try making the request over https I get the error "<statusCode>401</statusCode><statusText>Authentication Required. statusDetailCode 1014</statusText><statusDetailCode>1014</statusDetailCode>"

More importantly, what's the best fix?

I'm pretty confident we could just make that request over http and get rid of the useTLS=1 parameter and stop looking for their certificate in the response and things would work. But I believe that would allow for a man-in-the-middle attack.

Probably we should make this change to get things working in trunk, and contact AOL to find out what we need to do to use useTLS=1.

comment:10 Changed 9 years ago by MarkDoliner

  • Cc pva added

comment:11 Changed 9 years ago by MarkDoliner

I tried posting here: http://dev.aol.com/forum?c=showthread&ThreadID=1382 I haven't used their forum before... we'll see how it goes.

comment:12 in reply to: ↑ description Changed 9 years ago by deesto

Confirm that toggling the setting 'use clientLogin' from on to off seems to "fix" the problem.

comment:13 in reply to: ↑ 7 Changed 9 years ago by Reslayer

Replying to ihitf13anddied:

Replying to BMintern:

See http://ubuntuforums.org/showthread.php?t=1379409&page=1 for a workaround

confirmed workaround in Ubuntu 9.10 Karmic

Confirmed for Win/2.6.5:AIM.

comment:14 Changed 9 years ago by MarkDoliner

Ticket #11157 has been marked as a duplicate of this ticket.

comment:15 Changed 9 years ago by MarkDoliner

Ticket #11158 has been marked as a duplicate of this ticket.

comment:16 Changed 9 years ago by k8to

This was broken for me on debian when updating TO 2.6.4. I tried updating to 2.6.5 specifically to see if the problem was resolved, before finding this item.

comment:17 Changed 9 years ago by patman0623

Interestingly, I'm having the same problem with only two of my three screennames. My screenname with three words and 11 non-space characters signs on just fine (I'd rather not post it). My other two sn's, which are less than 10 characters, do not sign on. I deleted all the buddies from the one list, so I know it's not a buddy list problem.

comment:18 Changed 9 years ago by Robby

Ticket #11161 has been marked as a duplicate of this ticket.

comment:19 Changed 9 years ago by darkrain42

  • Component changed from unclassified to AIM
  • Owner changed from rekkanoryo to MarkDoliner
  • Summary changed from AOL not logging in with upgrade to 2.6.5 from 2.6.4 to AIM/ICQ not logging in as of 2010-01-12

comment:20 Changed 9 years ago by darkrain42

Ticket #11159 has been marked as a duplicate of this ticket.

comment:21 Changed 9 years ago by darkrain42

Ticket #11152 has been marked as a duplicate of this ticket.

comment:22 Changed 9 years ago by thoughtcrime

confirmed with Arch Linux x86_64, Pidgin 2.6.5

comment:23 Changed 9 years ago by darkrain42

Further confirmations, "me toos", or "CC me" comments are not useful.

Anyone who does want to CC themselves to the ticket can just tick the 'CC me to this ticket' yes box and submit changes without putting in a comment.

Thanks.

comment:24 Changed 9 years ago by Robby

Ticket #11169 has been marked as a duplicate of this ticket.

comment:25 Changed 9 years ago by Robby

Ticket #11167 has been marked as a duplicate of this ticket.

comment:26 Changed 9 years ago by MarkDoliner

Ticket #11177 has been marked as a duplicate of this ticket.

comment:27 Changed 9 years ago by jlsddmar

I've noticed that unchecking 'use clientLogin' does in fact resolve this error, but now the SSL handshake is failing. OTOH, sending my password in the clear isn't really appealing either. Is anyone else seeing this, or has unchecking 'use clientLogin' completely resolved the issue? I'm at 2.6.5.

Is it an AOL issue? openssl s_client -connect slogin.oscar.aol.com:5190 gives me the same failure

comment:28 Changed 9 years ago by jlsddmar

However, consistent with what Mark said, using the -tls1 flag does work

comment:29 Changed 9 years ago by MarkDoliner

jlsddmar: Your password is never sent for AIM accounts. At worst we send in the clear an MD5 hash of your password combined with a token given to us by AOL.

Everything works fine for me when "use ssl" is checked and "use clientlogin" is unchecked. Can you give more detail about the SSL handshake failure you're seeing?

comment:30 follow-up: Changed 9 years ago by jlsddmar

I'm getting the message: "Unable to connect to authentication server: SSL Handshake Failed"

Is there a way to get more verbose connection logging? (Windows)

comment:31 in reply to: ↑ 30 Changed 9 years ago by darkrain42

Replying to jlsddmar:

I'm getting the message: "Unable to connect to authentication server: SSL Handshake Failed"

Is there a way to get more verbose connection logging? (Windows)

The Help->Debug Window. Could you please file a new ticket for this?

comment:32 Changed 9 years ago by darkrain42

Ticket #11185 has been marked as a duplicate of this ticket.

comment:33 Changed 9 years ago by darkrain42

Ticket #11184 has been marked as a duplicate of this ticket.

Changed 9 years ago by walter

comment:34 Changed 9 years ago by darkrain42

Ticket #11189 has been marked as a duplicate of this ticket.

comment:35 Changed 9 years ago by MarkDoliner

Ticket #11194 has been marked as a duplicate of this ticket.

comment:36 Changed 9 years ago by darkrain42

Ticket #11171 has been marked as a duplicate of this ticket.

comment:37 Changed 9 years ago by rekkanoryo

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

For the record, this issue was a server-side bug that has been fixed. Everyone should be able to turn 'Use clientLogin' on again with no ill effects.

Closing this ticket as "worksforme" for lack of a more fitting resolution.

comment:38 follow-up: Changed 9 years ago by DHn82

For what it's worth, I'm still experiencing this problem with Pidgin 2.6.5 as of today. Disabling clientLogin did "solve" the issue.

comment:39 in reply to: ↑ 38 Changed 9 years ago by darkrain42

Replying to DHn82:

For what it's worth, I'm still experiencing this problem with Pidgin 2.6.5 as of today. Disabling clientLogin did "solve" the issue.

Given that this specific issue was solved, please file a new ticket and attach the Help->Debug Window output from logging in with clientLogin enabled.

comment:40 Changed 9 years ago by darkrain42

Oops, apparently it's re-occurring intermittently today.

comment:41 follow-up: Changed 9 years ago by deesto

Yeah, I'd have to disagree that this is _fixed_, as the given fix is to disable one secure connection option, or the other, or both, and there is no one sure-fire direction for getting it working.

comment:42 Changed 9 years ago by jlsddmar

I've also started seeing this issue again, with the same behavior as I had previously seen. In my case, I need to disable both clientLogin and Use SSL in order to successfully connect. I get a SSL handshake error if I use SSL with clientLogin disabled. This was working for me since my previous post. I had captured some trace when I saw it last time, but will take another look at it.

comment:43 in reply to: ↑ 41 Changed 9 years ago by darkrain42

  • Resolution worksforme deleted
  • Status changed from closed to new

Replying to deesto:

Yeah, I'd have to disagree that this is _fixed_, as the given fix is to disable one secure connection option, or the other, or both, and there is no one sure-fire direction for getting it working.

No, the change that broke it was server-side, as was its working again; the issue was simply worked around by disabling either clientLogin or SSL.

Anyway, as I said shortly after I asserted it was no longer happening, I was made aware that it has been occurring intermittently today (although it's intermittent and at least a few people have said that reconnecting worked fine without changing any settings). I'm reopening this (for now).

jlsddmar, if you're unable to connect with just "Use SSL" checked, check the Server and make sure it's set to slogin.oscar.aol.com. If that still doesn't work, please file a new ticket with the Help->Debug Window output.

Changed 9 years ago by DHn82

Log of failed login attempt

comment:44 Changed 9 years ago by darkrain42

Ticket #11327 has been marked as a duplicate of this ticket.

comment:45 Changed 9 years ago by kryptonik

Confirm that the workaround (toggling use clientLogin) fixes bug for Windows 7.

comment:46 Changed 9 years ago by javaJake

I'm also seeing this issue. I normally wouldn't post, but some are claiming it's fixed. I'm not so sure. The "useTLS=1 is not allowed for non secure requests" error is the one I'm seeing. The "clientLogin" checkbox workaround works for me.

I'm attaching a debug log with my AIM name removed.

Changed 9 years ago by javaJake

"useTLS=1 is not allowed for non secure requests" error log

comment:47 Changed 9 years ago by KnightCrusader

I am not sure if this helps, but I am still on 2.6.1 and I never even saw this issue until a friend of mine got a new laptop and installed 2.6.5 on Win7. I had her install 2.6.1 and she is up and running fine without changing any settings.

comment:48 Changed 9 years ago by QuLogic

Ticket #11331 has been marked as a duplicate of this ticket.

comment:49 Changed 9 years ago by darkrain42

Ticket #11337 has been marked as a duplicate of this ticket.

comment:50 Changed 9 years ago by rekkanoryo

In 2.6.1 clientLogin is not enabled by default; this was changed recently. Everyone should be using Pidgin 2.6.5, even if they need to turn off clientLogin to be able to sign into AIM or ICQ.

Changed 9 years ago by Leak

Failed connection attempt to ICQ with clientLogon off

comment:51 in reply to: ↑ description ; follow-up: Changed 9 years ago by Leak

I just encountered this problem with Pidgin 2.6.5 (which happily worked until today), but disabling the "Use clientLogon" setting didn't help. After doing it, the debug window lists "oscar: Username sent, waiting for response" and that was it. Even after 25 minutes now it hasn't progressed any further...

comment:52 Changed 9 years ago by Stevan_White

A little more precisely: I can confirm that the problem doesn't occur in Pidgin 2.6.2 on Scientific Linux 5.4, but it does occur in version 2.6.5.

Didn't try the work-around proposed above, but "Use clientLogin" is enabled in the working 2.6.2 version.

I only noticed this because the latest Ubuntu version is 2.6.2, and it was working.

This is a show-stopper, guys.

comment:53 in reply to: ↑ 51 Changed 9 years ago by Leak

Replying to Leak:

I just encountered this problem with Pidgin 2.6.5 (which happily worked until today), but disabling the "Use clientLogon" setting didn't help. After doing it, the debug window lists "oscar: Username sent, waiting for response" and that was it. Even after 25 minutes now it hasn't progressed any further...

Actually, scratch that - whatever it was that prevented Pidgin from connecting seems to have fixed itself; but it must have been something server-side since I can now also logon again with "Use clientLogon" checked...

comment:54 Changed 9 years ago by MarkDoliner

  • Status changed from new to pending

I'm able to login to AIM and ICQ accounts when both clientLogin and SSL are enabled. Seems like AOL changed something on their side that causes this to stop working, then changed it back so that it works again.

Is anyone still having problems with clientLogin+SSL? If not then I'm going to close this.

comment:55 Changed 9 years ago by javaJake

I used to have issues with clientLogin, but it works now, like you said. Very odd. It's "worksforme" as far as I'm concerned.

comment:56 Changed 9 years ago by DHn82

Works for me currently with clientLogin & SSL enabled, too.

comment:57 Changed 9 years ago by deesto

What platform are you all using? I have to say this still is not working for me, and there is no consistent recipe across platforms. For example: in Windows XP, with no proxy needed, if I choose SSL _or_ clientLogin, Pidgin fails to connect to AIM. Both must be disabled in order to connect. Yet both can be enabled in Fedora 12, unless a proxy is needed, at which point neither can be enabled, etc. I don't get it.

comment:58 Changed 9 years ago by javaJake

I'm running Pidgin v2.6.5 in latest amd64 stable Gentoo Linux.

comment:59 Changed 9 years ago by MarkDoliner

I'm using Pidgin trunk on x86-64 Ubuntu 9.10, but I wouldn't expect that to be too relevant (although whether you're using Cyrus SASL or GNU SASL might).

deesto: Has clientLogin or SSL without clientLogin ever worked for you? Is it possible outgoing SSL connections are blocked? Even clientLogin without SSL uses SSL for the initial authentication.

comment:60 Changed 9 years ago by deesto

MarkDoliner: yes, it used to work fine, though I admit that I had stopped using Pidgin for a year or so when I didn't have a Linux machine. I now use Pidgin in Linux at home (no proxy) and at work (behind a reverse proxy), and both have problems connecting when one or both of these two options are enabled.

comment:61 Changed 9 years ago by deesto

Ah, I should also mention something else regarding the proxy: when I first installed Pidgin and set up my AIM account, I left the proxy setting at the default "use system settings", which pulled in my proxy. When I did this, I found that my connection was being closed and re-opened almost once per minute, which became a bit annoying. So I tried disabling the proxy in my account settings, and I was able to connect fine, and without any more random disconnects. So even though any HTTP requests must be routed through the proxy, it appears that AIM protocol packets are not, so the proxy need not apply in this case.

comment:62 Changed 9 years ago by rekkanoryo

The clientLogin authentication method is brand new and has only been implemented since Pidgin 2.6.0, and only been on by default since either Pidgin 2.6.2 or 2.6.3. The fact that Pidgin worked a year ago is thus irrelevant to this particular problem.

comment:63 follow-up: Changed 9 years ago by deesto

rekkanoryo: INRE: clientLogin; OK, but are you saying SSL connections are also new?

comment:64 in reply to: ↑ 63 Changed 9 years ago by darkrain42

Replying to deesto:

rekkanoryo: INRE: clientLogin; OK, but are you saying SSL connections are also new?

Yes. They were introduced (disabled by default) in the 2.5.5 release (2009-03-01).

comment:65 Changed 9 years ago by rekkanoryo

As darkrain42 said, SSL is new. SSL was not enabled by default until 2.6.2 or 2.6.3 (whichever release made clientLogin default also made SSL default).

comment:66 Changed 9 years ago by Stevan_White

I can confirm that 2.6.5 is now again working, with no changes to the settings.

All on:

Use SSL
Use clientLogin
file transfers
Allow multiple

I think this supports the theory of MarkDoliner that there was some collision between this version of Pidgin and some change on the server side.

comment:67 follow-up: Changed 9 years ago by deesto

Starting to get a bit silly here ... I can counter-confirm that this is not working in a fresh install (as in, just installed a few minutes ago) of Fedora 12 64-bit, which is on a proxied network connection but not going through the proxy for AIM as it's not necessary (as explained earlier). When I leave the settings at default (which includes both SSL and clientLogin being turned on) for adding a new account to a fresh Pidgin install with a fresh OTR plugin install, I get this: "Error requesting https://api.screenname.aol.com/auth/clientLogin: Unable to connect to api.screenname.aol.com: SSL Connection Failed"

If I disable "Use SSL" and reconnect, I get the same error. If I then enable SSL and disable clientLogin, and then reconnect, the connection is made. Again: this is a brand-new install, with no other settings, and the machine is behind a proxy, but the proxy is disabled in the Pidgin settings.

As for SSL and Pidgin: the fact that SSL was not enabled by default in earlier versions does not mean that the SSL option was not available at all, does it? I tend to use SSL whenever possible. I'm not looking to cite a riot here; the two issues just seem orthogonal.

comment:68 Changed 9 years ago by Stevan_White

Maybe not so silly. Something is still fishy.

Shortly after I made the above report (having re-installed 2.6.5), I re-booted my machine for unrelated reasons. When it came up, one of the first apps I started was Pidgin.

The same warning message popped up again!

This time however, the AIM account is working anyway.

comment:69 in reply to: ↑ 67 Changed 9 years ago by darkrain42

Replying to deesto:

Starting to get a bit silly here ... I can counter-confirm that this is not working in a fresh install (as in, just installed a few minutes ago) of Fedora 12 64-bit, which is on a proxied network connection but not going through the proxy for AIM as it's not necessary (as explained earlier). When I leave the settings at default (which includes both SSL and clientLogin being turned on) for adding a new account to a fresh Pidgin install with a fresh OTR plugin install, I get this: "Error requesting https://api.screenname.aol.com/auth/clientLogin: Unable to connect to api.screenname.aol.com: SSL Connection Failed"

If I disable "Use SSL" and reconnect, I get the same error. If I then enable SSL and disable clientLogin, and then reconnect, the connection is made. Again: this is a brand-new install, with no other settings, and the machine is behind a proxy, but the proxy is disabled in the Pidgin settings.

The symptoms you describe are not the ones that this issue is tracking (the error message is different). Please file a new ticket and attach the full Help->Debug Window output of failing to connect to your AIM account.

comment:70 Changed 9 years ago by javaJake

OK, the clientLogin error came back. Disabling clientLogin (keeping SSL on) still works. I retract my "worksforme" report. I'll repost a debug log if so requested.

comment:71 Changed 9 years ago by Stevan_White

The "Received unexpected response" error came back for me too in version 2.6.5.

As explained above, it popped up but AIM continued to work for a while. After a couple of hours though, I seemed to lose AIM (not 100% sure what happened first--the person I was chatting with disappeared, but it may be unrelated). I re-started Pidgin, and now the error won't go away and AIM does not connect.

So I disabled clientLogin.

This results in a very long pause (5 min or so) then an error message: disconnected

Unable to connect to authentication server: SSL Connection Failed

But if I then click on "Reconnect", it seems to connect anyway.

Disabling SSL makes the problem go away. If I then re-enable clientLogin, the problem is still gone.

Since

1) SSL in version 2.6.2 works without problems even now

2) until the above fateful date, 2.6.5 with SSL worked without problems

3) Since then 2.6.5 does not function properly with SSL,

It looks like some change in the AIM server triggers some behavior new to version 2.6.5. Again: SSL was enabled in all cases.

comment:72 follow-ups: Changed 9 years ago by jtoth55

It's annoying that the pidgin developers keep saying this is fixed when it's clearly not. I'm running Pidgin 2.6.5 on Windows 7 x64 and my AIM stopped working 2 days ago. Unchecking "Use Clientlogin" and keeping "Use SSL" checked does NOT work (yes I have the server set to slogin.oscar.aol.com but it gives a SSL handshake error). Doing the opposite ("Use SSL" unchecked and "Use Clientlogin" checked does work.)

comment:73 in reply to: ↑ 72 Changed 9 years ago by Robby

Replying to jtoth55:

It's annoying that the pidgin developers keep saying this is fixed when it's clearly not.[...]

If that's what you're reading, you should take a closer look.

comment:74 Changed 9 years ago by Dakusan

To summarize what has been going on... In early January, when both SSL and ClientLogin? were enabled at the same time for either ICQ or AOL, Pidgin could not connect. This was and is a problem with the AOL servers (possibly an unannounced update to the protocol?). The Pidgin developers tried to contact AOL about it to find out what the problem was, and AFAIK they never received an answer. IIRC, the problem fixed itself after about 4 days. Starting, I believe, within the last week, the problem started occurring again. The problem is intermittent, and often trying to log in multiple times in a row (i.e. 10) will cause a successful login. Starting a few days ago, the problem has changed so that now only having SSL turned on breaks things. Again, AFAIK, this is an AOL server problem, and there's not much the Pidgin developers can do if if it's a bug on the AOL servers or AOL does not let them know about the new protocols.

comment:75 Changed 9 years ago by MarkDoliner

  • Status changed from pending to new

comment:76 in reply to: ↑ 72 Changed 9 years ago by darkrain42

Replying to jtoth55:

It's annoying that the pidgin developers keep saying this is fixed when it's clearly not. I'm running Pidgin 2.6.5 on Windows 7 x64 and my AIM stopped working 2 days ago. Unchecking "Use Clientlogin" and keeping "Use SSL" checked does NOT work (yes I have the server set to slogin.oscar.aol.com but it gives a SSL handshake error). Doing the opposite ("Use SSL" unchecked and "Use Clientlogin" checked does work.)

jtoth55 and Stevan White, please file new tickets for the inability to connect when clientLogin is disabled. Include the Help->Debug Window output.

comment:77 Changed 9 years ago by darkrain42

Pertinent commit (I forgot to Refs this ticket)

Revision: 0e3079d15adeb12c1e57ceaf5bf037f9b71c8abd
Ancestor: 267f28808ab6eeda6b5d68f6433f2b3fcf230d4f
Author: darkrain42@…
Date: 2010-02-18T21:52:18
Branch: im.pidgin.pidgin
URL: http://d.pidgin.im/viewmtn/revision/info/0e3079d15adeb12c1e57ceaf5bf037f9b71c8abd

Modified files:

libpurple/protocols/oscar/clientlogin.c

ChangeLog:

Change clientLogin to use HTTPS, since the hash calculation appears fixed now.

comment:78 Changed 9 years ago by Shridrea

You know, I feel really dumb because I looked for a ticket before I posted my own duplicate. It is Ticket #11413. Sorry about the duplicate.

I literally just updated to the newest version of Pidgin seconds ago, I'm using both Windows XP Professional and Redhat, but both computers give me the following error message:

Received unexpected response from http://api.oscar.aol.com/aim/startOSCARSession: useTLS=1 is not allowed for non secure requests.

I'm not good with computers so I've not attempted to make anything work with it yet. Any ideas on how to get it working again? I've tried all the advice here, and nothing is working for me. . . .

comment:79 Changed 9 years ago by Falkon

Hi,

Today I returned home after 2 weeks, waked up Win XP, started Pidgin 2.6.5 and... useTLS=1 is not allowed for non secure requests.

I thought that it could be done by some attempt to get rid of non-ICQ_client users, what is usually quickly fixed, so i checked Pidgin.cz and downloaded 2.6.6, but problem persisted..

I used CLientLogin workaround - and it works - but I would like to know some better solution, but Darkrains post is beyond my understanding... (What exactly it is, how to install it,...?)

comment:80 Changed 9 years ago by deryni

Ticket #11422 has been marked as a duplicate of this ticket.

comment:81 Changed 9 years ago by HyperHacker

Started having this problem yesterday on Debian. It would tell me I've been disconnecting too frequently and the account was disabled for 10 minutes. Unchecking "Use clientLogin" got it working again.

comment:82 Changed 9 years ago by AndyRazz

Just noting that ticket #10919 is closely related to this one, but precedes it - very similar problem, but with version 2.6.4.

comment:83 Changed 9 years ago by HeadlessCow

As another example of the total randomness of when these settings fail, I sign into two AIM accounts on my machine.

Neither works with SSL and ClientLogin?. One of them (consistently the same one) works with SSL enabled and clientLogin disabled. The other only works if I disable SSL (with or without clientLogin enabled).

comment:84 Changed 9 years ago by ben

Adding me as cc to this ticket.

comment:85 Changed 9 years ago by MarkDoliner

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

darkrain42: That change looks totally correct to me and fixes the problem. Any reason this ticket should stay open?

Recap of the issue:

  • AOL made a change on their servers that caused Pidgin to not be able to sign in with clientLogin+SSL
  • AOL reverted this change on their servers for maybe a week or two
  • AOL again made the change on their servers that caused Pidgin to not be able to sign in with clientLogin+SSL, but this time they also made another change that made it possible to use both clientLogin and SSL.
  • We made the necessary change to our code that fixes clientLogin+SSL. It will be in Pidgin 2.6.6 when it's released. There is currently no release date.

To anyone having issues with SSL but without clientLogin: These issues are unrelated to this ticket. Please file another ticket (or maybe search for an existing one) and include both the error message that you see and the output that is printed to Help->Debug Window during a failed sign on attempt.

comment:86 Changed 9 years ago by Dakusan

Did you mean "2.6.7 when it's released"?

comment:87 Changed 9 years ago by MarkDoliner

  • Milestone changed from 2.6.6 to 2.6.7

Whoops, yes I did.

comment:88 Changed 9 years ago by MarkDoliner

  • Milestone changed from 2.6.7 to 2.7.0

comment:89 Changed 9 years ago by rekkanoryo

Ticket #11545 has been marked as a duplicate of this ticket.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!