There are two places where if a wrong password is entered when connecting to Alfresco using libcmis that you cannot make a correct easily and this causes problems with user experience. Root cause of this failure is that LO retains your entered account/password for the current session -- even if it's wrong. 1) When you first are making a connection to Alfresco, you are prompted for your account name and password in order to find the "Main Repository". This happens when you hit the refresh symbol and are prompted for your account/password. If you enter the wrong combination it silently fails and the user is never given notice of failure nor given a way to fix it. Work around is to completely close LO and re-open and attempt it again. 2) If you have the Alfresco connection created as a shortcut, and enter the wrong account or password, you get a dialog about a general IO error with no indication of why it's failing. The wrong account or password is held in memory until you close and reopen LO. Proper fix would be for libcmis to report authentication failure and create a dialog to alert user, and then give the user chances to re-enter. This is broken in LO 4.2.X and also in 4.4 (master). Requesting please fix and backport to previous versions.
Cédric: Investigating a bit, it seems there's an exception when running http://opengrok.libreoffice.org/xref/core/ucb/source/ucp/cmis/cmis_repo_content.cxx#182 This one comes from session-factory.cxx SessionFactory::createSession However, I don't know why AuthProvider::authenticationQuery method from auth_provider.cxx asks user/passwd first time and not the other times. Any idea?
Another code pointer: http://opengrok.libreoffice.org/xref/core/ucbhelper/source/provider/simpleauthenticationrequest.cxx#111 If changing ucb::RememberAuthentication_SESSION to ucb::RememberAuthentication_NO + bAllowPersistentStoring = false, the dialog box appears again. 1) I don't know if both changes are mandatory 2) the dialog box always appears even if the login/password is ok. So now, we must find a way to retain the password when ok and to display the dialog box if ko.
Caolan: thought you might have an idea about this one since it concerns a dialog box. I noticed that even when I put the wrong password, executeLoginDialog returns ERRCODE_BUTTON_OK, is it normal? See: http://opengrok.libreoffice.org/xref/core/uui/source/iahndl-authentication.cxx#275 If needed, here's a cmis server for test: https://cmis.alfresco.com/cmisatom http://cmis.alfresco.com/cmisatom username: admin password: admin (from https://www.libreoffice.org/bugzilla/show_bug.cgi?id=72277#c10)
from that dialogs perspective its correct, the user pressed "ok" and not "cancel" so the return looks ok. Somewhere else the password must be rejected by some authentication method silently which is the problem
Thank you Caolan for your feedback. I tried again to investigate but got lost among all these functions: GetCanRememberPassword, GetIsRememberPassword, IsSavePassword, getRememberModes, rPreferredMode, rAlternateMode, Get and SetErrorText etc..... (Couldn't it be a litle less complicated!?)
The problem is more likely to be in the caching of content objects. The corresponding code is in: http://cgit.freedesktop.org/libreoffice/core/tree/ucb/source/ucp/cmis/cmis_provider.cxx
Szymon Kłos committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=050c4f9ceca3046159f7a24d3d5abf8ec4e47fb3&h=libreoffice-5-0 tdf#84190 : when auth fails, don't remember passwords for cmis It will be available in 5.0.0.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Cédric: I don't find Szymon Kłos in Bugzilla, do you know what's planned for master branch?
(In reply to Julien Nabet from comment #8) > Cédric: I don't find Szymon Kłos in Bugzilla, do you know what's planned for > master branch? His patch is sitting in his gsoc branch that will be merged in master before the end of summer: so master is targetted too
I was just astonished that the patch was first in 5.0 branch instead of master branch, thank you for your quick feedback Cédric.
Adding Szymon as CC
patch committed, closing.