Re: [dspace-tech] DSpace 7.6.1: Switch to myDSpace page directly after login?

[Sascha Szott]

Hi Matthias,

we have solved this by adapting one line in

src/app/core/auth/auth.effects.ts

You need to change the implementation of the redirectAfterLoginSuccess$ 
method by replacing


  this.authService.navigateToRedirectUrl(action.payload);

with


  this.authService.navigateToRedirectUrl('/mydspace');


Best regards
Sascha


Am 15.03.24 um 15:51 schrieb Matthias Letsch:

Hello there,

By default, you remain on the homepage when you log in. Is there a 
(simple) way to set that after logging in you are taken directly to the 
myDSpace page with the overview of your own releases?


Thank you and kind regards,
Matthias

--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx 


---
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/9dab0f73-5615-49da-84ac-3ce7fbc21b98n%40googlegroups.com .


--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/e0a98c42-04fc-444d-9659-f5549691764c%40hsu-hh.de.


smime.p7s
Description: Kryptografische S/MIME-Signatur

Re: [dspace-tech] Getting rid of jats-Tags in CrossRef-Import

[Sascha Szott]

Hi,

we've provided a PR in Github to remove JATS tags in CrossRef abstracts:

https://github.com/DSpace/DSpace/pull/9386

Best regards
Sascha


Am 28.02.24 um 18:32 schrieb Sascha Szott:

Hi,

we are facing the same problem in the abstract field of the JSON 
response returned by CrossRef.


I've created a Github issue in the DS CRIS project: 
https://github.com/4Science/DSpace/issues/435


But now I realize that this function is not CRIS specific. Currently, we 
are trying to provide a bug fix by removing the JATS markup.


I'll move the issue (and PR) to the DSpace Github project.

Best regards,
Sascha

Am 28.02.24 um 17:56 schrieb Jarmo Schrader:

Hi Group,

abstracts imported from CrossRef often contain jats-tags (Journal 
Publishing Tag Set). DSpace does not seem to interpret these tags but 
instead shows them as normal text which is ugly an requires manual 
fixing.
Does anyone have an established solution to remove these tags during 
import?
Or is there a way to make DSpace interpret the tags for display so we 
could keep them?


Cheers
Jarmo

--
Dr. Jarmo Schrader
stellv. Bibliotheksleiter
Fachreferat und EDV
Universität Hildesheim
Universitätsbibliothek
Universitätsplatz 1
31141 Hildesheim

Tel: +49 (0) 5121 - 883 - 93004
jarmo.schra...@uni-hildesheim.de

--
All messages to this mailing list should adhere to the Code of 
Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx 
<https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx>

---
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 
<mailto:dspace-tech+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/94025452-9be4-4550-9225-52a81d537dda%40uni-hildesheim.de <https://groups.google.com/d/msgid/dspace-tech/94025452-9be4-4550-9225-52a81d537dda%40uni-hildesheim.de?utm_medium=email_source=footer>.





--
Sascha Szott
Abteilung Forschungsinformation und Publizieren
Universitätsbibliothek
Helmut-Schmidt-Universität
Universität der Bundeswehr Hamburg
Holstenhofweg 85
22043 Hamburg

 +49 171 6433825
 https://ub.hsu-hh.de/

--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/44425c9a-3bd5-4006-be0b-76d6dcecc2d9%40hsu-hh.de.


smime.p7s
Description: Kryptografische S/MIME-Signatur

Re: [dspace-tech] Getting rid of jats-Tags in CrossRef-Import

[Sascha Szott]

Hi,

we are facing the same problem in the abstract field of the JSON 
response returned by CrossRef.


I've created a Github issue in the DS CRIS project: 
https://github.com/4Science/DSpace/issues/435


But now I realize that this function is not CRIS specific. Currently, we 
are trying to provide a bug fix by removing the JATS markup.


I'll move the issue (and PR) to the DSpace Github project.

Best regards,
Sascha

Am 28.02.24 um 17:56 schrieb Jarmo Schrader:

Hi Group,

abstracts imported from CrossRef often contain jats-tags (Journal 
Publishing Tag Set). DSpace does not seem to interpret these tags but 
instead shows them as normal text which is ugly an requires manual fixing.
Does anyone have an established solution to remove these tags during 
import?
Or is there a way to make DSpace interpret the tags for display so we 
could keep them?


Cheers
Jarmo

--
Dr. Jarmo Schrader
stellv. Bibliotheksleiter
Fachreferat und EDV
Universität Hildesheim
Universitätsbibliothek
Universitätsplatz 1
31141 Hildesheim

Tel: +49 (0) 5121 - 883 - 93004
jarmo.schra...@uni-hildesheim.de

--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx 


---
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/94025452-9be4-4550-9225-52a81d537dda%40uni-hildesheim.de .



--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/85038186-d03f-4118-b962-aeae04d9912c%40hsu-hh.de.


smime.p7s
Description: Kryptografische S/MIME-Signatur

Re: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

[Sascha Szott]

Hi Tim,

thanks again for helping out.

I think the key point is that we use a Docker container to run the 
DSpace frontend.


The DS documentation says

"Per the frontend Installation instructions, you must also be running 
your production frontend/UI via either yarn run serve:ssr or yarn start."


but in the Dockerfile provided by DSpace we found

CMD yarn serve --host 0.0.0.0

I have tried to change it to serve:ssr but it doesn't work. 
Unfortunately, I'm not that familiar with nodejs / yarn, but I can 
confirm that SSR is disabled if you run the DSpace frontend in a Docker 
container based on the Dockerfile provided in Github.


Best
Sascha

Am 01.08.23 um 16:36 schrieb DSpace Technical Support:

Hi Sascha,

SSR should always be enabled by default as it is *required* for SEO 
(e.g. Google Scholar will not index your site unless you are using SSR).


DSpace 7 therefore always has SSR enabled, and you'd have to go out of 
your way to disable it (you have to change default code, as it's not 
possible to disable SSR via simple configs).  Nonetheless, if you've 
somehow disabled SSR, then we have a guide in our SEO documentation 
about how to reenable 
SSR: https://wiki.lyrasis.org/display/DSDOC7x/Search+Engine+Optimization#SearchEngineOptimization-Ensuretheuserinterfaceisusingserver-siderendering


Tim

On Tuesday, August 1, 2023 at 7:07:57 AM UTC-5 Sascha Szott wrote:

Hi Karol, Tim,

thanks again.

I think that it is not sufficient to add "anonymousCache" to config.yml
- this setting only affects the configuration of the SSR cache.

Another step is required to enable SSR. Currently I'm looking for a
explanation in the DS documentation.

You can simply check if SSR is enabled on your DSpace site by disabling
JavaScript on your browser. If the site's content is still visible
without JavaScript, it is using SSR. If the site appears blank, it is
not using SSR.

In my case I see a blank page on my local DS instance. In contrast,
https://demo7.dspace.org <https://demo7.dspace.org> is visible
without JavaScript.

Best
Sascha


Am 01.08.23 um 13:59 schrieb Karol:
 > Tim,
 >
 > thank you, now I understand that it is not a "bug" in my
repository, but
 > the way how it works. I have and had Anonymous cache enabled:
 >
 >     anonymousCache:
 >       # Maximum number of pages to cache. Default is zero (0) which
 > means anonymous user cache is disabled.
 >       # As all pages are cached in server memory, increasing this
value
 > will increase memory needs.
 >       # Individual cached pages are usually small (<100KB), so a
value
 > of max=1000 would only require ~100MB of memory.
 >       max: 3000
 >       # Amount of time after which cached pages are considered stale
 > (in ms). After becoming stale, the cached
 >       # copy is automatically refreshed on the next request.
 >       # NOTE: For the anonymous cache, it is recommended to keep
this
 > value low to avoid anonymous users seeing outdated content.
 >       timeToLive: 1 # 10 seconds
 >       # When set to true, after timeToLive expires, the next request
 > will receive the *cached* page & then re-render the page
 >       # behind the scenes to update the cache. This ensures users
 > primarily interact with the cache, but may receive stale pages
(older
 > than timeToLive).
 >       # When set to false, after timeToLive expires, the next
