Installation Issues

[TimHollies]

I've been trying to install Numishare on my institution's (Warwick University) servers and have run into several issues:

Firstly, assets are hard-coded to be served over http when our servers use https. Although we could change the servers it makes sense for numishare to be https as it requires users to log in. I've forked the project and changed every hard-coded http:// to a protocol agnostic version so it'll work correctly regardless. I can submit this as a pull request if that would be helpful.

Secondly, the system was throwing a null pointer exception when we tried to access certain pages. I've tracked this down to line 36 of /xpl/views/pages/index.xpl:

<p:input name="data" href="aggregate('content', #data, #feature-view)"/>

If I remove #feature-view the null pointer exceptions go away. I don't know what #feature-view is for, or why it's a null pointer. Do you have any ideas why this is happening, and how bad is it to just remove it?

Finally I've been having some problems with authentication; I keep getting the Numishare 'Unauthorized User' page when logging in as a numishare-admin user. Orbeon is correctly asking for the username and password and they are correctly being pulled through from tomcat-users.xml - but Numishare is not recognizing the authenticated session. Is any setup required in eXist to be able to log in as a numishare-admin user?

[ewg118]

You should be able to remove the #feature-view from the model, although I am unsure why this would cause a problem. I'd also comment out the two pipelines above this (one that executes a Solr query and the other that transforms this Solr query into a fragment of HTML that is shown on the index page).

I am thinking there might be some issue with the way queries are passed to Solr by parsing the request-uri from the request header in Orbeon. Do you have the log4j set up for Solr? Are there any Solr errors in this log when you attempt to go to the index page?

On the 'http://' issue, The combination of hard coding and parsing the request-uri from the HTTP header of the $include_path URL is an attempt to refer to project-specific CSS files deployed in different Numishare branches checked out onto the server and symlinked into a 'themes' folder in the Orbeon /apps folder. There is essentially one codebase for Numishare (the master branch) checked out onto our server, but we have at least six different Numishare projects with different CSS files and in one case, some different JS files.

[TimHollies]

Hmm.. Solr does have an error org.apache.solr.common.SolrException: undefined field text which it throws when the server is restarted. As far as I can see no new errors are generated when I navigate to the page.

I've solved some of my other issues (which were mostly down to using a slightly too new version of orbeon) and have come across a new one. The site tries to load all assets from http://localhost:8080/orbeon/themes/default/ - which isn't correct (this is using the original, not my https friendly version). Where do I set the URL for the assets to be loaded from?

[ewg118]

The assets URL (particularly the server name portion) is generated from the HTTP request header, which is why I'm pretty confused as to why it is using localhost. I am looking for an alternate solution to this.

Which version of Solr are you using? Is it 4.10?

On Mon, Apr 10, 2017 at 12:43 PM, Tim Hollies notifications@github.com wrote:

Hmm.. Solr does have an error org.apache.solr.common.SolrException: undefined field text which it throws when the server is restarted. As far as I can see no new errors are generated when I navigate to the page.

I've solved some of my other issues (which were mostly down to using a slightly too new version of orbeon) and have come across a new one. The site tries to load all assets from http://localhost:8080/orbeon/ themes/default/ - which isn't correct (this is using the original, not my https friendly version). Where do I set the URL for the assets to be loaded from?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ewg118/numishare/issues/38#issuecomment-293007842, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiX81uXwzLk6BBd_ViuRqaATTeiu-s0ks5rulwsgaJpZM4M29id .

[TimHollies]

I now think it's to do with how the Apache proxy has been set up (which I don't have direct control over, but can request changes to). When I access the public site via 8080 it loads everything correctly, but when I access it via 80 it tries to load things from localhost:8080. I'll have a look into whether it can be fixed by changing the proxy configuration.

And yes, I'm using Solr 4.10.4.

[ewg118]

It could be the Apache config. One of the reasons I implemented the reading of the HTTP request header for the server name and concatenating :8080/orbeon/themes/ is because http://numismatics.org:8080/orbeon/* was always accessible regardless of the Proxypass configuration in Apache. We have six or so Numishare projects running on the same server, so http://numismatics.org/ocre and http://numismatics.org/crro could access the themes folder on their own server. However, the request header registered numismatics.org as the server name, not localhost. So that one is a bit of a mystery to me.

Here's part of our Apache config:

ProxyPass         /ocre/ http://localhost:8080/orbeon/numishare/ocre/
ProxyPassReverse  /ocre/ http://localhost:8080/orbeon/numishare/ocre/

<Location /ocre>
     Order allow,deny
     Allow from all
</Location>
Redirect /ocre http://numismatics.org/ocre/

[TimHollies]

I've managed to get the system working by manually replacing {$include_path} with the server name. It's not ideal to hardcode it - would it possible to add a top level config.xml which specifies these kind of settings? This could also solve the http/https issues.

I'm now having issues with the optional tabs in the Create/Edit Coin view. For example, when 'Digital Representation' is clicked the tab is added to the form, but clicking on it does nothing. There are no JavaScript errors and nothing is logged by either orbeon or tomcat. Do you have any idea what might be happening?

Thanks for your help.

[TimHollies]

