Sudden failure to log in: "Page not found"
Permalink
Don't know if this is the right forum or not...there should be a "Maintaining Concrete" category...
Anyway: a client emailed me today that he can't log in. Trying to do so gives him a "Page Not Found" error. I tried it myself, and sure enough:
"Page Not Found
No page could be found at this address."
The URL structure comes out like this:
"http://www.domain_name/index.php/login/-/do_login/"
Does anyone have any insight into this type of error?
(On another matter: since I can't log in, I can't see what version of Concrete this is, and there's nothing in the site.php file or in the Updates folder to tell me. How do I find out?)
Anyway: a client emailed me today that he can't log in. Trying to do so gives him a "Page Not Found" error. I tried it myself, and sure enough:
"Page Not Found
No page could be found at this address."
The URL structure comes out like this:
"http://www.domain_name/index.php/login/-/do_login/"
Does anyone have any insight into this type of error?
(On another matter: since I can't log in, I can't see what version of Concrete this is, and there's nothing in the site.php file or in the Updates folder to tell me. How do I find out?)
The site is still viewable and everything seems to work properly. Just no log in. I don't know what they may have changed, but my contact there says it's been months since he last tried to log in, so this may actually have been an invisible problem for quite some time.
I'm checking through every single folder to make sure there aren't any files missing that are part of the original installation. One thing that has me wondering is "/concrete/controllers/_notes/dwsync.xml", since it specifies the location of login.php:
This isn't part of the original upload, so it must have been created by Concrete. Is there any way this could be incorrect? If I deleted it, would it be re-created? I don't know what it does, and I'm reluctant to test it.
I'm checking through every single folder to make sure there aren't any files missing that are part of the original installation. One thing that has me wondering is "/concrete/controllers/_notes/dwsync.xml", since it specifies the location of login.php:
"<file name="login.php" server="174.34.177.147/public_html/" local="130113707623534823" remote="130113851400000000" Dst="2" />"
This isn't part of the original upload, so it must have been created by Concrete. Is there any way this could be incorrect? If I deleted it, would it be re-created? I don't know what it does, and I'm reluctant to test it.
Interesting, hard to diagnose without access. Ensure the concrete core hasn't been tampered with.
You can determine the version by looking in the Config table on the database.
You can determine the version by looking in the Config table on the database.
Now that I think of it...why am I getting a "Page not found" error? Why not simply a failure message? Obviously, it must be trying to call a file that isn't there...so what file does "login.php" try to call in order to validate a login attempt? If I knew that, I could check to see if the file was missing or corrupted.
I think you might be right. Maybe you can try to sign in using Google Chrome and then when it gives you this error, go to the inspect element and see if it tells you what page it it trying to access. Firefox also has this feature.
-Blenderite
-Blenderite
Hello,
This is a bit odd. Is it possible that they deleted the login page? Do you have a link to the site? It would be a lot easier for me to tell what it going on with the headers.
Can you see the site at all?
Best Wishes,
Mike
This is a bit odd. Is it possible that they deleted the login page? Do you have a link to the site? It would be a lot easier for me to tell what it going on with the headers.
Can you see the site at all?
Best Wishes,
Mike
Hello,
It looks like you have something fishy going on. I guess you know that already. hah. In the header I see this
Somehow it thinks that a constant is a string. Likely because REL_DIR_FILES_TOOLS_REQUIRED wasn't set.
My best guess right now is that there is an error or other strangeness going on in
/config/site.php
I would take a look a that file and look for errors or strange stuff. Especially the define() stuff.
Best Wishes,
Mike
It looks like you have something fishy going on. I guess you know that already. hah. In the header I see this
var CCM_TOOLS_PATH = "REL_DIR_FILES_TOOLS_REQUIRED";
Somehow it thinks that a constant is a string. Likely because REL_DIR_FILES_TOOLS_REQUIRED wasn't set.
My best guess right now is that there is an error or other strangeness going on in
/config/site.php
I would take a look a that file and look for errors or strange stuff. Especially the define() stuff.
Best Wishes,
Mike
Mike--
The site.php file looks normal to me. This is what's there:
The rest of the site works fine, so it must be connecting successfully to the database.
Their server is clogged up with a whole bunch of stuff that's totally unrelated to the website (they host streaming video)...is it possible that something added recently somewhere else on the server could be interfering with the login?
The site.php file looks normal to me. This is what's there:
The rest of the site works fine, so it must be connecting successfully to the database.
Their server is clogged up with a whole bunch of stuff that's totally unrelated to the website (they host streaming video)...is it possible that something added recently somewhere else on the server could be interfering with the login?
Hello,
REL_DIR_FILES_TOOLS_REQUIRED gets defined very early on in the bootstrap process. config/app.php
And it always defines it no matter what. But on your site it is not defined. I see you are running 5.5. Are there core modifications going on? It's just almost impossible to get to a full page load without REL_DIR_FILES_TOOLS_REQUIRED not being defined.
Was this restored from a backup or something similar?
Best Wishes,
Mike
REL_DIR_FILES_TOOLS_REQUIRED gets defined very early on in the bootstrap process. config/app.php
And it always defines it no matter what. But on your site it is not defined. I see you are running 5.5. Are there core modifications going on? It's just almost impossible to get to a full page load without REL_DIR_FILES_TOOLS_REQUIRED not being defined.
define('REL_DIR_FILES_TOOLS_REQUIRED', DIR_REL . '/' . DISPATCHER_FILENAME . '/tools/required'); // front-end
Was this restored from a backup or something similar?
Best Wishes,
Mike
I can only speak for what I've done...no telling at this point (until I ask) what the client may have tried to do.
This site has been up and running for about a year now. No problems at all. This came out of the blue--but, as I mentioned, it may have actually been a problem for quite some time...they just didn't realize it until they tried to log in.
I checked a couple other sites I've done in Concrete, and they have a different line in the header:
...which I take it is the correct one. But that's nothing I've done: Concrete writes that automatically, so long as is present in the header (yes?). So what's causing this corrupted line of javascript? If you know what file it loads from, I could re-upload that and see if everything works again. (On a hunch, I re-uploaded virtually every file in the /concrete/js/ folder, and nothing changed.)
This site has been up and running for about a year now. No problems at all. This came out of the blue--but, as I mentioned, it may have actually been a problem for quite some time...they just didn't realize it until they tried to log in.
I checked a couple other sites I've done in Concrete, and they have a different line in the header:
var CCM_TOOLS_PATH = "/index.php/tools/required";
...which I take it is the correct one. But that's nothing I've done: Concrete writes that automatically, so long as
<?php Loader::element('header_required'); ?>
I know that no ones touched this support request in a while, but I recently ran into this issue, and can tell you what it was in my experience:
1.) I was getting the login page by this address:
http://somewebsite.com/index.php/dashboard/...
and after typing in the information it was redirecting to this:
http://somewebsite.com/login/do_login/...
Thus removing the index.php.
This issue was caused by the pretty urls not working properly. Most likely it did not create the .htaccess file that it needs to turn on pretty urls, or didn't have proper permissions to do so on the server.
in your main directory (outside of the theme, outside of the concrete folder, just the main directory that lists everything) create a .htaccess file and paste in the following:
After pulling this in from one of my other builds, the site was able to reference the correct path. Not sure if this is what is happening with yours, but it may help put you on the right path to correcting it.
1.) I was getting the login page by this address:
http://somewebsite.com/index.php/dashboard/...
and after typing in the information it was redirecting to this:
http://somewebsite.com/login/do_login/...
Thus removing the index.php.
This issue was caused by the pretty urls not working properly. Most likely it did not create the .htaccess file that it needs to turn on pretty urls, or didn't have proper permissions to do so on the server.
in your main directory (outside of the theme, outside of the concrete folder, just the main directory that lists everything) create a .htaccess file and paste in the following:
# -- concrete5 urls start -- <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME}/index.html !-f RewriteCond %{REQUEST_FILENAME}/index.php !-f RewriteRule . index.php [L] </IfModule> # -- concrete5 urls end --
After pulling this in from one of my other builds, the site was able to reference the correct path. Not sure if this is what is happening with yours, but it may help put you on the right path to correcting it.
As for the login page not being found, did you or your client make any changes to the site just before this started? Did some files accidentally get deleted? It sounds like the latter, since it can't find the page. Can you still view your site?
-Blenderite