request
 > will wait on SSR to complete & receive a fresh page (which is
then saved
 > to cache).
 >       # This ensures stale pages (older than timeToLive) are never
 > returned from the cache, but some users will wait on SSR.
 >       allowStale: true
 >
 >  but still the occurrences are very high: 50450 daily times
 > metadata-import:401. Probably this is due to bots, or the monitoring
 > system in my IT department (zabbix etc). Perhaps I will install
fail2ban.
 >
 > ps. Sascha, thanks for pointing the way.
 >
 > Greetings,
 >
 > Karo
 >
 > poniedziałek, 31 lipca 2023 o 17:53:39 UTC+2 DSpace Technical
Support
 > napisał(a):
 >
 > Hi Sascha,
 >
 > Yes, the demo site has it's own "ui-demo" branch for the UI at this
 > time: https://github.com/DSpace/dspace-angular/compare/ui-demo
<https://github.com/DSpace/dspace-angular/compare/ui-demo>
 > <https://github.com/DSpace/dspace-angular/compare/ui-demo
<https://github.com/DSpace/dspace-angular/compare/ui-demo>>
 >
 > That said, I'll admit we are currently migrating the demo site to a
 > new platform, and that new platform won'

Re: Prywatna wiadomość na temat: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

[Sascha Szott]

Hi Karol, Tim,

thanks again.

I think that it is not sufficient to add "anonymousCache" to config.yml 
- this setting only affects the configuration of the SSR cache.


Another step is required to enable SSR. Currently I'm looking for a 
explanation in the DS documentation.


You can simply check if SSR is enabled on your DSpace site by disabling 
JavaScript on your browser. If the site's content is still visible 
without JavaScript, it is using SSR. If the site appears blank, it is 
not using SSR.


In my case I see a blank page on my local DS instance. In contrast, 
https://demo7.dspace.org is visible without JavaScript.


Best
Sascha


Am 01.08.23 um 13:59 schrieb Karol:

Tim,

thank you, now I understand that it is not a "bug" in my repository, but 
the way how it works. I have and had Anonymous cache enabled:


     anonymousCache:
       # Maximum number of pages to cache. Default is zero (0) which 
means anonymous user cache is disabled.
       # As all pages are cached in server memory, increasing this value 
will increase memory needs.
       # Individual cached pages are usually small (<100KB), so a value 
of max=1000 would only require ~100MB of memory.

       max: 3000
       # Amount of time after which cached pages are considered stale 
(in ms). After becoming stale, the cached

       # copy is automatically refreshed on the next request.
       # NOTE: For the anonymous cache, it is recommended to keep this 
value low to avoid anonymous users seeing outdated content.

       timeToLive: 1 # 10 seconds
       # When set to true, after timeToLive expires, the next request 
will receive the *cached* page & then re-render the page
       # behind the scenes to update the cache. This ensures users 
primarily interact with the cache, but may receive stale pages (older 
than timeToLive).
       # When set to false, after timeToLive expires, the next request 
will wait on SSR to complete & receive a fresh page (which is then saved 
to cache).
       # This ensures stale pages (older than timeToLive) are never 
returned from the cache, but some users will wait on SSR.

       allowStale: true

  but still the occurrences are very high: 50450 daily times 
metadata-import:401. Probably this is due to bots, or the monitoring 
system in my IT department (zabbix etc). Perhaps I will install fail2ban.


ps. Sascha, thanks for pointing the way.

Greetings,

Karo

poniedziałek, 31 lipca 2023 o 17:53:39 UTC+2 DSpace Technical Support 
napisał(a):


Hi Sascha,

Yes, the demo site has it's own "ui-demo" branch for the UI at this
time: https://github.com/DSpace/dspace-angular/compare/ui-demo
<https://github.com/DSpace/dspace-angular/compare/ui-demo>

That said, I'll admit we are currently migrating the demo site to a
new platform, and that new platform won't use the same GitHub
branch-based setup anymore.  So, this branch unfortunately won't be
a resource for much longer.  The branch already is incomplete
though, as it cannot contain any private information (like the
private application keys used to connect the demo to the ORCID
sandbox or similar).

That said, we might be able to find a different way to simply
document the enabled features on the wiki or similar.

Tim
    On Monday, July 31, 2023 at 10:40:04 AM UTC-5 Sascha Szott wrote:

Hi Tim,

SSR is the missing keyword - thank you! I was not aware of the
fact that
it is enabled.

