I'm fairly new to CakePHPand am building a site using the Auth component. A couple of times I have tried to do things with this component which have caused the error
Fatal error: Call to undefined method stdClass::user() in /ftphome/site/app/controllers/users_controller.php on line 395
The line it refers to in this case is
$this->User->read(null, $this->Auth->user('id'));
This error does not disappear when I revert the code back to how it was before the error and I only seem to be able to get rid of it by removing some files on the server (I'm not sure which files, when I tried removing all files in the tmp directory the error persisted so I removed the entire site and restored from the latest svn revesion.
In this particular case I think I caused the error by putting the following code in app_controller
class AppController extends Controller {
function beforeRender() {
$this->set('test', $this->Auth->user());
}
}
Which I copied from this thread http://groups.google.com/group/cake-php/browse_thread/thread/ee9456de93d2eece/cff6fe580d13622b?lnk=gst&q=auth
A previous time I caused the issue by attempting to update the Auth user details after updating the user in the database.
I can see I'm somehow removing the user object from the Auth object but I can't understand why I need to delete files in the site to get it back or how the code above removes it - any help would be much appreciated.
Edit
It looks like in the case I mentioned above, the problem was the app_controller.php file which I'd copied into my app/controllers directory. Just having the file with an empty class declaration causes this error - can anyone provide further insight?
Further edit
I've realised I've been a bit silly and the problem was caused by me putting app_controller.php in /app/controllers/app_controller.php when there was already one in /app/app_controller.php - thanks for the input though Andy, it helps me understand a bit more what was happening.
This error is normally thrown when a class instance (in your case an instance of Auth) has been serialised to disk, then re-read/deserialised in another request but the class definition (i.e. Auth) has not been loaded yet, so PHP creates it as an "stdClass" (standard class.)
When you remove your site files, you're removing the session storage (IIRC it's the Cache folder in a CakePHP app) so at the next request, a new session is created from scratch.
It's been a while since I last used CakePHP (I switched to Zend) so I cannot remember if Cake includes files it requires using an __autoload function or not.
On that mailing list post, someone says that you can this $this->Auth->user() in a view, but in the controller, you can use $session->read('Auth.User') to get the user component. Not sure what the difference is, maybe $this->Auth is a view helper, so isn't available in the controller?
Related
I am suddenly getting the error: "Unable to locate persister for the entity named 'MyLib.Project'."
I did not make any code changes to this project since the last time I published it. The reason I went into the code to look at it is because a user reported that the web page that utilizes this library was giving an error. I have also checked the eager loading of the provider as per (NHibernate - Random occurrences of "Unable to locate persister") but I am already eagerly loading.
Furthermore, I even changed my data provider configuration to:
.Mappings(Function(x) x.FluentMappings.AddFromAssemblyOf(Of Project)())
I stepped through the code and actually saw it find the Project mapping and step through it. There are no exceptions thrown while building the provider, but yet the web app still fails when I try to fetch a Project from the DB.
Update
I have tested this same exact code with a desktop application and it works perfectly fine. It seems to me the problem must be with NHibernate and the Web Application. Does anyone have any ideas about this specifically?
The answer to this, of course, is that I made a mistake.
I had two session factories in use in the same program and I passed a session from the wrong factory to one of my functions. So the error is correct, because the session it was passed was unaware of the Project type. I found this out eventually by looking at the Connection property of the session I was querying through.
Hopefully this helps someone else who may have made the same mistake.
I have a site built using MVC4 which is getting content out of a database and it all works fine.
If I then rebuild the solution and try to refresh the page to check my changes, I will always get the SQL Network Interfaces, error: 26 saying that I cannot connect to the server.
However, if I then browse to my homepage and then back to the page I was looking at it will work fine.
Does anyone know what could cause this problem as it is really annoying
EDIT
Further to this I have found it is when the AuthorizationContext filterContext is being loaded after the rebuild that it cannot connect to the db
EDIT 2
As with neil below I have found that I only get the problem if I try to access a page that has had a role assigned to it
I'm seeing the exact same problem and can trace it to the .ASPXAUTH session cookie in the browser. Delete that cookie and the database error goes away until the next rebuild.
The error occurs regularly if you are authenticated and then rebuild the project and try to browse any page that either:
Requires authentication
Makes a call to the User object (e.g. #if (User.IsInRole("Administrators")))
If you have the AuthorizeAttribute filter set in App_Start/FilterConfig.cs you'll get this on every page.
This seems to be new behavior following the most recent Patch Tuesday updates. Previously, I was seeing weird behavior where I would remain logged in but I would loose my roll membership. After the most recent patches, it seems Simple Membership chokes when it gets a bad .ASPXAUTH cookie (invalid because of the rebuild).
I've got the correct connection string in InitializeSimpleMembershipAttribute.cs but it's like Simple Membership is defaulting to something else in this one instance.
Note that I've moved the Simple Membership databases from the original (localDb) to a full-fledged (local) SQL Server instance. Don't know why that would matter, and it works fine in all other cases.
Update:
I've also tried making the connection string name the same as the EF context name (e.g. "ProjectContext") on the theory that it is defaulting to the standard convention, but that made no difference. I am explicitly identifying the connection string name in all my context class constructors (using the : base("connectionString") syntax) and Simple Membership is able to find the right connection string all other times.
Update 2:
The problem only occurs after rebuild when accessing a page protected by role. A simple [Authorize] won't trigger it. You need something like [Authorize(Role="Admin")]. I've replicated this on a new MVC 4 project with no other modifications, using the default (localDb) database. Clear the cookie and that same user can access the protected content w/o any problems. I believe this is a core .NET or MVC bug and needs to be reported as such.
This happened to me while rebuilding the application when I was logged in the browser.
Deleting cookies fixed the problem for me.
When using SimpleMembership, this bug occurs with any use of Roles-not just in the controller, but also when I use:
if(Roles.IsUserInRole(rolename){...
I am late to the game with this answer, but I added [InitializeSimpleMembership] to my home controller and I think that fixed it.
I'm working on a Symfony project in a Win7/Apache 2.2/ZendStudio environment and I have some trouble getting my file uploads to work properly.
My goal is to let the user create a new entity which can contain arbitrary many "Documents" (based on the article found at http://symfony.com/doc/current/cookbook/doctrine/file_uploads.html). I have a form type containing one field of type 'collection' (based on the article found at http://symfony.com/doc/current/cookbook/form/form_collections.html). So far so good. Via jQuery I can add arbitrarily many forms as subforms which works fine. But when I submit my form, very often (but not always!) I get the following exception:
Warning: rename(C:/Programming/Servers/Apache2.2/htdocs/Symfony/app/cache/dev/doctrine/orm/Proxies\__CG__MyMainBundleEntityRecruiter.php.507bf02e30df69.85090364,C:/Programming/Servers/Apache2.2/htdocs/Symfony/app/cache/dev/doctrine/orm/Proxies\__CG__MyMainBundleEntityLecture.php): Zugriff verweigert (code: 5) in C:\Programming\Servers\Apache2.2\htdocs\Symfony\vendor\doctrine\orm\lib\Doctrine\ORM\Proxy\ProxyFactory.php line 194
Zugriff verweigert is German for Access denied. Weirdly, the files seem to get renamed and saved at the right location nevertheless.
Why do I get this exception, does it have something to do with my environment and how can I fix it? I guess this issue is related to Symfony Warning : rename (../app/cache/dev , ../app/cache/dev_old ) : Access Denied . (Code : 5), but not quite sure whether it's the same as it happens in another context. I do also encounter the problem described in this link, though.
Thanks in advance.
I've been running into the same exact issue recently. I don't really have a good sense of why the problem is happening, but the problem is coming from a step in the process where Doctrine is trying to generate proxy classes.
In my config.yml file, under the ORM section of the Doctrine configuration, I changed the value of auto_generate_proxy_classes from %kernel.debug% to false. I've played with it for a while since making the change and haven't been able to reproduce the issue since.
Found this while looking for same answer, it seems to be a windows + Doctrine issue.
Doctrine Ticket with more detailed info
TLDR: Basically the proxy is trying to rename a file that's still being used, works in Linux but not always on windows.
Go to the file that renames the file, then replace it with a windows compatible rename function
private function renameWindowsCompatible($oldfile,$newfile) {
try {
rename($oldfile,$newfile);
} catch(\Exception $e) {
if (copy($oldfile,$newfile)) {
unlink($oldfile);
return TRUE;
}
return FALSE;
}
return TRUE;
}
I learned about proxies and saw that it is used with lazy loading.
I had an entity A with a one to one relationship to B.
B was the problem is the proxies directory
I just had fetch="EAGER" annotation in A entity
/**
#ORM\OneToOne(targetEntity=B::class, fetch="EAGER")
*/
private $b;
Then the B proxy was not generated and no more problem with rename.
Hope this help.
I get the following error within Magento CE 1.6.1.0
Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: Cannot send session cookie - headers already sent by (output started at /home/dev/env/var/www/user/dev/wdcastaging/lib/Zend/Controller/Response/Abstract.php:586) in /home/dev/env/var/www/user/dev/wdcastaging/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php on line 119
when accessing /api/soap/?wsdl
Apparently, a session_start() is being attempted after the entire contents of the WSDL file have already been output, resulting in the error.
Why is magento attempting to start a session after outputting all the datums? I'm glad you asked. So it looks like controller_front_send_response_after is being hooked by Mage_Persistent in order to call synchronizePersistentInfo(), which in turn ends up getting that session_start() to fire.
The interesting thing is that this wasn't always happening, initially the WSDL loaded just fine for me, initially I racked my brains to try and see what customization may have been made to our install to cause this, but the tracing I've done seems to indicate that this is all happening entirely inside of core.
We have also experienced a tiny bit of (completely unrelated) strangeness with Mage_Persistent which makes me a little more willing to throw my hands up at this point and SO it.
I've done a bit of searching on SO and have found some questions related to the whole "headers already sent" thing in general, but not this specific case.
Any thoughts?
Oh, and the temporary workaround I have in place is simply disabling Mage_Persistent via the persistent/options/enable config data. I also did a little bit of digging as to whether it might be possible to observe an event in order to disable this module only for the WSDL controller (since that seems to be the only one having problems), but it looks like that module relies exclusively on this config flag to determine it's enabled status.
UPDATE: Bug has been reported: http://www.magentocommerce.com/bug-tracking/issue?issue=13370
I'd report this is a bug to the Magento team. The Magento API controllers all route through standard Magento action controller objects, and all these objects inherit from the Mage_Api_Controller_Action class. This class has a preDispatch method
class Mage_Api_Controller_Action extends Mage_Core_Controller_Front_Action
{
public function preDispatch()
{
$this->getLayout()->setArea('adminhtml');
Mage::app()->setCurrentStore('admin');
$this->setFlag('', self::FLAG_NO_START_SESSION, 1); // Do not start standart session
parent::preDispatch();
return $this;
}
//...
}
which includes setting a flag to ensure normal session handling doesn't start for API methods.
$this->setFlag('', self::FLAG_NO_START_SESSION, 1);
So, it sounds like there's code in synchronizePersistentInf that assumes the existence of a session object, and when it uses it the session is initialized, resulting in the error you've seen. Normally, this isn't a problem as every other controller has initialized a session at this point, but the API controllers explicitly turns it off.
As far as fixes go, your best bet (and probably the quick answer you'll get from Magento support) will be to disable the persistant cart feature for the default configuration setting, but then enable it for specific stores that need it. This will let carts
Coming up with a fix on your own is going to be uncharted territory, and I can't think of a way to do it that isn't terribly hacky/unstable. The most straight forward way would be a class rewrite on the synchronizePersistentInf that calls it's parent method unless you've detected this is an API request.
This answer is not meant to replace the existing answer. But I wanted to drop some code in here in case someone runs into this issue, and comments don't really allow for code formatting.
I went with a simple local code pool override of Mage_Persistent_Model_Observer_Session to exit out of the function for any URL routes that are within /api/*
Not expecting this fix to need to be very long-lived or upgrade-friendly, b/c I'm expecting them to fix this in the next release or so.
public function synchronizePersistentInfo(Varien_Event_Observer $observer)
{
...
if ($request->getRouteName() == 'api') {
return;
}
...
}
I had to move a website on a bluehost server, that is in the Joomla Platform 1.7. I did alot of reasearch on Joomla.org and google and still haven't resloved the issue.
I recieve the following error: Infinite loop detected in JError. I went threw the configuration file and made sure that database and user match up with my new database parameters match up and I am still recieving this issue. Thank you. Urgent response will be very helpful. Currently working on this and this is not a good start. :(
I have ran into the same issue moving my Joomla site from one server to another. What I learned is the following;
Make sure you look at the parameters in configuration.php. Double check if the following variables in your configuration.php file is correct. (Double Check) You did mention that you already have done so. In that case I am 98% sure that you have an issue dealing with file Attributes with configuration.php. Change the Attributes of configuration.php from 444 to 666.
To get detailed information about the error, open the error.php file located in /libraries/joomla/error/ on your server.
In the following code:
public static function throwError(&$exception)
{
static $thrown = false;
// If thrown is hit again, we've come back to JError in the middle of
throwing
another JError, so die!
if ($thrown) {
// echo debug_print_backtrace();
jexit(JText::_('JLIB_ERROR_INFINITE_LOOP'));
}
change the line // echo debug_print_backtrace();
to the following:
**print"<pre>";
echo debug_print_backtrace();
print"</pre>";**
Remember- When you change the parameters in configuration.php to you new database make sure you that configuration.php file attribute is set to 666, Otherwise when you go to save the file it will not change. Try this first.. Good luck.