Hi,

I don't know - your fixes don't look valid to me. $url eq '' in
cgi/users/login is also true in my setup, and it works.

Try putting the following code into sub redirect in
perl_lib/EPrints/Repository.pm:

use Data::Dumper;
print STDERR Carp::longmess("redirect to url="" with opts=" .
Dumper(\%opts) ."\n");

...here is what the outputs should look like (it works here without your
fixes):

redirect to url="" class="moz-txt-link-freetext" href="http://elib.localdomain/cgi/users/login?login_check=1">http://elib.localdomain/cgi/users/login?login_check=1}
with opts=$VAR1 = {};

 at /opt/eprints/perl_lib/EPrints/Plugin/Screen/Login.pm line 68

EPrints::Plugin::Screen::Login::finished('EPrints::Plugin::Screen::Login::Internal=HASH(0x7faca988a098)')
called at /opt/eprints/perl_lib/EPrints/Plugin/Screen/Login/Internal.pm
line 119

EPrints::Plugin::Screen::Login::Internal::action_login('EPrints::Plugin::Screen::Login::Internal=HASH(0x7faca988a098)')
called at /opt/eprints/perl_lib/EPrints/Plugin/Screen.pm line 240

EPrints::Plugin::Screen::from('EPrints::Plugin::Screen::Login::Internal=HASH(0x7faca988a098)')
called at /opt/eprints/perl_lib/EPrints/ScreenProcessor.pm line 310
    EPrints::ScreenProcessor::process('EPrints::ScreenProcessor',
'session', 'EPrints::Repository=HASH(0x7faca9aab778)', 'screenid',
'Login::Internal', 'problems', undef) called at
/opt/eprints/perl_lib/EPrints/Apache/Login.pm line 43

EPrints::Apache::Login::handler('Apache2::RequestRec=SCALAR(0x7facad1fc820)')
called at -e line 0
    eval {...} called at -e line 0

redirect to url="" with opts=$VAR1 = {};

 at /opt/eprints/cgi/users/login line 13

ModPerl::ROOT::ModPerl::Registry::opt_eprints_3_2e0_2e5_cgi_users_login::handler('Apache2::RequestRec=SCALAR(0x7faca9a0da58)')
called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
    eval {...} called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204

ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0x7facad24d7e8)')
called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 170

ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0x7facad24d7e8)')
called at /usr/lib/perl5/ModPerl/Registry.pm line 31
    ModPerl::Registry::handler('ModPerl::Registry',
'Apache2::RequestRec=SCALAR(0x7faca9a0da58)') called at -e line 0
    eval {...} called at -e line 0


Here is what the communication after POSTing the login form should look
like (captured with wireshark):

HTTP/1.1 302 Moved
Date: Wed, 05 Mar 2014 14:11:06 GMT
Server: Apache/2.2.16 (Debian)
Set-Cookie:
eprints_session%3Aelib.localdomain=3cfde222c19cc70f4001b82af1caed64;
domain=elib.localdomain; path=/
Location: http://elib.localdomain/cgi/users/login?login_check=1
Content-Length: 0
Keep-Alive: timeout=15, max=96
Connection: Keep-Alive
Content-Type: text/plain

GET /cgi/users/login?login_check=1 HTTP/1.1
Host: elib.localdomain
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:27.0)
Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://elib.localdomain/cgi/users/login
Cookie: eprints_session%3Aelib.localdomain=3cfde222c19cc70f4001b82af1caed64
Connection: keep-alive

HTTP/1.1 302 Moved
Date: Wed, 05 Mar 2014 14:11:06 GMT
Server: Apache/2.2.16 (Debian)
Location: /cgi/users/home
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 237
Keep-Alive: timeout=15, max=95
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

Gilles Fournié wrote:

 Hi,

Thanks for your answer, Jan.

I did not see anything about cookies. I compared with a test version we
were using before (it's a 3.3.11 installed from binaries).
Although the naming of the cookie has changed (in 3.3.12, the name
contains the hostname), it seems that they are correctly set.

I tracked the login process with Data::Dumper and I managed to get the
connection working when using the admin account.

But I had to modify (very lightly) two files.
And as I am very far from being an Eprints expert, I don't like it very
much...

Here are the diffs (testing for empty strings in addition to the
original "defined" test) :

    > diff --git a/cgi/users/login b/cgi/users/login
     my $repo = EPrints->new->current_repository;

     my $url = "" "target" );
    -$url = "" if !defined $url;
    +$url = "" if !defined $url || $url eq '';

     $repo->redirect( $url );


    > diff --git a/perl_lib/EPrints/ScreenProcessor.pm
    b/perl_lib/EPrints/ScreenProcessor.pm
      sub process
            {
                    $opts{screenid} = $opts{session}->param( "screen" );
            }
    -       if( !defined $opts{screenid} )
    +       if( !defined $opts{screenid} || $opts{screenid} eq '' )
            {
                    $opts{screenid} = "FirstTool";
            }

