EPrints Technical Mailing List Archive

Message: #08410

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] login-only repository on Debian10

Hi Thomas,
Sorry about the lack of replacing http... as you will tell from the email it was rather late last night by the time I managed to get at list one further level down into you issue.  If you have written a local login plugin, it would be useful to be able to see this.  As this is likely to be where the issue manifests itself, as it is fundamentally different from a standard EPrints repository and even a standard dark/login-only repository.
Sorry, if I have not picked up all the information you have provided along the way.  This has been a rather protracted conversation and as my day job is working on dozens of different EPrints repositories it is difficult to remember exactly what has and has not been said for your particular case.  The URL mangling also makes it difficult to read back through the email change to get back up to speed.
This is clearly a complex issue and not having direct access makes it slow to progress things.  Asking you questions inevitably leads to further questions rather than any useful answers on my part. 

Regards

Davdi Newman

On 18/12/2020 11:17, th.lauke@arcor.de wrote:

CAUTION: This e-mail originated outside the University of Southampton.

Hi David,


I think I have figured out your problem.

no, obviously not :(


This seems to have been reported here:
github.com/eprints/eprints/issues/327

yes, I know ... that's why we use a local 'plugin' following
wiki.eprints.org/w/Tips_to_write_plugins ... :)


On top of making this change, I would advise [to] create the file: ...

following your advice I end up with
[core:error] [pid 1797] [client 172.20.4.237:54751] AH00082: an unknown filter was not added: includes
in apache's log file ... and the same behaviour as before :(

Please replace ptth: by h t t p : / / for the following report:
Starting with the main address ptth:sub.domain.de/ login is requested for on
ptth:sub.domain.de/cgi/users/login?target=http%3A%2F%2Fsub.domain.de%2F
After giving my login credentials I end up on ptth:sub.domain.de/, i.e. an 404 error page, because we have no index.html ... Manual adding to ptth:sub.domain.de/home.html helps finally ;(

When I start the login process with the login link
ptth:sub.domain.de/cgi/users/home the login is presented on ptth:sub.domain.de/cgi/users/login?target=/cgi/users/home
After giving my login credentials I end up on
ptth:sub.domain.de/cgi/users/login?target=%2Fcgi%2Fusers%2Fhome&login_check=1
with the initial uri::_generic error ...
When I insert the hostname address, i.e. using ptth:sub.domain.de/cgi/users/login?target=ptth:sub.domain.de%2Fcgi%2Fusers%2Fhome&login_check=1 instead
I am redirected to ptth:sub.domain.de/cgi/users/home as intended!

As already proposed, I like to focus on the inherent redirection (implemented in Rewrite.pm?), where obviously for some targets the hostname is missing!?


Hope this helps.

maybe a bit, but unfortunately the final goal isn't reached ...

Again:

Does the disabling of mod deflate introduce any harm?
I will check the influence, but what's your opinion?

What next?
Thomas

P.S.: Hopefully the url mangling is once again prevented!?


--
This email has been checked for viruses by AVG.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avg.com%2F&amp;data=04%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7Cf4e28027e74f459f1c6408d8a348457b%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637438878089184546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=omA1N9jACmVT%2BXxcvTgdT2uPaPUr6VU2%2FOQOmR1rGVI%3D&amp;reserved=0