Download it now!
Bug 84190 - libcmis: Wrong Password Entered For Alfresco Never Allows For Correction
Summary: libcmis: Wrong Password Entered For Alfresco Never Allows For Correction
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.0.0.3
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-22 15:20 UTC by Dave Richards
Modified: 2016-04-16 07:01 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Richards 2014-09-22 15:20:35 UTC
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.
Comment 1 Julien Nabet 2014-10-21 23:19:43 UTC
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?
Comment 2 Julien Nabet 2014-11-02 00:55:45 UTC
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.
Comment 3 Julien Nabet 2015-01-06 21:47:40 UTC
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)
Comment 4 Caolán McNamara 2015-01-12 12:09:24 UTC
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
Comment 5 Julien Nabet 2015-01-14 10:32:27 UTC
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!?)
Comment 6 Cédric Bosdonnat 2015-01-14 13:39:29 UTC
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
Comment 7 Commit Notification 2015-07-08 06:10:12 UTC
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.
Comment 8 Julien Nabet 2015-07-08 07:30:18 UTC
Cédric: I don't find Szymon Kłos in Bugzilla, do you know what's planned for master branch?
Comment 9 Cédric Bosdonnat 2015-07-08 08:21:15 UTC
(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
Comment 10 Julien Nabet 2015-07-08 08:35:27 UTC
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.
Comment 11 Cédric Bosdonnat 2015-07-08 09:17:15 UTC
Adding Szymon as CC
Comment 12 raal 2016-04-16 07:01:45 UTC
patch committed, closing.