Opened at 2011-06-27T11:18:31Z
Closed at 2011-08-08T22:15:39Z
#808 closed defect (worksforme)
Authentication failure in gmail. Pass it's okay
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | BitlBee | Version: | 3.0.3 |
Keywords: | password login failure | Cc: | |
IRC client+version: | irssi 0.8.15 (20100403 1617) | Operating System: | Public server |
OS version/distro: | Archlinux x64 |
Description
I have added a jabber account hosted in jabberes.org and it works okay. The password is a [a-z] pass with no numbers
My gmail account is added correctly: account add jabber nick@… pass account #number set server talk.google.com
And then, for enabling it account #number on
and the output is: <@root> jabber(nick@…) - Logging in: Connecting <@root> jabber(nick@…) - Logging in: Connected to server, logging in <@root> jabber(nick@…) - Logging in: Converting stream to TLS <@root> jabber(nick@…) - Logging in: Connected to server, logging in <@root> jabber(nick@…) - Login error: Authentication failure <@root> jabber(nick@…) - Logging in: Signing off..
My pass is a very complex one with symbols, leters and numbers. I say it, because searching in google i have found an old bug where pass with [a-z][0-9] failed to log in
Some months ago my gmail account had only [a-z] characteres and it logged in without problems
Perhaps it is the same bug?
Attachments (0)
Change History (3)
comment:1 Changed at 2011-07-09T12:38:58Z by
comment:2 Changed at 2011-07-24T12:02:56Z by
Artem: Correct, and that's not specific to passwords but simply BitlBee command-line syntax - similar to any Unix shell. If your passwd contains special chars (like quotes, spaces, backslashes), you need to quote them like on most other command lines.
Original submitter: What kind of characters? Any of the ones mentioned above?
comment:3 Changed at 2011-08-08T22:15:39Z by
Priority: | critical → normal |
---|---|
Resolution: | → worksforme |
Status: | new → closed |
critical? no way
Also, submitter hasn't responded since opening the bug. Nevermind.
After some testing i could only reproduce it with passwords containing either spaces or the '\' character followed by whatever. If that's the case you can escape those characters with additional '\' like this: