Hello,

I am having a problem with logging into to eprints when using it with Shibboleth single sign on and was wondering if someone might have some insight that could help me. I will try to provide as much information as I can.

I believe that the issue itself may not be to do with Shibboleth. I believe I have the Shibboleth side working correctly. Previously before setting eprints up with Shibboleth I was having issues with the standard eprints login. Basically I would sign in with a user and would get redirected back to the home page only without the extra topbar links that would be present after logging in. I never got to the bottom of this issue and decided to try set it up with Shibboleth to try and circumvent to the issue (we need to set it up with Shibboleth anyway).

Another important fact to mention about this setup is that its eprints running inside of a docker container with a base image of Debian Stretch. When a request is sent to the docker host machines port 32772 it is mapped to port 80 in the docker container, which has apache set up with SSL and the appropriate Shibboleth apache config. I have followed the Eprints/Shibboleth wiki to get me this far ( https://wiki.eprints.org/w/Shibboleth ).

So this is what is happening. I go to eprints, click login, get taken to our institutes Shibboleth login page, login with my user credentials, I then get redirected back to eprints (cgi/users/home), but the browser gives an error saying "the page isn't redirecting properly" and that "this problem can sometimes be caused by disabling or refusing to accept cookies".

How I believe it works is that the file zz_shibboleth.pl file ( https://wiki.eprints.org/w/Shibboleth#Configuring_Apache_and_EPrints ) makes eprints use a shibboleth login instead of the local login, the link returned by 'get_login_url' would be MailScanner has detected a possible fraud attempt from "docker_machine:32772" claiming to be https://docker_machine:32772/shibbolth/login. But before I hit this file (archives/ist/shibboleth/login, can also be seen in the link above) I am redirected to our shibboleth page where I sign in, and am then redirected back to the 'shibboleth/login' file. I can see, by adding some logs to this file, that the correct user data is being returned by shibboleth. It then queries the database for that user (which does exist), creates another redirect url ( https://docker_machine:32772/cgi/users/home ), it then seems to create the eprints session cookies by calling:

  $session->dataset( "loginticket" )->create_dataobj({
    userid => $user->id,
  })->set_cookies();

Then it redirects to the url created above. At this point it goes into a redirect loop and the browser stops with the above error.


My initial thoughts was that for some reason the eprints session cookies are not being set correctly and that it is getting caught in this redirect loop because the cookies are not set. So I found the set_cookies sub in perl_lib/EPrints/DataObj/LoginTicket.pm:  https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/DataObj/LoginTicket.pm#L301

When I print the results from 'generate_cookie' and 'generate_secure_cookie' I can see that the application is creating them:

eprints_session%3A=9d9b1398928c13846d9ad0b51c50d099; path=/
secure_eprints_session%3Adocker_machine%3A32772=7ccde4c6b10e333fb5d2896369ec5744; domain=docker_machine:32772; path=/; secure

Whether the application is setting correctly I don't know, I just see them being sent to 'err_headers_out->add' and presume that this works.

So after the browser stops the redirection loop I go back to the home page, I open firebug and have a look at the cookies. I can see that my shibboleth session cookie is set and there also exists an eprints session cookie called 'eprints_session%3A' with some hex value. However for some reason the secure session cookie is not there. It looks kind of strange that the cookies name has %3A at the end. We have another install of eprints running on a bare server, when I look at the cookies from that install I see just 'eprints_session' with not %3A. I have no idea if this has an affect but its information worth sharing.


Can anyone think of what may be happening in this situation? In my head the problem has something to do with the cookies. Am I right in thinking that after the set_cookies sub is called, the session cookies should be set and then on the redirect to '..../cgi/users/home' I should end up on the home page logged in?


Thanks in advance for any help with this situation.

Jonathan
IST Austria