Bug 97743 - Impossibility to add certain Wiki accounts in "Tools - Options - Internet - MediaWiki"
Summary: Impossibility to add certain Wiki accounts in "Tools - Options - Internet - M...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.0.4.2 release
Hardware: All All
: medium normal
Assignee: Julien Nabet
URL:
Whiteboard: target:6.0.0 target:5.4.0.1
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-11 12:03 UTC by Thomas Hackert
Modified: 2017-07-25 12:03 UTC (History)
3 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 Thomas Hackert 2016-02-11 12:03:04 UTC
Hello @ll,
after reporting tdf#64397 in the past, I found out, that this option got even worse ... :(

Steps to reproduce:
1. Start LO
2. Go to "Tools - Options - Internet - MediaWiki"
3. Click on "Add..."
4. Enter an URL, your username there and your password
5. Additionally, but it does not matter, mark "Save password"

In the past, I was able to enter https://de.wikipedia.org as URL, with my username and password there, and clicking on OK added this account to LO. Nowadays, I only get an error message:

<quote>
A connection to the MediaWiki system at 'https://de.wikipedia.org/wiki/Wikipedia:Hauptseite' could not be created.
</quote>

... :( If I use www.wikipedia.org (or say http://mein.homelinux.com (where I have no account)), I get the error message

<quote>
A connection to the MediaWiki system at 'https://www.wikipedia.org' could not be created.
</quote>

or

<quote>
A connection to the MediaWiki system at 'http://mein.homelinux.com' could not be created.
</quote>

Tested with LO
Version: 5.0.4.2
Build-ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
Gebietsschema: de-DE (de_DE.UTF-8)

Version: 5.0.5.1
Build-ID: 7609023f63524a6c8326f6c82e7e23f55a5b7bb5
Gebietsschema: de-DE (de_DE.UTF-8)

Version: 5.1.0.3
Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
CPU Threads: 4; OS Version: Linux 4.3; UI Render: default; 
Locale: de-DE (de_DE.UTF-8)

(all three parallel installed, following the instructions from https://wiki.documentfoundation.org/Installing_in_parallel/Linux) on Debian Testing AMD64 w/ de_DE lang- as well as helppack.

If I do this with LO
Version: 5.0.0.5
Build-ID: 437e4abdf9e72fd0a6e6f8697a0e659bc77f9b10
Gebietsschema: de-DE (de_DE.UTF-8)

(also parallel installed) – and I am pretty sure, that this has also worked with earlier LO versions of LO before 5.0.4.2 – it works ...
Sorry for the inconvenience
Thomas.
Comment 1 Cor Nouws 2016-02-11 13:05:33 UTC
Hmm, no fun here either.
In 5.1.0.3 I get a different error (wrong name/pwd whatever).

And funny output on the console:
11-feb-2016 14:00:19 org.apache.commons.httpclient.HttpMethodBase getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
11-feb-2016 14:00:23 org.apache.commons.httpclient.HttpMethodBase getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
com.sun.star.uno.RuntimeException: [jni_uno bridge error] Java calling UNO method hasByName: [map_to_uno():string] null-ref given!
java stack trace:
	at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method)
	at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:185)
	at com.sun.proxy.$Proxy13.hasByName(Unknown Source)
	at com.sun.star.wiki.Helper.AllowUnknownCert(Helper.java:944)
	at com.sun.star.wiki.Helper.ExecuteMethod(Helper.java:662)
	at com.sun.star.wiki.Helper.Login(Helper.java:782)
	at com.sun.star.wiki.WikiEditSettingDialog.DoLogin(WikiEditSettingDialog.java:257)
	at com.sun.star.wiki.WikiEditSettingDialog.access$000(WikiEditSettingDialog.java:35)
	at com.sun.star.wiki.WikiEditSettingDialog$1.run(WikiEditSettingDialog.java:377)

	at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method)
	at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:185)
	at com.sun.proxy.$Proxy13.hasByName(Unknown Source)
	at com.sun.star.wiki.Helper.AllowUnknownCert(Helper.java:944)
	at com.sun.star.wiki.Helper.ExecuteMethod(Helper.java:662)
	at com.sun.star.wiki.Helper.Login(Helper.java:782)
	at com.sun.star.wiki.WikiEditSettingDialog.DoLogin(WikiEditSettingDialog.java:257)
	at com.sun.star.wiki.WikiEditSettingDialog.access$000(WikiEditSettingDialog.java:35)
	at com.sun.star.wiki.WikiEditSettingDialog$1.run(WikiEditSettingDialog.java:377)
