Hi James,

SameSite was changed to Secure in the secure_eprints_session cookie as part of https://github.com/eprints/eprints3.4/issues/311 which was part of 3.4.5.  This was changed as using SameSite None was considered a security risk.  I think a number of people have had a problem with this particular if they use Shibboleth login.  The advice on the Shibboleth configuration wiki page [1] has been updated advising using a meta refresh in the shibboleth/login script to fix this.  I have not observed this with LDAP login and I do not think a similar approach could be used to fix your issue. 

Your issue would suggest that the repository URLs are possibly flipping between two different hostnames and breaks the SameSIte Strict rule. Alternatively, there could be some flip between HTTP and HTTPS URLs but that feels like that the referrer policy rather than the cookie SameSite setting would cause such a problem in that case.

I would not recommend the header hack in the Apache configuration as a long term solution but it should fix your issue for now.  I would advise getting to the bottom of why this is happening, (partly because I would really like to know what is causing this).  Unfortunately, this is one of the issues that it is very difficult to give advice, as you need to carefully inspect the requests and responses and even then it can take a while to spot where an issue occurs. 

The shibboleth login fix was needed because  the offsite redirect to to perform user authentication caused SameSite strict to drop the cookie just before it tries to load /cgi/users/home, so it thinks it is not logged in so needs to go off to the shibboleth login site to authenticate again and then you get stuck in a loop.  Using the meta refresh ensure the page fully loads with the cookie and the immediately redirects (on the same site), so the cookie does not get dropped.

Regards

David Newman

[1] https://wiki.eprints.org/w/Shibboleth

On 09/07/2024 9:58 pm, James Kerwin wrote:

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

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

Hello!

I think I've found a cause/solution. In the developers log I couldn't see the secure cookie in the list until I included those filtered out then I could see "secure_eprints_session%3Alivrepository.liverpool.ac.uk". The value under the SameSite column was "Strict" whereas that of the equivalent Data Catalogue cookie was "None".

I've so far included this line in my apache config:

Header always edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure

This seems to have resolved it. I'm not sure why the behaviour is different between the repository and data catalogue because there was nothing in the latters apache conf that suggested it would change this behaviour. They are on slightly different point versions of EPrints, but I don't think it's that. There are some other differences between the two more generally.

Thank you both for your help and advice.

Thanks,
James

On Tue, Jul 9, 2024 at 11:18 AM James Kerwin <jkerwin2101@gmail.com> wrote:

Hi John and David,

David I tried the ignore ip config option. While I observed no IP being recorded in the database the problem persisted. Though looking through some of the new config options in this new version of EPrints there are some new, fun and exciting things to try for some new features. Very Exciting!

John, I battled with your suggestion for a bit, but the google sheet opens a new tab when clicking the link. I made a basic webpage containing a suitable link. Observed the problem there also and was able to see a big red X next to the request for the page. The status code is "401 Unauthorized" and the referrer policy is "strict-origin-when-cross-origin". I don't currently know what that means, but it's something to investigate. I'm a bit flummoxed as I used the same apache config from the old server. Though I suppose with a new version of Ubuntu, Apache and EPrints there could be some differences. Not to mention the university beefing up security.

Thanks,

James

On Tue, Jul 9, 2024 at 9:24 AM John Salter <J.Salter@leeds.ac.uk> wrote:

Hi James,
One thing that it might be worth checking is whether there are any unexpected http -> https redirections happening.
The best way to observe these is in the browser developer console – as they are often too quick to see. Look in the ‘Network’ tab when navigating between logged-in and need-to-login pages.

 

I have also observed the issue that David describes. The cases I’ve seen have been often the result of a user being on a mobile broadband connection, and being between radio masts of equal quality. If their connection switches between masts, it normally results in a new IP address – and they then have to log in again.

 

Cheers,

John

 

From: eprints-tech-request@ecs.soton.ac.uk <eprints-tech-request@ecs.soton.ac.uk> On Behalf Of David R Newman
Sent: Wednesday, July 3, 2024 5:30 PM
To: eprints-tech@ecs.soton.ac.uk; James Kerwin <jkerwin2101@gmail.com>
Subject: Re: [EP-tech] Login when opening a new tab

 

CAUTION: External Message. Use caution opening links and attachments.

Hi James,

That is odd.  I think LDAP may be a red herring.  I suspect that there IP may be changing and this will require them to login again.  It is worth checking the loginticket table for the userid of a user with this issue.  If you see lots of loginticket records for them, especially if ordering by time the IP keeps flipping between two or more IP addresses, then that will be your issue.  If that is the case you will need to set the following configuration option:

$c->{ignore_login_ip} = 1;

Where I have used this recently I have put this under the archive's cfg/cfg.d/ directory and called the file zz_ignore_login_ip.pl to ensure it is not overridden.

The reason for caring about the IP address saying the same is historical back in the day when some repositories did not use HTTPS and therefore the best way to make sure someone had not stolen a user session was to ensure the IP address had not changed.  In the next release (3.4.6) or EPrints things have been changed to not enforce the IP address saying the same to maintain a session, as long as HTTPS is enabled:

https://github.com/eprints/eprints3.4/issues/339

Regards

David Newman

 

On 03/07/2024 15:05, James Kerwin wrote:

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

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

Hi everyone,

 

Another question. We're on EPrints 3.4.4 and use LDAP login. Team members pointed out today that whenever they follow a link to a login-only page they need to log in to the repository again in order to view it even if they have only just logged in. If they paste the link in their address bar it typically works.

 

My testing so far suggests any login-only link from the browser requires another login. If I follow it from an Excel/notepad file it lets me view the page.

 

Can anybody nudge me in the right direction for how to start to solve this?

 

Example of a login-only page that I attempt to view:

 

https://livrepository.liverpool.ac.uk/cgi/users/home?screen=EPrint%3A%3AView&eprintid=3180090

 

The page it takes me to:

 

https://livrepository.liverpool.ac.uk/cgi/users/login?target=https%3A%2F%2Flivrepository.liverpool.ac.uk%2Fcgi%2Fusers%2Fhome%3Fscreen%3DEPrint%253A%253AView%26eprintid%3D3180090

 

I have investigated the user-login.pl script that comes with this version of EPrints, but it's very different to the LDAP scrip that I have in a file of the same name.

 

Thanks,

James

*** Options: https://wiki.eprints.org/w/Eprints-tech_Mailing_List

*** Archive: https://www.eprints.org/tech.php/

*** EPrints community wiki: https://wiki.eprints.org/

*** Options: https://wiki.eprints.org/w/Eprints-tech_Mailing_List
*** Archive: https://www.eprints.org/tech.php/
*** EPrints community wiki: https://wiki.eprints.org/