I've investigated this issue further, but made no progress in solving it. The tabs 'References', 'Undertype Description', 'Findspot Description' and 'Digital Representations' get added to the form correctly, but do nothing when they are clicked.

I've noticed that when clicking on a non-added tab a request is made to the server which returns some XML containing a <xxf:control-values> element with several <xxf:control> children. When clicking on an added tab the <xxf:control-values> element has no children

I have tried removing all of the content within an added tab and a non-added tab to check if there was anything inside the added tabs that was causing them to fail to load. This had no effect on the problem - so it appears that tab content is not responsible.

The 'inspector' tab displays the current XML representation of the object currently being edited. This appears to show that the XML is being correctly modified when the new tabs are added. E.g. adding the 'References' tab adds the <refDesc /> element to the XML representation.

There's some deprecation warnings on the documentation page about fr:tab - which version of orbeon are you using? I'm using 4.4 at the moment.

[ewg118]

The tab clicking had worked in older versions of Orbeon, but the fr:tab-view has since been deprecated and replaced with an fr:tabbable control. The tab switching should now work, but you'll need to use a version of Orbeon more recent than mid-2015. Orbeon 4.4 is pretty old.

[TimHollies]

I tried a newer version of orbeon before, and found it broke the authentication. I've now updated to 2016.3 and, as before, it appears to not properly populate the 'request-security' object which makes it impossible to log into the admin pages.

I used http://wiki.orbeon.com/forms/doc/developer-guide/authentication to try and understand how it works.

'Auth type' is 'FORM' or 'BASIC' depending on whether I've set up the login pages and 'secure' is always 'false' (regardless of whether the request is made over https). The other fields (principle-user, remote-user and role) are all empty. It worked with orbeon 4.4 - any ideas?

Thanks again, Tim

[ewg118]

I don't have any ideas on authentication in Orbeon 2016.x. I think the latest version I've used with authentication is 4.10.x

[TimHollies]

I've changed the orbeon version to 4.10 but the issue still occurs. It's definitely reading the tomcat users file as the login dialog works correctly - however after authentication it displays the 'unauthorised user' page. I am attempting to log in as numishare-admin which should have access to all projects. Dumping the values out of request-security show that they are not being set.

I came across ewg118/eaditor#30 which sounds like it might be describing a similar issue.

[ewg118]

I am working on testing the newest version of Orbeon, which has some differences in authentication, which may or may not have also applied to Orbeon 4.10. The updated docs are at https://doc.orbeon.com/installation/tomcat.html

[ewg118]

I have tested that authentication works under Orbeon 2016 with some minor changes to the instructions, which I have updated at https://github.com/ewg118/numishare/wiki/Tomcat-Authentication

I will open another issue related specifically to updating link paths for CSS/JS

[grlu]

Hi, the issue is closed, but I would like to follow up on this topic... When I try to load http://servername:8080/orbeon/numishare/ I get the message: The collections-list.xml file does not appear in the eXist-db collection, presumably becaues this is the first time you have run Numishare. Be sure to create the 'numishare-admin' Tomcat role following the instructions on Github. This page will automatically redirect to the admin panel in 10 seconds. If it does not, click here.

While redirect to the admin-panel, I log in with "admin", which has the role "numishare-admin" and after that I get the error: Unauthorized User - Your are seeing this interface either because authentication has not beed enabled for the Numishare administrative panel or there is no matching eXist-db collection for you role. If it is the latter case, please log in as the numishare-admin role and create a new collection for the associated Tomcat role.

I´ve installed orbeon 2018.1 and also tried orbeon 2016.1. Still the same error. Are there any new tips, how to solve this issue?

[ewg118]

I have not yet migrated to 2018.1, but I have authentication working on 2016.1 through 2017.x. This is almost certainly something related to Tomcat authentication or an authentication setting in Orbeon. Have you taken a look at https://github.com/ewg118/numishare/wiki/Tomcat-Authentication#set-roles-in-orbeon-properties ?

[grlu]

Yes, I´ve set the roles in properties-local.xml and also (as a try) in properties-local-prod.xml.

But I´m not really sure about the additional configuration for basic authentiaction https://doc.orbeon.com/installation/tomcat#basic-authentication. Do I need that with tomcat 8.5 or where do I have to set it? I´ve pasted it within the context-element in orbeon.xml in TOMCAT_HOME/conf/Catalina/localhost, because it also contains the context settings, which were set here https://github.com/ewg118/numishare/wiki/Deploying-Orbeon.

[Msch0150]

Maybe this helps: I setup numishare using docker. So, if you have docker installed (on Linux) then you might take a look to:

https://github.com/Msch0150/numishare-docker

Here I am using: Apache 2.4 solr 5.5 tomcat 8 Orbeon 2017.2 eXist 4.0.0 (one of the above is started in a compatibility mode)

You can find my used xml files here:

https://github.com/Msch0150/numishare-docker/tree/master/web

They might get modified by the docker and setup scripts.

Info: there is one issue which appears after creating a new collection. But there is a workaround (see SUMMARY):

https://github.com/ewg118/numishare/issues/58

[ewg118]

Thanks, this should be really useful.

[grlu]

Thanks for your help. Seems to be a good alternative. If I find the time, I'll try it with docker.