What do you think about that ?
Did this patch hide a bad config on our server ?

Thanks
Gilles


Le 05/03/2014 13:00, Jan Ploski a écrit :

I would start troubleshooting this by looking at Firebug's network panel
and comparing the exchanged request/response sequences during login to a
working configuration, paying particular attention to Host and
Set-Cookie / Cookie headers. My guess is that due to some Apache
misconfiguration (maybe a mismatch in hostname actually used by Apache
and the one EPrints thinks it should use) cookies are not being
exchanged correctly, so that you end up in some "half-logged in" state.

Other than that, you can insert "use Data::Dumper; print STDERR
Carp::longmess(Dumper($variable));" anywhere in the code to output a
stack trace and $variable's content to Apache's log, and trace undefined
values back to where they should be set.

Gilles Fournié wrote:

 Hi,

We are fresh newcomers to the EPrints community (Cirad is a French
research centre working in the field of tropical agronomy, breeding, ...).

The library team has made the choice of EPrints to manage the documents
produced by our research teams.

So, I am trying to install EPrints 3.3.12 on the dedicated server (the
server is still in intranet zone, for now, so I can't post useful links) :

    * CentOS release 6.5 (Final)
      LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarc

    * MySql 5.6.15
    * Perl 5.18.2
    * Apache 2.2.26 with mod_perl 2.0.8

Installation of EPrints seems OK :

    * "epadmin create", to create the test repository + modification of
      httpd.conf
    * import of testdata
    * generate_views
    * "indexer start"

But, I still get errors when running unit_tests...

    * one error on 30_search.pl
    * fails (exists) on 84_sword.pl "1/27 Bailout called.  Further
      testing stopped:  Failed to parse
      http://-----.cirad.fr/sword-app/servicedocument :1: parser error :
      Space required after the Public Identifier"

And on the web interface I run through several problems :

   1. When I try to login with the admin account created during "epadmin
      create", I get a page "Moved" instead of the "Manage deposits"
      page. I have found that another user reported the same problem
      (http://www.eprints.org/tech.php/18174.html) but I didn't find any
      answer to his mail.

      If I go back one page, I return to the home page and I can see
      that the connection has been done. I am identified under the admin
      account...

   2. If I try to edit the user profile through the "Profile" link, I
      get an error : "user does not exist. It may have been erased."

      The url of this page is
      http://-----.cirad.fr/cgi/users/home?screen=Workflow%3A%3AView&dataset=user&dataobj=

      If I tweak this URL, adding "1" at the end, I obtain the profile
      page...

   3. On this profile page, if I click on "Edit", this produce a "500
      Internal Server Error"

      The Apache log has a line related to this error : "Can't call
      method "action_buttons" on an undefined value at
      /opt/www/eprints-3.3.12/perl_lib/EPrints/Plugin/Screen/Workflow/Edit.pm
      line 206."

      Note: if I don't click "Edit" but rather one of the links on field
      titles (as Name or User Type), I get to the edit page
      (http://-----.cirad.fr/cgi/users/home?screen=Workflow%3A%3AEdit&dataset=user&dataobj=1&userid=1&stage=default#name)
      without a problem.

   4. I get the same kind of problems when trying to edit documents.
      From the "Manage deposits" page, I can view documents but not edit
      them : same "500 Internet Server Error" but with a different line
      in the error_log " Can't call method "render" on an undefined
      value at /opt/www/eprints-3.3.12/perl_lib/EPrints/Workflow.pm line
      446.". As for the user editing, if I click on a title link from
      the view page of a document, I correctly reach the edit page.

   5. Last problem. When I try to search the repository
      (http://-----.cirad.fr/cgi/search//simple or advanced), I get a
      redirection error from firefox : "The page isn't redirecting
      properly - Firefox has detected that the server is redirecting the
      request for this address in a way that will never complete"

Has anybody any clue or advices of things I should look at...

With all my apologies for this long message...
Thank you for your assistance.

Gilles

    * Anglais - détecté
    * Anglais
    * Français
    * Espagnol

    * Anglais
    * Français
    * Espagnol

<_javascript_:void(0);>



*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/