This problem was caused by the Sword configuration on the DSpace server. Or, more precisely, the complete lack of configuration of the Sword module. We moved the server from another host last summer, and that must be when the config got overwritten with the defaults. Apparently, no one had tried to publish from Vireo until last week! Once the Sword module was correctly configured, Vireo was able to connect.
On Thursday, January 24, 2019 at 4:30:54 PM UTC-6, librarysy...@gmail.com wrote: > > Further information: > > We seem to have got past "unauthorized credentials." > > Now Vireo says, "Unable to communicate with deposit location: > org.purl.sword.client.SWORDClientException: Received error from service > document request: Code: 400, Message: 'Bad Request' > > Using curl to browse to the Sword servicedocument URL gives this message: > "The requested URL /sword/servicedocument was not found on this server." > > Browsing to the same URL in Internet Explorer gives this message: HTTP > Status 400 – Bad Request > ------------------------------ > > *Type* Status Report > > *Message* Unable to recognise URL as a valid service document: > https://rctest.ourschool.edu/sword/servicedocument > > *Description* The server cannot or will not process the request due to > something that is perceived to be a client error (e.g., malformed request > syntax, invalid request message framing, or deceptive request routing). > ------------------------------ > Apache Tomcat/7.0.90 > - show quoted text - > > On Wednesday, January 23, 2019 at 10:55:26 AM UTC-6, > librarysy...@gmail.com wrote: >> >> We are using Vireo 3.0.6 (with Sword v1) and publishing to a DSpace 6.3 >> repository. Since updating the operating systems on both servers, Vireo >> can’t connect to the DSpace repository to deposit theses and >> dissertations. The DSpace server is running Amazon Linux kernel >> 4.14.88-72.73.amzn1.x86_64, Tomcat 7 and Apache 2.2. At first, the error >> message indicated a certificate error. I replaced the cacerts files and >> the operating system CA files with the ones that existed prior to the >> update. That fixed the certificate error, but now we get “unauthorized >> credentials” when testing the connection. I tested the credentials by >> logging into the DSpace server’s web interface, and they are correct. User >> permissions have not changed, so the deposit user should be authorized. >> >> >> I also tested by browsing to the Sword servicedocument page. The page >> produces a login box. When I enter the credentials, the login box >> disappears, then reappears. I don't know how to interpret this. The >> Tomcat log records 401 errors. >> >> >> I'm out of ideas for troubleshooting, would appreciate any suggestions. >> >> >> Glenn >> > -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
