Bug 358934 - Passwords containing colons are not urlencoded properly when adding DAV resources
Summary: Passwords containing colons are not urlencoded properly when adding DAV resou...
Status: RESOLVED FIXED
Alias: None
Product: kaddressbook
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR major
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-03 00:51 UTC by Daniel
Modified: 2016-02-06 23:26 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Dialog with broken encoding (51.64 KB, image/png)
2016-02-03 00:53 UTC, Daniel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel 2016-02-03 00:51:09 UTC
Version 4.14.10 (not an available option in the bug report wizard).

Reproducible: Always

Steps to Reproduce:
1. File: New: Address Book: DAV resource
2. Enter any username, and enter the exact password: "test:pass"
3. Choose configure resource manually
4. Click Add server configuration
5. Type in a responding URL and click Fetch (doesn’t need to be a working server)

Actual Results:  
See screenshot. Password is not urlencoded causing it to break in interesting ways. Ignoring the cosmetically problem, you do get a list of resources from the server. However, the added address book will not be able to sync with KAddressBook and will just be left broken.

Expected Results:  
Password should not be displayed in this dialog. Password should be properly urlencoded.

Causes problems other places too, as even if you ignore this dialog and get a list of resources: KAddressBook will not be able to actually sync against this address book later. (Could be different bug causing the actual sync issue, but I have strong suspicions about this one right here.)
Comment 1 Daniel 2016-02-03 00:53:17 UTC
Created attachment 96992 [details]
Dialog with broken encoding
Comment 2 Grégory Oestreicher 2016-02-06 23:26:33 UTC
Thanks for the report. This has been fixed since as I can't reproduce it with 15.12. I remember addressing the @ in the user name, which may also be the cause here.