Apache OpenOffice (AOO) Bugzilla – Issue 95568
Connection name is garbage when setting up wiki without user/password
Last modified: 2017-05-20 08:57:40 UTC
(I set the priority relative to the MediaWiki publisher extension, but if it should be relative to Open office as a whole then P3) Fresh download today of open office 3, immediately installed wiki publisher. I get the following symptoms: Local Media wiki for our group: Cant connect with no user name and password. Steps to reproduce: 1. Tools>Extensions>Sun Wiki Publisher>Options>Add 2. Enter URL of wiki with a local machine name (http://imos21/wiki, and http://imos21/wiki/index.php/Main_Page, http://imos21.corp.aspentech.com/wiki/index.php/Main_Page all tried) 3. Omit username and password 4. click OK Observed Results: The following server name is added to the ist of available servers (no this is not a cut and paste error!): http://imos21PE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="keywords" content="Main Page,Application Best Practices,Approved EOR Use Cases,Architectural Guidelines,Architecture Team,Audit Table Exclusions,Bookouts,Bug Lifecycle,Build Quirks,Code Library,Coding conventions" /><link rel="shortcut icon" href="/favicon.ico" /> <title>Main Page - IMOSWiki</title> <style type="text/css" media="screen,projection">/*<![CDATA[*/ @import "/wiki/skins/monobook/main.css?7"; /*]]>*/</style> <link rel="stylesheet" type="text/css" media="print" href="/wiki/skins/common/commonPrint.css" /> <!--[if lt IE 5.5000]><style type="text/css">@import "/wiki/skins/monobook/IE50Fixes.css";</style><![endif]--> <!--[if IE 5.5000]><style type="text/css">@import "/wiki/skins/monobook/IE55Fixes.css";</style><![endif]--> <!--[if IE 6]><style type="text/css">@import "/wiki/skins/monobook/IE60Fixes.css";</style><![endif]--> <!--[if IE 7]><style type="text/css">@import "/wiki/skins/monobook/IE70Fixes.css?1";</style><![endif]--> <!--[if lt IE 7]><script type="text/javascript" src="/wiki/skins/common/IEFixes.js"></script> <meta http-equiv="imagetoolbar" content="no" /><![endif]--> <script type="text/javascript">var skin = 'monobook';var stylepath = '/wiki/skins';</script> <script type="text/javascript" src="/wiki/skins/common/wikibits.js"><!-- wikibits js --></script> <script type="text/javascript" src="/wiki/ Expected results: something that looks like a sane server name perhaps? Scenario 2: Wikipedia wiki 1. Tools>Extensions>Sun Wiki Publisher>Options>Add 2. Enter URL of wikipedia (http://en.wikipedia.org/wiki/Main_Page) 3. Omit username and password 4. click OK Observed Result: The following server name is added: http://en.wikipedia.org/w/ Expected result: a URL that is valid on the wikipedia website? Accessing the URL that is stored as the wiki URL causes a 403 forbidden. Not surprisingly, in both scenarios the resulting URL is useless for publishing. Providing a username/password almost always causes the publisher config to complain that "User name or password is incorrect. Please try again or leave the fields blank for an anonymous connection." The only choice is to blank out the username/password (with the results above) or click cancel. I tried this a bunch of times. Just one time when I was providing the fully qualified name for our local server it inexplicably accepted the user name and password and appeared to work. In the config it maintained the correct server URL, but then when I tried to publish a test document it had forgotten the username and password, and resumed complaining about username/password being incorrect. This is the only time things appeared to almost work. Otherwise this extension has been complete DOA :( I am 100% sure that the username and password is correct. I logged into both wikipedia and our local wiki with it to double check, and carefully retyped it several times. Unless it's not respecting what I'm typing in and using a cached value (that it doesn't display) that can't be the problem.
Oh forgot to give the detailed specs... Local Wiki: MediaWiki: 1.6.3 Current Wikipedia: MediaWiki 1.14alpha (r42593) Sun Wiki Publisher 1.0 OpenOffice.org 3.0.0 OOO300m9 (Build:9358)
This is no P1, changing the priority.
I can not reproduce the problem exactly in the same way as it is described in the issue. But I get problems while storing to Wikipedia, and they seems to have the same reason. It looks to be a result of the new MediaWiki release that has changed the format of the generated html pages. The extension has to be switched to the new MediaWiki API that looks to be stable now.
First of all, the issue describes three different problems that is definitely not a good practice. 1) Impossibility to get access to own wiki ( garbled wiki system path ) 2) Impossibility to export to Wikipedia 3) Impossibility to use the URL used to identify the wiki system in browser Please see my comments to all the mentioned problems below referred by the problem number. 1) So now this bug is only about the problem with the users own wiki. 2) A new issue 99196 is opened to cover this problem. 3) The URL from Wikipedia is not garbled, it is a unique identifier that specifies the path to the index.php file. It is shown so by intention, since the user enters an arbitrary URL from the wiki server and we have to get the unique identifier of the wiki system ( theoretically a server might contain more than one wiki system ). I see currently no other general way to identify a wiki system. The URL was till now never intended to be used in browser. I am not sure that this possibility worses the efforts. Anyway, if you believe that you need it, please write a new enhancement request to me.
mav->fsparv_at: Could you please do the following: - please enter the URL you have mentioned in a webbrowser ( http://imos21.corp.aspentech.com/wiki/index.php/Main_Page for example ). - get the sources of the page ( In Firefox it can be retrieved using "View\Page Source" menu entry ) - attach a text file containing the sources to this issue ( if the sources are not confidential ) That would allow to investigate the original scenario.
The wiki page parsing is improved. Unfortunately there is no possibility to test the original scenario, I need at least the sources of the main page as I have mentioned in the previous comment. I hope that the improving solves the mentioned here problem as well. I am setting the issue to fixed for now.
Setting the issue to verified by myself since there is no possibility to verify it on our side without answer from submitter.
Sorry I haven't been responding. First off the page is confidential. Sorry. I don't know if I'll have time for sure, but I'll try to test against our wiki sometime this week. What's the best way to get the code that has your fix?
In the following please understand that I ask to understand not to criticize. Your efforts are greatly appreciated. I just read the first comment from 2/13 and I don't understand how http://en.wikipedia.org/w/ identifies the index page of the wiki... what is the "w/" part? how is that useful to the user? is it shorthand If the value shown had been http://en.wikipedia.org/ or http://en.wikipedia.org/wiki/ your comment would seem to make sense. As for practice, it was my intent that the issue be about the single issue of the URL not being stored properly. The various symptoms all seem to point back to that problem. In both cases the root of the URL (the machine name portion) is followed by additional text (web page contents in one case and "/w/" in another). The message about logging in seemed logical given that if one tries to log in at http://en.wikipedia.org/w/ there is no log in screen (just 403) and log in fails. Similarly posting to a misidentified wiki would also cause a problem. Theoretically I could have supplied only one example, but I knew that one of my examples was dramatic, but not reproducible by you. The other was far less dramatic, but produced on a system you had access to. I specifically suspected that the issue would be related to the parsing of the input URL since the dramatic failure occured in the case where the URL had a less common format (machine name with no '.' character, which is a legal URL, but only useful on a local network, or when a hosts file specifies the machine. So in my mind this was about one issue that has multiple symptoms. If the URL storage/display were fixed and one or both the scenarios still didn't work that would definitely mean that a second or third issue had been uncovered. Your comment about url not intended for the browser doesn't make much sense to me either. If it's an internal value not understandable to the user (such as the /w/ being your internal shorthand for /wiki/MainPage perhaps?) and not corresponding to anything the user can know, why is it shown? A value that is user intelligible/useful should be substituted for display purposes.
mav->fsparv_at: The fixed version of the extension can be found attached to issue 96279. Please remember that the baseline for the extension has been changed, it requires now at least OOo3.0. The URL 'http://en.wikipedia.org/w/' is a unique identifier specifying the path to index.php, as I already have mentioned. Please read http://www.mediawiki.org/wiki/Manual:Short_URL for more information. Using of such identifier has nothing to do with the problems 1 and 2 mentioned in my comment from 13.02. This bug is only about problem 1 mentioned in my comment from 13.02. If you still has the problem using the new extension, please write it here. The problem 2 should be discussed in issue 99196 If you believe that the 3 problem mentioned by you has to be fixed write a new issue to me. Please do not mix multiple issues together.