History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: IDEA-14897
Type: Bug Bug
Status: Open Open
Assignee: Dmitry Jemerov
Reporter: Marco Götze
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
IDEA: Feedback

IDEA keeps prompting for credentials on Linux

Created: 12 Sep 07 14:54   Updated: 20 Sep 07 14:59
Component/s: Version Control Integration. Subversion

Environment: Linux (up-to-date Gentoo, but that should not matter), Sun JDK 1.6.0_02, both x86 and x86_64 systems and JDKs

Build: 7,274
Severity: High


 Description  « Hide
Subversion server interaction is broken for me on Linux. Whenever I do something that requires the SVN integration to talk to the server (update, commit), I'm prompted for my credentials. Once I've done so, the dialog immediately re-appears (with its title suggesting that authentication has failed). It does not matter whether or not I check "Save credentials", and the credentials I do enter are definitely correct.

The only way to get out of the credentials request loop is to hit "Cancel", which then leads to an "Error: svn: authentication cancelled" message (as expected).

The (remote) SVN server in question is v1.2.0. The upgrade option in IDEA's SVN configuration has been set to "Upgrade automatically". I've tried using both the system default and a custom Subversion configuration directory, and I've also removed Subversion's default ("~/.subversion") configuration directory to rule out its contents as a cause.

SVN access works as expected with the very same work directory on the command line (using a v1.4.4 client). The work directory is in v1.4 format, I believe (".svn/format" says "8").



 All   Comments   Work Log   Change History      Sort Order:
Marco Götze - 13 Sep 07 11:38
In case this matters, authentication-wise, I'm using user/password-based authentication, i.e., an svn:// URL.

Marco Götze - 20 Sep 07 14:19
Persists with build 7291.

Marco Götze - 20 Sep 07 14:59
I've apparently found a work-around (build 7291): While entering a password directly into the password input field results in an authentication failure, inserting it from the clipboard (via [Ctrl]-[V]) works. Consequently, the issue seems to have to do with the password input field as such. In case this matters, the password in question consists of Latin letters, digits, and an @ character.