Comment 2 Cor Nouws 2016-02-11 13:08:36 UTC
hmm.. trying a different URL does work. Sorry
Comment 3 Thomas Hackert 2016-02-11 14:22:36 UTC
Hello Cor,
(In reply to Cor Nouws from comment #2)
> hmm.. trying a different URL does work. Sorry

thanks for trying :) just out of interest: Which URL does work for you?
Have a nice afternoon
Thomas.
Comment 5 Thomas Hackert 2016-02-11 15:30:51 UTC
(In reply to Cor Nouws from comment #4)
> https://wiki.documentfoundation.org/Main_Page does not
> https://wiki.documentfoundation.org does ...

interesting. The last one still leads to my found bug #64397 ... :(
Thanks for your answer
Thomas.
Comment 6 Buovjaga 2016-02-15 10:01:12 UTC
I was able to add https://fi.wikipedia.org/ just fine. It changed it to: https://fi.wikipedia.org/w/

Win 7 Pro 64-bit, Version: 5.1.0.3 (x64)
Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
Locale: fi-FI (fi_FI)
Comment 7 Thomas Hackert 2016-02-15 10:38:24 UTC
Hello Beluga, *,
(In reply to Beluga from comment #6)
> I was able to add https://fi.wikipedia.org/ just fine. It changed it to:
> https://fi.wikipedia.org/w/
> 
> Win 7 Pro 64-bit, Version: 5.1.0.3 (x64)
> Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
> CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
> Locale: fi-FI (fi_FI)

thanks for testing :) Interestingly enough, I am also able to add the Finnish one, but not the de-de (https://de.wikipedia.org) one ... :( Would you be so kind to test it with it, too?
Thanks in Advance
Thomas.
Comment 8 Buovjaga 2016-02-15 17:52:53 UTC
Reproduced with https://de.wikipedia.org/
Comment 9 Thomas Hackert 2016-02-15 18:27:58 UTC
Hello Beluga, *,
(In reply to Beluga from comment #8)
> Reproduced with https://de.wikipedia.org/

thanks for confirming :) Have a nice evening
Thomas.
Comment 10 QA Administrators 2017-03-06 16:02:27 UTC Comment hidden (obsolete)
Comment 11 Thomas Hackert 2017-03-06 17:05:24 UTC
Hello *,
(In reply to QA Administrators from comment #10)
<snip>
> Test to see if the bug is still present on a currently supported version of
> LibreOffice 
> (5.2.5 or 5.3.0  https://www.libreoffice.org/download/
> 
> If the bug is present, please leave a comment that includes the version of
> LibreOffice and 
> your operating system, and any changes you see in the bug behavior

It is still reproducible with

OS: Debian Testing AMD64
LO: Version: 5.1.6.2
Build-ID: 07ac168c60a517dba0f0d7bc7540f5afa45f0909
CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

LO: Version: 5.2.6.2
Build-ID: a3100ed2409ebf1c212f5048fbe377c281438fdc
CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

LO: Version: 5.3.1.1
Build-ID: 72fee18f394a980128dc111963f2eefb05998eeb
CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; Layout-Engine: neu; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

LO: Version: 5.3.2.0.0+
Build-ID: ae225329435cb49e61e3c9fc76129aa4e334598a
CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; Layout-Engine: neu; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-3, Time: 2017-02-27_23:15:07
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

and

LO: Version: 5.4.0.0.alpha0+
Build-ID: 08750abc64a7ad82cac96adeb7a0bcdce7ac704d
CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-02-28_00:23:27
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

, sorry ... :(

HTH
Thomas.
Comment 12 Julien Nabet 2017-06-10 08:47:32 UTC
Let's give it a try with https://gerrit.libreoffice.org/#/c/38631/
Comment 13 Julien Nabet 2017-06-10 10:19:02 UTC
I should have read comments in detail.
The problem is some websites use w/index.php (wikipedia) other use /index.php (wiki.documentfoundation.org).
Now I just wonder if there's some standard (and tdf wiki should be fixed) or if we should find a way so LO retrieves the right link.
Comment 14 Julien Nabet 2017-06-10 18:14:03 UTC
I gave a new try with a different approach to focus on the retrieving of the right main url.
Comment 15 Commit Notification 2017-06-10 21:03:17 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e34b02834b24be4062ffd535aa1b929481ff427e

tdf#97743: mediawiki account

It will be available in 6.0.0.

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 16 Julien Nabet 2017-06-10 21:08:12 UTC
Just for information, master sources correspond now to 6.0.0 (and not 5.5.0 for marketing reason).
Anyway, if someone could give a try to daily master (see http://dev-builds.libreoffice.org/daily/master/) when patch there'll be some release with patch included.
Comment 17 Commit Notification 2017-06-11 06:48:16 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f283f3a31cff295dbc06af95430f0b26bf2bc9a3&h=libreoffice-5-4

tdf#97743: mediawiki account

It will be available in 5.4.0.1.

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 18 Julien Nabet 2017-06-11 08:10:08 UTC
I'm wondering if it's ok that instead of initial url provided by the user, it's the main url detected which is saved in settings.
I mean if I put "https://fr.wikipedia.org", it saves "https://fr.wikipedia.org/w/"

For "https://wiki.documentfoundation.org/", no pb because main url doesn't contain anything more.

What's expected here?
Comment 19 Dennis Roczek 2017-07-07 16:06:22 UTC
Does anybody have access to an OLD wiki? (something like 1.18; maybe up to 1.21)

I guess the wiki publisher still works with old wikis as nowadays (as explained in the gerrit) is protecting the main page (except for admins, because of spam and vandalism) which will causing this bug.
Comment 20 Thomas Hackert 2017-07-09 09:54:05 UTC
Hello Julien, *,
sorry for the delay, but did not find the time to answer earlier ... :(

(In reply to Julien Nabet from comment #18)
> I'm wondering if it's ok that instead of initial url provided by the user,
> it's the main url detected which is saved in settings.
> I mean if I put "https://fr.wikipedia.org", it saves
> "https://fr.wikipedia.org/w/"

If I use my WP's user name and password and check "Save password", it does not work (leads to the error message which I mentioned in comment 1). If I empty both fields (but with the already entered URL and checked "Save password"), it works ...

> For "https://wiki.documentfoundation.org/", no pb because main url doesn't
> contain anything more.

O.K.

> What's expected here?

No idea, sorry ... :(
Thank you very much for all your work and have a nice Sunday :)
Thomas.
Comment 21 Dennis Roczek 2017-07-17 11:39:50 UTC
(In reply to Julien Nabet from comment #18)
> I'm wondering if it's ok that instead of initial url provided by the user,
> it's the main url detected which is saved in settings.
> I mean if I put "https://fr.wikipedia.org", it saves
> "https://fr.wikipedia.org/w/"
> 
> For "https://wiki.documentfoundation.org/", no pb because main url doesn't
> contain anything more.
> 
> What's expected here?

The path of the index.php is expected here. depending on the configuration of mediawiki this can be lying at sme other places (some use /w/ some wikis do use /wiki/, etc.)

I think that's hard to explain for the user which url to enter there. i guess wee need some detection. :-(
Comment 22 Julien Nabet 2017-07-22 08:43:12 UTC
Dennis: sorry for the delay, I was away from my laptop the 2 last weeks.
I don't understand about detection since it's already done by the fix.
To sum up, according to last comments (from gerrit or bugzilla), I should:
- remove opensearch_desc.php and load.php and put api.php instead for detection
- let LO save the detected path, 
=> as I indicated in comment 18 in first example, if the user typed "https://fr.wikipedia.org", the saved path will be "https://fr.wikipedia.org/w/"
it's already what the fix does.

Is it ok for you or did I miss and/or misunderstand something?
Comment 23 Thomas Hackert 2017-07-23 09:45:04 UTC
Hello Julien, *,
thank you for your work on this bug :) However, it is still not fixed in

OS: Debian Testing AMD64
LO: LO: Version: 5.3.6.0.0+
Build-ID: c967cebeab0d5b343bd33d3a6f758aeaa40258f8
CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; Layout-Engine: neu; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-3, Time: 2017-07-21_05:36:28
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

but in

LO: Version: 5.4.1.0.0+
Build-ID: 6622ea7365fbf1b425e5f90667dd7e6466fd0293
CPU-Threads: 4; Betriebssystem:Linux 4.5; UI-Render: Standard; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-4, Time: 2017-07-21_06:37:51
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

LO: Version: 5.4.0.3
Build-ID: 92c2794a7c181ba4c1c5053618179937228ed1fb
CPU-Threads: 4; Betriebssystem:Linux 4.5; UI-Render: Standard; VCL: gtk2; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

and

LO: Version: 6.0.0.0.alpha0+
Build-ID: e0bafa78e3ad0df397d78cd65ad19bd5b07dc5f2
CPU-Threads: 4; Betriebssystem:Linux 4.5; UI-Render: Standard; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-07-20_22:42:49
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

it is working now :)
Thanks again for your work and have a nice Sunday
Thomas.
Comment 24 Julien Nabet 2017-07-23 11:15:31 UTC
(In reply to thackert from comment #23)
> Hello Julien, *,
> thank you for your work on this bug :) However, it is still not fixed in
> 
> OS: Debian Testing AMD64
> LO: LO: Version: 5.3.6.0.0+
> ...
Hi thackert,

5.3 backport is still on gerrit. Following Dennis' comment, it seems the fix needs some changes. So the goal is first to change it on master, then on 5.4 and finally on 5.3. I described in my previous comment the actions to do to to be sure it's ok for Dennis. If it is, I'll submit a new patch for master to begin.

Since you tested this new version, did it work well on different situations you may have encountered?
What do you think about the fact that url saved on LO may be different from the one typed by the user? (see previous comments) Is it confusing?
Comment 25 Thomas Hackert 2017-07-23 12:13:17 UTC
Hello Julien, *,
(In reply to Julien Nabet from comment #24)
> (In reply to thackert from comment #23)
> > thank you for your work on this bug :) However, it is still not fixed in
> > 
> > OS: Debian Testing AMD64
> > LO: LO: Version: 5.3.6.0.0+
> 
> 5.3 backport is still on gerrit. Following Dennis' comment, it seems the fix
> needs some changes. So the goal is first to change it on master, then on 5.4
> and finally on 5.3. I described in my previous comment the actions to do to
> to be sure it's ok for Dennis. If it is, I'll submit a new patch for master
> to begin.

O.K.

> Since you tested this new version, did it work well on different situations
> you may have encountered?

Which different situations? I tested it with my Wikipedia account for de.wikipedia.org as well as for wikipedia.org and also with my TDF wiki account. I could add all of them without any problem.

> What do you think about the fact that url saved on LO may be different from
> the one typed by the user? (see previous comments) Is it confusing?

Not for me. I am glad that I am able now to add wikipedia as well as wiki.documentfoundation with https to LO ... ;)
Have a nice day
Thomas.
Comment 26 Dennis Roczek 2017-07-25 11:57:56 UTC
(In reply to Julien Nabet from comment #22)
> Dennis: sorry for the delay, I was away from my laptop the 2 last weeks.
> I don't understand about detection since it's already done by the fix.
> To sum up, according to last comments (from gerrit or bugzilla), I should:
> - remove opensearch_desc.php and load.php and put api.php instead for
> detection
> - let LO save the detected path, 
> => as I indicated in comment 18 in first example, if the user typed
> "https://fr.wikipedia.org", the saved path will be
> "https://fr.wikipedia.org/w/"
> it's already what the fix does.
> 
> Is it ok for you or did I miss and/or misunderstand something?

Oh sorry; no. I were a bit confused (neither I hadn't any time to check if the fix works now) and also tried to explain the situation / the background. The api.php is the best. If that is deactivated in the wiki; we also have no possibility to push our changes. ;-)

Feel free to push the change to 5.3 as Thomas already confirmed it working.
Comment 27 Commit Notification 2017-07-25 12:02:44 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c51e789b3a5b77b8bca03c3404699655b19ac80d&h=libreoffice-5-3

tdf#97743: mediawiki account

It will be available in 5.3.6.

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 28 Julien Nabet 2017-07-25 12:03:28 UTC
(In reply to Dennis Roczek from comment #26)
>...
> Oh sorry; no. I were a bit confused (neither I hadn't any time to check if
> the fix works now) and also tried to explain the situation / the background.
> The api.php is the best. If that is deactivated in the wiki; we also have no
> possibility to push our changes. ;-)
> 
> Feel free to push the change to 5.3 as Thomas already confirmed it working.

Thank you for your feedback, I submitted the patch as it was.