Is there a place (e.g. branch in Github) where we can see which
frontend
configuration is taken into account to serve the public DSpace demo
instance? It would be helpful in the future to explain such
differences.

Best
Sascha


Am 31.07.23 um 17:28 schrieb DSpace Technical Support:
 > Hi Karol & Sascha,
 >
 > I previously misunderstood when you were seeing these 401
responses.
 >  Seeing them appear occasionally from the User Interface is
*expected
 > behavior*.  What is going on is that the frontend is checking
 > permissions of the current user to see if they are allowed to
 > export/import in order to provide the proper links in the
User Interface
 > if they have access.  If the user is allowed, this request
returns a
 > 200.  If they are not allowed, it returns a 401.  It is
therefore *not*
 > an error, but a permissions check... as a 401 response simply
means you
 > don't have permissions.
 >
 > Simply put, these are safe to ignore.  You *will* sometimes
see the User
 > Interface "ask" the REST API if a user has permissions , or
if a feature
 > is enabled.  The REST API then will sometimes respond with
401 or 404 or
  

Re: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

[Sascha Szott]

Hi Tim,

SSR is the missing keyword - thank you! I was not aware of the fact that 
it is enabled.


Is there a place (e.g. branch in Github) where we can see which frontend 
configuration is taken into account to serve the public DSpace demo 
instance? It would be helpful in the future to explain such differences.


Best
Sascha


Am 31.07.23 um 17:28 schrieb DSpace Technical Support:

Hi Karol & Sascha,

I previously misunderstood when you were seeing these 401 responses.  
  Seeing them appear occasionally from the User Interface is *expected 
behavior*.  What is going on is that the frontend is checking 
permissions of the current user to see if they are allowed to 
export/import in order to provide the proper links in the User Interface 
if they have access.  If the user is allowed, this request returns a 
200.  If they are not allowed, it returns a 401.  It is therefore *not* 
an error, but a permissions check... as a 401 response simply means you 
don't have permissions.


Simply put, these are safe to ignore.  You *will* sometimes see the User 
Interface "ask" the REST API if a user has permissions , or if a feature 
is enabled.  The REST API then will sometimes respond with 401 or 404 or 
similar... this is expected behavior at this time.  (It might be 
possible to reanalyze if there's a different way to achieve this... but 
this is how it works currently. You are welcome to log a bug ticket 
though in our ticketing system if you want: 
https://github.com/DSpace/dspace-angular/issues)


That said, if this is filling up your logs you could use caching to 
ensure the check happens less frequently.


On the demo site, we have anonymous page caching turned on.  This is why 
it's not visible there as frequently (it still may appear occasionally), 
as the pages are cached and this permission check happens /less 
frequently/.  See this guide for how to enable that 
caching: https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)


Hopefully that helps explain what is going on better.  At a second 
glance, I think these are just permissions checks for current users.  
But, turning on caching should decrease their frequency.


Tim
On Saturday, July 29, 2023 at 7:05:20 AM UTC-5 karols...@gmail.com wrote:

Hi Tim, Sascha,

Tim, it looks like my first entry, is not correlated with the 401
error - it's just a coincidence. I don't have any additional
scripts, nor do I see any bots in the logs that are trying to access
this content: /server/api/system/scripts/metadata-import

Sascha, it directed me to conduct tests:

1) I blocked the firewall for everyone opened only for my computer
and started opening the main page of my repository. And to my
surprise, errors started to appear:
*GET /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514
"-" "Mozilla/5.0 (Linux x64) node.js/12.22.12
v8/7.8.279.23-node.57"* and
*GET /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514*
*"-" "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"*
even though I only opened the main repository page in the browser.
Opening a collection, community, item view or anything else does not
cause these errors.

2) I disabled the frontend (angular) left the backend enabled and
the errors stopped appearing, which excludes bots that try to get
into the
/server/api/system/scripts/metadata-import
/server/api/system/scripts/metadata-export

Tim, in summary, I have exactly the same problem as Sascha,
everytime when I opening, refreshing the main page it generating 2
errors :
**
*GET /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514
*
*GET /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514*
**

Comes to my mind, because after migrating from dspace6 to dspace7 I
once carried out the export and import process of collections from
the Administrator - first in simulation mode then in normal mode
everything performed correctly, did you Sascha take such actions?
Maybe something "crashed" in Angular after this action?

