gPodder Bug Tracker – Bug 1509
can not access gpodder.net when password contains / (slash) character
Last modified: 2012-02-28 12:00:47 GMT
If the user password to the gpodder.net account contains a / (slash) character, tapping on My gpodder.net will not start loading the list of subscriptions.
This is because share/ui/qml/Subscribe.qml assembles the data and produces an invalid URI (in the form of http://user:email@example.com/subscriptions/user.xml).
A simple fix seemed to be to use encodeURIComponent() on the password. This lead to a valid URI (the / is replaced by %2F), but something down the Qt stack then does not un-escape the password, leading to "pass%2Fword" (from above example) being sent over the network.
Thank you for your very detailed and helpful bug report.
So, the un-escaping should happen somewhere in the Qt stack? If so, have you reported this as a bug in the Qt bug tracker?
I suspect it should happen in Qt - otherwise there is no way to pass passwords/usernames with URI special characters. I did not submit a bug report to Qt.
(In reply to comment #3)
> I suspect it should happen in Qt - otherwise there is no way to pass
> passwords/usernames with URI special characters. I did not submit a bug report
> to Qt.
Could you do so and link the new bug here? I'm sure that this should be easy to fix on the Qt side. On our side, I think we should just use the escaping so that the URL looks right - and from then, just wait until the fix lands in Qt.
Obviously we could also implement a temporary fix to try to unescape the password and verify it again if the normal verification with the normal password doesn't work out. Stefan - what do you think?
I guess <https://bugreports.qt.nokia.com/browse/QTBUG-19925> is related to this bug.
Bug 1461 seems to be related, although not a duplicate.
(In reply to comment #4)
> Obviously we could also implement a temporary fix to try to unescape the
> password and verify it again if the normal verification with the normal
> password doesn't work out. Stefan - what do you think?
A server side fix would of course be possible, but I'd prefer not to introduce any workarounds in the authentication code unless absolutely necessary. Also this would only solve half of the problem (bug 1461 being to the half).
I'm having a similar issue but don't have a / in my password. I have ^ and ! in there though. Works fine in 2.20 but 3.0.1 doesn't load anything after entering my credentials.
Using Win 7 x64. If there's any debug mode I can run to get more info I'll gladly do it.