I have a VM that I set up to do development on two sites hosted on Acquia with the same codebase. I'm using version Drupal 7.26. I have it where I can access both sites from the host computer, but when I try to log in using /user/login on either site, I get nothing. The POST returns a 404 containing the log in page again.
I've tried settings $cookie_domain = '.my-site.dev' as well as $cookie = 'www.mysite.dev'. Neither has any effect. I also tried adding a bunch of random charactersto the file to make sure I was editing the correct file; with the random characters, pages didn't load at all. (See https://www.drupal.org/node/611920#comment-3110010.)
I also tried doing repair table sessions. I forgot which site I saw that recommendation from. I also tried delete from sessions just for kicks. Neither worked.
Any ideas? Thanks!
edit: Per https://www.drupal.org/node/261411#comment-3182566, I tried to go to www.mysite.dev/?q=user/login. This did not give me a 404, but I had tried (unsuccessfully, it seems) to reset my password through the database. I'm at least getting an error about a bad username/password combination rather than nothing at all. Still, I would think /user/login should have worked, too.
edit 2: The production site uses CAS, but logging in through /user/login still works.
Related
I have a free heroku plan and a nodejs app on the heroku server. The nodejs app is built with meanjs, so the code for mongodb connections is exactly what you would find in the configuration files. I use a mongolab free mongo database to store the data. Occasionally (depending on how much I interact/change code I believe), the mongodb data is corrupted. I believe this to be true because I use a script to register names, and I can always log into them for awhile until I receive a no user/pass error. If I get this error and immediately create a new user, the user can successfully be logged in and out. All of the user data is still in the database. I also have a few other crud modules that use different collections in the same database, and I (so far) have not seen anything happen to that data, or anything to any of the data besides the password. I don't know where my error is possibly coming from, or what code is relevant, as I haven't touched the config files at all and to my knowledge haven't written any code that looks at user passwords at all. Also, my user object is occasionally empty (user = "") in the markup, but that bug was introduced after the original, I believe while I was trying to find out what was going on. Again, I don't have any clue though, so I included it just in case. Thanks!
After a lot of trial and error, I found the cause to my problem.
After I created these users, I go into my Mongolab account and manually edit the roles based on what module I'm working on (doing role based authentication). It is when editing the data that my passwords become corrupted. I don't know why, but I've pinpointed the problem to there. I've messed with some other data, with similar results.
I updated a clients Wordpress to 3.5.2 but couldn't login via wp-admin. The site is within another directory within public_html, eg: public_html/site so I thought that this might be causing the errors
I logged on to PHPMyAdmin, went to the wp_options table and saw that the siteurl seemed to be correct, eg: mysite.com/site/. Trying to see if it would help, I changed it to just mysite.com/ but that broke everything - I could even access the front page any more, I got a Server 500 error.
So I changed siteurl back to mysite.com/site/ again. However, my browser still shows the 500 error. Cleared cache to no affect.
Im not sure what else I can do. I changed the siteurl row back to what it was originally but the site remains broke. Any suggestions?
Try "relocating" the site by putting the original URLs in define statements in wp-config.php. See See Changing The Site URL « WordPress Codex for that and other recovery instructions.
I don't know why changing the URL would cause 500 errors. Check the .htaccess file, too; but that doesn't get written to when working in the database.
The login function can work on local server and uni server, but it doesn't work on the client's server.
checked the salt, the same as local core.php
checked the password, char(40),
set debug to 2,
deleting the cache files from the app/tmp/cache folder and subfolders,
but nothing happened, I still can not login the system.
I am not sure where I should be looking next, I am very confused.
client server
PHP version:5.3.17
CakePHP: 2.2.3
Many Thanks.
The solution:
Remove all the white space after the end of } tag in controllers and models.
Now, it works.
The reason(found in Google Search):
' the issue is a PHP issue with whitespace being output after some headers are sent, and typically occurs when a redirect is requested further down in the code from the whitespace. This issue has nothing to do specifically with CakePHP as implied in the post title.'
Thanks for help...
I got the SAME problem. removed all the white space after the end tag in PHP in ALL .php and .CTP files. over 1000 of them.
I believe it is something to do with folder permissions because in localhost it works FINE and Dandy and in my case I know the server has a lot of permission issues.
I am getting an endless loop with a concrete5 site that just went live today... it was fine in development using a temporary URL, but now live only the homepage works... was wondering if this has something to do with pretty URLS.
error: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
Site is http://redletterdaysforbusiness.co.uk
It seemed all was okay with the rewrite rules, and the error was in fact within C5 itself...
When developing the test site I had enabled pretty URLS, once I went live and changed the URL this didn't work anymore.
By disabling pretty URLS, all links worked. Then re-enabling prety URLS, everything still working.
Thanks jcem for you input.
I have a CakePHP website that's been working great.
I just developed a new functionality that at one point auto-logs the user in, and redirects him to a page that's behind the login wall.
This works perfectly well in my dev machine, but in production, the user gets redirected to the login page.
Relevant code: (not much)
$objCustomer = $this->Customer->findById($customerId);
$this->Auth->login($objCustomer);
$this->redirect("/customers/signup");
Customer is the Model that's used for authentication.
In the server, I see that I AM getting redirected to /customers/signup, and that redirects me to /customers/login
The thing that confuses me the most is that this works perfectly in my machine.
I dumped the return value of Auth->Login in the server, and it returns 1, so in theory everything is fine and the user should've been logged in.
Some things I can think of that are different between my machine and the server:
Dev machine is Windows, Server is Linux. This sometimes introduces case-sensitivity issues, but the signup method i'm redirecting to is all lowercase, I don't see where there could be such a problem here.
Dev machine is IIS, Server is LiteSpeed. Maybe Litespeed is screwing with something? This would be the first time in over a year running this site in production that i'd find something different because of LiteSpeed
Production site is over SSL, dev is not. I don't see how this could be a problem.
Any ideas are infinitely welcome!
Thank you!
I had problems too with authentication working fine on my machine in development mode, but not working on the server in production mode. Surprisingly, when I changed the server to development mode it started working correctly. Then I changed back to production, and it was still working. Perhaps it was some cache issue.
After a LOOOONG process of trying different weird things, it turns out it all boils down to this:
ini_set('session.referer_check', $this->host);
That's part of CakePHP's standard security features... It sets that INI setting.
If the request made to the action that'll call Auth->login is coming from another host (domain/subdomain/whatever), PHP will consider the session invalid, which effectively kills the auto-login attempt.