<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
Thanks for your help.<br>
<br>
The first log is identical to yours...<br>
<br>
-------------------------------------------------------<br>
redirect to
url={<a class="moz-txt-link-freetext" href="http://eprints-test.cirad.fr/cgi/users/login?login_check=1">http://eprints-test.cirad.fr/cgi/users/login?login_check=1</a>}
with opts=$VAR1 = {};<br>
<br>
at /opt/www/eprints-3.3.12/perl_lib/EPrints/Plugin/Screen/Login.pm
line 68.<br>
<br>
EPrints::Plugin::Screen::Login::finished('EPrints::Plugin::Screen::Login::Internal=HASH(0x688ae08)')
called at
/opt/www/eprints-3.3.12/perl_lib/EPrints/Plugin/Screen/Login/Internal.pm
line 119<br>
<br>
EPrints::Plugin::Screen::Login::Internal::action_login('EPrints::Plugin::Screen::Login::Internal=HASH(0x688ae08)')
called at /opt/www/eprints-3.3.12/perl_lib/EPrints/Plugin/Screen.pm
line 240<br>
<br>
EPrints::Plugin::Screen::from('EPrints::Plugin::Screen::Login::Internal=HASH(0x688ae08)')
called at
/opt/www/eprints-3.3.12/perl_lib/EPrints/ScreenProcessor.pm line 310<br>
<br>
EPrints::ScreenProcessor::process('EPrints::ScreenProcessor',
'session', 'EPrints::Repository=HASH(0x2f47af8)', 'screenid',
'Login::Internal', 'problems', undef) called at
/opt/www/eprints-3.3.12/perl_lib/EPrints/Apache/Login.pm line 43<br>
<br>
EPrints::Apache::Login::handler('Apache2::RequestRec=SCALAR(0x6819770)')
called at -e line 0<br>
eval {...} called at -e line 0<br>
-------------------------------------------------------<br>
<br>
The second one is different from yours.<br>
<br>
First, it shows a bad redirect (I have restored the original
cgi/users/login to run without my "fix"... The $url is empty...)<br>
<br>
I only have 12 lines in my cgi/users/login... Your log says "at line
13"<br>
<br>
-------------------------------------------------------<br>
redirect to url={} with opts=$VAR1 = {};<br>
<br>
at /opt/www/eprints-3.3.12/cgi/users/login line 12.<br>
<br>
ModPerl::ROOT::ModPerl::Registry::opt_www_eprints_2d3_2e3_2e12_cgi_users_login::handler('Apache2::RequestRec=SCALAR(0x6362ed0)')
called at
/opt/perl-5.18.2/lib/site_perl/5.18.2/x86_64-linux/ModPerl/RegistryCooker.pm
line 206<br>
eval {...} called at
/opt/perl-5.18.2/lib/site_perl/5.18.2/x86_64-linux/ModPerl/RegistryCooker.pm
line 206<br>
<br>
ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0x688aca0)')
called at
/opt/perl-5.18.2/lib/site_perl/5.18.2/x86_64-linux/ModPerl/RegistryCooker.pm
line 172<br>
<br>
ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0x688aca0)')
called at
/opt/perl-5.18.2/lib/site_perl/5.18.2/x86_64-linux/ModPerl/Registry.pm
line 31<br>
<br>
ModPerl::Registry::handler('ModPerl::Registry',
'Apache2::RequestRec=SCALAR(0x6362ed0)') called at -e line 0<br>
eval {...} called at -e line 0<br>
-------------------------------------------------------<br>
<br>
I also captured the communication (with HttpFox extension).<br>
<br>
I have a ?target= which doesn't appear in your capture. So I also
tried without this parameter and it makes no difference.<br>
<br>
The result is similar to yours except for the last response header
which doesn't contain any "Location:" :-(<br>
<br>
-------------------------------------------------------<br>
(Status-Line) HTTP/1.1 302 Moved<br>
Date Wed, 05 Mar 2014 16:46:04 GMT<br>
Server Apache<br>
Set-Cookie
eprints_session%3Aeprints-test.cirad.fr=760c61dbf83e67e68a7c982c158f5eaf;
domain=eprints-test.cirad.fr; path=/<br>
Location
<a class="moz-txt-link-freetext" href="http://eprints-test.cirad.fr/cgi/users/login?login_check=1">http://eprints-test.cirad.fr/cgi/users/login?login_check=1</a><br>
Content-Length 0<br>
Keep-Alive timeout=5, max=100<br>
Connection Keep-Alive<br>
Content-Type text/plain<br>
<br>
(Request-Line) GET /cgi/users/login?login_check=1 HTTP/1.1<br>
Host eprints-test.cirad.fr<br>
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101
Firefox/27.0<br>
Accept
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br>
Accept-Language fr-fr,fr;q=0.8,en-us;q=0.5,en;q=0.3<br>
Accept-Encoding gzip, deflate<br>
DNT 1<br>
Referer
<a class="moz-txt-link-freetext" href="http://eprints-test.cirad.fr/cgi/users/login?target=http%3A%2F%2Feprints-test.cirad.fr%2Fcgi%2Fusers%2Fhome">http://eprints-test.cirad.fr/cgi/users/login?target=http%3A%2F%2Feprints-test.cirad.fr%2Fcgi%2Fusers%2Fhome</a><br>
Cookie
eprints_session%3Aeprints-test.cirad.fr=760c61dbf83e67e68a7c982c158f5eaf<br>
Connection keep-alive<br>
<br>
(Status-Line) HTTP/1.1 302 Moved<br>
Date Wed, 05 Mar 2014 16:46:04 GMT<br>
Server Apache<br>
Content-Length 184<br>
Keep-Alive timeout=5, max=99<br>
Connection Keep-Alive<br>
Content-Type text/html; charset=iso-8859-1<br>
-------------------------------------------------------<br>
<br>
Do you have any other clue ?<br>
<br>
Regards,<br>
Gilles<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Le 05/03/2014 15:27, Jan Ploski a
écrit :<br>
</div>
<blockquote cite="mid:5317343E.3030907@plosquare.com" type="cite">
<pre wrap="">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={$url} with opts=" .
Dumper(\%opts) ."\n");
...here is what the outputs should look like (it works here without your
fixes):
redirect to url={<a class="moz-txt-link-freetext" href="http://elib.localdomain/cgi/users/login?login_check=1">http://elib.localdomain/cgi/users/login?login_check=1</a>}
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={/cgi/users/home} 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: <a class="moz-txt-link-freetext" href="http://elib.localdomain/cgi/users/login?login_check=1">http://elib.localdomain/cgi/users/login?login_check=1</a>
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: <a class="moz-txt-link-freetext" href="http://elib.localdomain/cgi/users/login">http://elib.localdomain/cgi/users/login</a>
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:
</pre>
<blockquote type="cite">
<pre wrap=""> 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 = $repo->param( "target" );
-$url = "/cgi/users/home" if !defined $url;
+$url = "/cgi/users/home" 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 :
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap=""> 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
<a class="moz-txt-link-freetext" href="http://-----.cirad.fr/sword-app/servicedocument">http://-----.cirad.fr/sword-app/servicedocument</a> :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
(<a class="moz-txt-link-freetext" href="http://www.eprints.org/tech.php/18174.html">http://www.eprints.org/tech.php/18174.html</a>) 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
<a class="moz-txt-link-freetext" href="http://-----.cirad.fr/cgi/users/home?screen=Workflow%3A%3AView&dataset=user&dataobj=">http://-----.cirad.fr/cgi/users/home?screen=Workflow%3A%3AView&dataset=user&dataobj=</a>
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
(<a class="moz-txt-link-freetext" href="http://-----.cirad.fr/cgi/users/home?screen=Workflow%3A%3AEdit&dataset=user&dataobj=1&userid=1&stage=default#name">http://-----.cirad.fr/cgi/users/home?screen=Workflow%3A%3AEdit&dataset=user&dataobj=1&userid=1&stage=default#name</a>)
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
(<a class="moz-txt-link-freetext" href="http://-----.cirad.fr/cgi/search//simple">http://-----.cirad.fr/cgi/search//simple</a> 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
<a class="moz-txt-link-rfc2396E" href="javascript:void(0);"><javascript:void(0);></a>
*** Options: <a class="moz-txt-link-freetext" href="http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech">http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech</a>
*** Archive: <a class="moz-txt-link-freetext" href="http://www.eprints.org/tech.php/">http://www.eprints.org/tech.php/</a>
*** EPrints community wiki: <a class="moz-txt-link-freetext" href="http://wiki.eprints.org/">http://wiki.eprints.org/</a>
*** EPrints developers Forum: <a class="moz-txt-link-freetext" href="http://forum.eprints.org/">http://forum.eprints.org/</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<div style="bottom: auto; left: 575px; right: auto; top: 386px;
display: none;" class="translator-theme-default"
id="translator-floating-panel">
<div title="Cliquer pour traduire"
id="translator-floating-panel-button"></div>
</div>
</body>
</html>