Thanks guys,

Karol

piątek, 28 lipca 2023 o 18:44:44 UTC+2 Sascha Szott napisał(a):

Hi Karol,

did you checked the requests to /metadata-import and
/metadata-export
are issued when you access the start page of your DSpace instance?

Currently, we see two 401 requests everytime we open the home
page of
our DSpace instance. We are running DSpace 7.5 / CRIS 2023.01.
We are
not able to reproduce this behaviour in the public DSpace demo
instances.

The backend response is

{
"timestamp": "2023-07-28T16:32:41.705+00:00",
"status": 401,
&qu

Re: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

[Sascha Szott]

Hi Karol,

did you checked the requests to /metadata-import and /metadata-export 
are issued when you access the start page of your DSpace instance?


Currently, we see two 401 requests everytime we open the home page of 
our DSpace instance. We are running DSpace 7.5 / CRIS 2023.01. We are 
not able to reproduce this behaviour in the public DSpace demo instances.


The backend response is

{
"timestamp": "2023-07-28T16:32:41.705+00:00",
"status": 401,
"error": "Unauthorized",
"message": "Authentication is required",
"path": "/server/api/system/scripts/metadata-import"
}

{
"timestamp": "2023-07-28T16:32:41.691+00:00",
"status": 401,
"error": "Unauthorized",
"message": "Authentication is required",
"path": "/server/api/system/scripts/metadata-export"
}

We have no idea how to configure the system properly and disable the 
requests.


Best
Sascha


Am 28.07.23 um 16:56 schrieb DSpace Technical Support:

Hi Karol,

A 401 HTTP code / exception means that the client is unauthorized (not 
authenticated).  So, that large number of logs appears to be someone 
which is attempting to access those REST API endpoints without being 
authenticated.   Perhaps your login timed out while you were trying to 
run an export or import (from either the UI or REST API)?  Or, do you 
maybe have a custom script calling these export/import scripts which is 
failing to authenticate?  It also could be some sort of bot/crawler 
which is trying to crawl your REST API and stumbled on these endpoints.  
  It's really difficult to say for certain where the requests came from 
without more details about what you (or others) might have been doing at 
the time.


These are *not* errors in DSpace though. The 401 HTTP Code just means 
that someone tried to do something in DSpace which required 
authentication, and DSpace stopped them from doing it.


Tim

On Friday, July 28, 2023 at 7:57:07 AM UTC-5 karols...@gmail.com wrote:

Hi,

I'm back with a problem that is causing a large increase in logs. I
have a very large number of queries from my own server (api), I
can't find why this is happening. Can I ask for some guidance on how
to diagnose which process or user is generating these queries?

MyIP- - [28/Jul/2023:14:53:41 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:41 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:43 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:43 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:44 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:44 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:47 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:47 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:51 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:51 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:53 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:53 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:55 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:55 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:56 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-"
"Mozilla/5.0 (Linux x64) 

Re: [dspace-tech] HTTP Status 404 – Not Found when accessing DSpace

[Sascha Szott]

Hi Sushant,

replace /jspui by /server to reach the REST endpoint.

DS7 does not support JSPUI anymore.

Best
Sascha


Am 26.07.23 um 09:28 schrieb Sushant Virdi:

Hello everyone!

I installed DSpace 7.5 on my AWS EC2 instance running tomcat 9. The 
installation went well with no errors as such but now when I try to 
access it through:


*http://SERVER_IP:8080/jspui* I get the error below:

HTTP Status 404 – Not Found


*Type* Status Report

*Message* The requested resource [/jspui] is not available

*Description* The origin server did not find a current representation 
for the target resource or is not willing to disclose that one exists.



Apache Tomcat/9.0.58 (Ubuntu)

I tried searching everywhere but so far not able to figure out what is 
causing this issue. Is there a way to troubleshoot this? Thank you!


--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx 


---
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/4f99b51d-473a-4ed3-99af-14322c6e5471n%40googlegroups.com .


--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/28fbbc06-3834-bbc1-5e2f-649ae4d566d8%40hsu-hh.de.


smime.p7s
Description: S/MIME Cryptographic Signature