Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Problem opening a file on a webdav share|
|Product:||[Fedora] Fedora||Reporter:||Nicolas Mailhot <nicolas.mailhot>|
|Component:||openoffice.org||Assignee:||Caolan McNamara <caolanm>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||2.3.0-6.11.fc8||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-01-22 10:42:04 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Nicolas Mailhot 2007-11-15 06:47:14 EST
When double-clicking on an office document in a currently mounted dav share in nautilus, openoffice.org displays a popup asking for identifier and password to access the share. However, only the password field is editable and the identifier can not be inputed. As a result access fails openoffice.org-writer-1:2.3.1-9.1.fc9.x86_64
Comment 1 Caolan McNamara 2007-12-06 06:01:14 EST
Ideally I'd like to know the configuration of your webdav server to reproduce, I assume its apache ?
Comment 2 Caolan McNamara 2007-12-06 06:26:21 EST
setting up my own little apache webdav server with password I get a user name and password dialog from OOo. There are later problems, but I seem to have that dialog functioning anyway.
Comment 3 Nicolas Mailhot 2007-12-06 07:26:50 EST
fedora apache with mod_dav on https
Comment 4 Caolan McNamara 2007-12-07 03:54:24 EST
davs:// then I guess. Hmm I don't get a problem with the identifier/username not being editable, but I do see that it's a total failure afterwards to actually *open* the document as the seeks and stuff are hopeless over dav/davs hidden behind gnome-vfs. If I extend the inbuilt OOo http/https neon stuff to also handle dav/davs then it works well for me, so I reckon I should do that anyway in the next spin. So... if you e.g. right click in nautilus and get the "Location" I assume it says e.g. davs://127.0.0.1/testme . If you then from the command line substitute https:// for davs:// and do e.g. oowriter https://127.0.0.1/testme/atest.odt does it give the authentication dialog, and in a usable form and then go on to successfully open the doc ?
Comment 5 Nicolas Mailhot 2007-12-08 05:25:01 EST
(In reply to comment #4) > davs:// then I guess. > > Hmm I don't get a problem with the identifier/username not being editable, Actually after the fist failure in nautilus identifier/username gets non-editable, but you're right the initial dialog is ok > So... if you e.g. right click in nautilus and get the "Location" I assume it > says e.g. davs://127.0.0.1/testme . If you then from the command line substitute > https:// for davs:// The nautilus properties use davs and specity the port, but I didn't use this on the CLI > and do e.g. oowriter https://127.0.0.1/testme/atest.odt > does it give the authentication dialog, and in a usable form and then go on to > successfully open the doc ? It works if I do oowriter https://... with the URL cut & pasted from firefox (for bonus points I have a document with whitespace in its name, so you need to replace space with %20 and probably do the same for non-ascii characters)
Comment 6 Caolan McNamara 2007-12-08 09:09:11 EST
2.3.1-9.7 *might* resolve these issues by routing the davs:// foo through the OOo webdav backend instead of the gnome-vfs one. Let me know if that has any effect, otherwise it might be something to do with the type of server authentication which I'd then have to try and reproduce here.
Comment 7 Nicolas Mailhot 2007-12-08 10:10:51 EST
2.3.1-9.7 complains of an untrusted certificate issuer without showing any option to authorize the CA
Comment 8 Caolan McNamara 2007-12-08 10:55:19 EST
Looking at gnome-vfs2 I see that it has a total copy of neon in there and one that doesn't support checking certificates at all apparently which is why e.g. gedit doesn't just say roughly the same thing on opening a .txt files on the same webdav export. Gods what a mess to have an embedded neon in gnome-vfs2, we should get rid of that. At least now we're now seeing the same thing, I just had neon hacked to ignore the cert problem on my quick and dirty setup. I can at least *match* the functionality of the gnome-vfs2 solution for now. With the forthcoming gvfs replacement for gnome-vfs2 I don't want to go too far down a complete implementation of all that stuff as it may become totally redundant if we get the reseat of OOo on top of gvfs.
Comment 9 Nicolas Mailhot 2007-12-09 04:15:03 EST
1:2.3.1-9.8 solves the davs problem I must say it's a pleasure to report Fedora OpenOffice.org problems when they get fixed so fast. The package is not 100% clean however, and yum update fails Cleanup : openoffice.org-core ####################### [23/28] rm: ne peut enlever `/usr/lib64/openoffice.org/share/uno_packages/cache/registry': est un répertoire rm: ne peut enlever `/usr/lib64/openoffice.org/share/uno_packages/cache/uno_packages': est un répertoire Cleanup : openoffice.org-langpack-ru ####################### [24/28] error: %postun(openoffice.org-core-2.3.1-9.7.fc9.x86_64) scriptlet failed, exit status 1
Comment 10 Caolan McNamara 2007-12-09 07:23:56 EST
Excellent, well not the silly typo in the post, but at least for getting access to the davs:// stuff
Comment 11 Fedora Update System 2008-01-06 20:19:10 EST
openoffice.org-2.3.0-6.10.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openoffice.org'
Comment 12 Fedora Update System 2008-01-15 18:06:36 EST
openoffice.org-2.3.0-6.11.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openoffice.org'
Comment 13 Fedora Update System 2008-01-22 10:41:58 EST
openoffice.org-2.3.0-6.11.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.