Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the CollectiveAccess support forum! Here the developers and community answer questions related to use of the software. Please include the following information in every new issue posted here:

  1. Version of the software that is used, along with browser and version

  2. If the issue pertains to Providence, Pawtucket or both

  3. What steps you’ve taken to try to resolve the issue

  4. Screenshots demonstrating the issue

  5. The relevant sections of your installation profile or configuration including the codes and settings defined for your local elements.


If your question pertains to data import or export, please also include:

  1. Data sample

  2. Your mapping


Answers may be delayed for posts that do not include sufficient information.

First login failure

edited November 1 in Troubleshooting
I have just completed a successful installation of Providence 1.7.5.  But when I come to login, the URL gets rewritten and I get a 404 error message.

There were a few warnings about permissioning during the installation but I fixed all the reported ones. The process ended by giving me an administrator id and password to use.


You can see I am using a local webserver, listening on port 8000.  It is NGINX and obviously works, because I did the installation through it.


This fails with the 404 message.  Not sure why the rewrite is happening.  Any help would be appreciated.

Update 1st Nov17:  No real progress after several hours.  I've changed the port so that the IP doesn't require qualification, but no change.  Tried changing ownership of the entire file structure to www-data, which NGINX runs under, but no change.  Have stepped through the code, and established that it falls over when index.php reaches the yellow-highlighted point.  But as a newbie, I don't know whether the rewrite is correct or not.  Please help before I go totally mad.

if (!preg_match("/^[\/]{0,1}system\/auth\/(dologin|login|forgot|requestpassword|initreset|doreset)/", strtolower($req->getPathInfo()))) {
$vb_auth_success = $req->doAuthentication(array('noPublicUsers' => true));
if(!$vb_auth_success) {
$resp->sendResponse();
$req->close();
exit;
}
}

Comments

  • Post your setup.php file please? I'd bet you have a path wrong in there.
  • edited November 1
    imageSetup is attached.  I've changed the suffix from PHP to TXT so that it will upload.  I've not changed any path settings from the initial distribution.
  • Ok nothing in that files looks wrong. Is there anything in the log? If you go directly to this URL ( http://192.168.1.218:8000/index.php/system/auth/login) what happens?
  • edited November 2
    I've made some useful progress, but not enough to claim it is solved!

    The 404 errors arose because my NGINX config was not set up for the URL structures used in Collective Access, namely <site><php script>/xxx/yyy/zzz.  Some other posts on this wiki have helped me get an NGINX config that now gets me to the logon screen.

    Great, I thought. But...

    I supply the correct credentials but now it always bounces back to the logon screen (no error message).  If I deliberately supply incorrect credentials, the Login was invalid message is displayed.  So I can conclude the correct credentials ARE being accepted.

    Here is the NGINX access log as the login screen opens:

    192.168.1.202 - - [02/Nov/2017:12:08:48 +0000] "GET / HTTP/1.1" 302 16 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"
    192.168.1.218 - - [02/Nov/2017:12:08:48 +0000] "GET /index.php?processIndexingQueue=1 HTTP/1.1" 499 0 "-" "-"
    192.168.1.202 - - [02/Nov/2017:12:08:48 +0000] "GET /index.php/system/auth/login?redirect=http%3A%2F%2F192.168.1.218%2Findex.php%2FDashboard%2FIndex HTTP/1.1" 200 1737 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (K$

    And here is the log after the credentials are supplied:

    192.168.1.202 - - [02/Nov/2017:12:11:06 +0000] "POST /index.php/system/Auth/DoLogin HTTP/1.1" 302 5 "http://192.168.1.218/index.php/system/auth/login?redirect=http://192.168.1.218/index.php/Dashboard/Index" "Mozilla/5.0 (Win$
    192.168.1.202 - - [02/Nov/2017:12:11:06 +0000] "GET /index.php/Dashboard/Index HTTP/1.1" 302 16 "http://192.168.1.218/index.php/system/auth/login?redirect=http://192.168.1.218/index.php/Dashboard/Index" "Mozilla/5.0 (Windows$
    192.168.1.218 - - [02/Nov/2017:12:11:06 +0000] "GET /index.php?processIndexingQueue=1 HTTP/1.1" 499 0 "-" "-"
    192.168.1.202 - - [02/Nov/2017:12:11:06 +0000] "GET /index.php/system/auth/login?redirect=http%3A%2F%2F192.168.1.218%2Findex.php%2FDashboard%2FIndex HTTP/1.1" 200 1737 "http://192.168.1.218/index.php/system/auth/login?redirect=http:%2$

    I acknowledge that NGINX is not explicitly supported but, given that its market share now matches Apache's, I want to persevere with it.  I find NGINX is easier to manage when you have many websites on the same server.

    Here's the config file if anyone can comment:

    server {
           server_name 192.168.1.218;
           listen 80;
           listen [::]:80;
           root /home/shawmat/data/providence;

           if ($http_host != "192.168.1.218") {
                     rewrite ^ 192.168.1.218$request_uri permanent;
           }

           index index.php index.html;

           location = /favicon.ico {
                    log_not_found off;
                    access_log off;
           }

           location = /robots.txt {
                    allow all;
                    log_not_found off;
                    access_log off;
           }

           # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
           location ~ /\. {
                    deny all;
                    access_log off;
                    log_not_found off;
           }

           location / {
                try_files $uri @rewrite;
            }

            location @rewrite {
                rewrite ^ /index.php;
            }

            location ~ /media/(.+)\.php$ {
                    deny all;
            }

           # Add trailing slash to */wp-admin requests.
           location ~*  \.(css|gif|jpg|png|js|woff|ttf|swf)$ {
                    expires max;
                    log_not_found off;
           }

          location ~ \.php$ {
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_index    index.php;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_intercept_errors on;
            fastcgi_pass localhost:9000;
        }
    }


  • I'll try to make time to install nginx on one of our machines and see what the issue is. I agree with you that nginx should be supported.
  • It turns out that NGINX may not be the cause.  I've now installed Apache 2.4 and disabled NGINX - and the problem of login bouncing back still happens.  So the good news is that my original NGINX config script may be good to use.  The bad news is that I now need to look elsewhere to fix the symptoms.

    Once again, if anyone can help me with debugging this situation I'll be very gratetful.
  • Finally. I got the login to work.  This note summarises my learnings in case it's useful to others, and in no way guarantees that I won't hit further problems!

    The original problems stemmed from using NGINX rather than Apache for the installation. Login kept bouncing back to the login screen. Even after switching to Apache, the same symptoms occurred.  Before that, I had had to deal with a URL pattern that I hadn't seen before, and you can see in an earlier post the config which appears to resolve that.

    Today I decided to fully re-install using Apache - and login now works.  Additionally, I made sure that Linux user www-data was a member of the account doing the install from the outset, so I got no access warnings (unlike previously).

    It's probably something quite easy to fix CA for NGINX to be supported.  NGINX is my production environment so would ideally like to get it working.  But at least I can now move forward.

Sign In or Register to comment.