Open ianwallen opened 1 year ago
I would like confirmation that http://localhost:8080/geonetwork?uuid=e3b63ab5-c277-4dd8-8cff-ee78555bd809
is a good "absolute" reference for the record (it appears much more so than a search#
result :)
I'm not sure if the following is a good email address for redirection as it loses any language specific information from the url and will revert back to the default language.
http://localhost:8080/geonetwork?uuid=e3b63ab5-c277-4dd8-8cff-ee78555bd809
So I found another url that may work - I tried to go to http://localhost:8080/geonetwork/srv/eng/catalog.search?uuid=e3b63ab5-c277-4dd8-8cff-ee78555bd809 http://localhost:8080/geonetwork/srv/fre/catalog.search?uuid=e3b63ab5-c277-4dd8-8cff-ee78555bd809
and it redirected to
Which then redirected to
Geonetwork 3.12.x has the following code
<rule>
<note>
Redirects to hash with metadata
Example URL: http://localhost:8080/geonetwork?uuid=da165110-88fd-11da-a88f-000d939bc5d8
</note>
<from>^/(.*)/catalog.search\?.*uuid=(.*)</from>
<to type="permanent-redirect">%{context-path}/#/metadata/$2</to>
</rule>
It was implemented in the following PR https://github.com/geonetwork/core-geonetwork/pull/6139
I’m guessing that if we change this so that the redirect does not lose the language then it may work? Maybe something like this? (Not tested)
We would need to do some testing.
In 4, we also change link in email to have it consistent in all places in https://github.com/geonetwork/core-geonetwork/pull/6792/files pointing to the landing page ie. srv/api/records/uuid (but this is not the JS app).
@fxprunayre Based on the PR that you mentioned, the following urls seem to somewhat work for me on GN 3.12. They properly redirect to and English and French page.
http://localhost:8080/geonetwork/srv/api/records/e3b63ab5-c277-4dd8-8cff-ee78555bd809?language=eng http://localhost:8080/geonetwork/srv/api/records/e3b63ab5-c277-4dd8-8cff-ee78555bd809?language=fre
But the viewer is not correct and buggy It has a link to login at the top of the page even though I'm logged in already via keycloak.
It seems to be using skin.xls for the display.
And the footer does not seem to check if footer is enabled - we have it disabled but it still shows the footer.
Are these bugs?
Are these bugs?
Here indeed https://github.com/geonetwork/core-geonetwork/blob/main/web/src/main/webapp/xslt/skin/default/skin.xsl#L55-L63 this does not check session status and UI configuration. So something to improve.
Is there anywheres in the code where we use xsl to parse the ui configuratrion settings? The display that is being called seems to be the nojs version so we are no able to use Angular to get the values.
Or maybe it is possible to change it to use a js version like the search page? I'm not sure I understand why a nojs version is used?
Is there anywheres in the code where we use xsl to parse the ui configuratrion settings?
Check XslUtil#getUiConfigurationJsonProperty
but one issue can be that no setting is in the database - but usually when it is, it will configure non default options.
I'm not sure I understand why a nojs version is used?
It was done for SEO purpose for landing page mainly.
Describe the bug The link within the approver email does not work if using external authentication.
To Reproduce
Expected behavior Expecting the link to work as intended.
Desktop (please complete the following information):
Additional context The issue is that the redirect email tries to go to a url similar to the following http://localhost:8080/geonetwork/srv/eng/catalog.search#/metadata/e3b63ab5-c277-4dd8-8cff-ee78555bd809 But as the user is not logged in the authentication will redirect the user to the oauth application (i.e. keycloak). The redirect will not contain the anchor "#/metadata/e3b63ab5-c277-4dd8-8cff-ee78555bd809" because the redirect is generated from the server and is not available - it is only available to the browser. The browser will detect that the redirect is to a different host so it will not include the anchor. So after the login the user goes to http://localhost:8080/geonetwork/srv/eng/catalog.search which is not the intended location.
Suggesting that the link get changed to the following http://localhost:8080/geonetwork?uuid=e3b63ab5-c277-4dd8-8cff-ee78555bd809 Which should fix the issue.
Note that this issue may apply in other links applied to the catalogue - I'm not sure where all occurrences may be? Also this issue is also affecting users bookmarking the urls to metadata records for the same issue. The only time the books marks wil work is when the user is already logged in.