logo
Ask your Symfony questions! Pay money and get answers fast! (more info)

Warning: Please do not give out any FTP or ssh credentials to anyone, unless you trust them completely. Giving out login details is dangerous.

If the asker does not get an answer then they have 10 days to request a refund.

$4
Why would back.php have different database access than index.php

We are trying to move all of our sites to the RackSpace cloud. All of our sites will share one code base, so we took most of the Symfony project and put it in this folder:

/home/zebulon/project/

Only the "web" directory lives elsewhere. Each web site has a path like:

/home/emergencyquestions.com/public_html/

and in this folder would be other folders like:

/css

/images

/uploads

We have 2 front controllers:

index.php

back.php

They live here:

/home/zebulon/project/web/

Here is the odd thing:

I can log into index.php just fine. But when I try to log into back.php, I'm told "No such username can be found." I'm using the same username.

Why would the 2 front controllers give different login responses?


[UPDATE]

I should mention that WP Questions is still on the old server, and there I can log into the backend with no problem. So the problem is not exactly with the code, but rather, it is something to do with the new setup on the new server.

This question has been answered.

Lawrence Krubner | 11/29/10 at 12:19pm Edit

Previous versions of this question: 11/29/10 at 1:32pm

The experts have suggested, on average, a prize of $4 for this question.

(10) Responses

See a threaded view of answers?

Warning: Please do not give out any FTP or ssh credentials to anyone, unless you trust them completely. Giving out login details is dangerous.

  • avatar
    Last edited:
    11/29/10
    12:24pm
    Ben says:

    are you using the same environment for both controllers

    require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

    $configuration = ProjectConfiguration::getApplicationConfiguration('frontend', <ENVIRONMENT>, false);
    sfContext::createInstance($configuration)->dispatch();


    ensure <ENVIRONMENT> is set to the same for both controllers.

  • avatar
    Last edited:
    11/29/10
    12:30pm
    Nate Flink says:

    try accessing with the dev controller back_dev.php same problem?

    Is your back.php inheriting from sfGuardSecurityUser ? check /apps/back/lib/myUser.class.php for the line: class myUser extends sfGuardSecurityUser

  • avatar
    Last edited:
    11/29/10
    2:30pm
    Gert Findel says:

    I had a similar problem, but I fixed it configuring my httpd.conf and htaccess
    Can you paste your virtual host config and htaccess?

  • avatar
    Last edited:
    11/29/10
    10:35pm
    Loban Rahman says:

    (1) Can you login using the dev versions of the front controllers? contest_dev.php and back_dev.php
    (2) If the same problem as above, please post the tail end of the log file.

  • avatar
    Last edited:
    11/30/10
    10:04pm
    Florian Klein says:

    As said above, first check the environment used in your front controller



    $configuration = ProjectConfiguration::getApplicationConfiguration('contest', 'prod', false);


    Then, open your config/databases.yml to check if a different database access is defined in this environement.


    example with propel:

    dev:
    propel:
    param:
    classname: DebugPDO

    test:
    propel:
    param:
    classname: DebugPDO
    dsn: mysql:dbname=equipmoto2_test;host=localhost
    all:
    propel:
    class: sfPropelDatabase
    param:
    dsn: mysql:dbname=equipmoto2;host=localhost



    As you can see, in function of the environment selected in my front controller, the database accessed will be either equipmoto2 in prod or equipmoto2_test in test environment.


    Other possible solution, you maybe are sharing the same session between the two applications:

    check your session config in apps/<frontend | backend>/config/factories.yml, section storage:

    symfony ref book

    If you're using sfGuard, it will try to load the user by id stored in session, but it may be inexistent in one of your databases.



    Previous versions of this answer: 11/30/10 at 4:19am

  • avatar
    Last edited:
    11/30/10
    10:34am
    José Nahuel Cuesta Luengo says:

    Have you checked the dsn configuration that shows up in the web debug bar for both controllers?

    I mean, try accessing through the 'dev' environment on both of the controllers, and look for the DSN configuration in the web debug on both. Do they differ?

  • avatar
    Last edited:
    11/29/10
    1:28pm
    Lawrence Krubner says:

    This is from back.php:


    require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

    $configuration = ProjectConfiguration::getApplicationConfiguration('back', 'prod', false);

    sfContext::createInstance($configuration)->dispatch();



    this is index.php:

    require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

    $configuration = ProjectConfiguration::getApplicationConfiguration('contest', 'prod', false);
    sfContext::createInstance($configuration)->dispatch();







  • avatar
    Last edited:
    11/29/10
    1:30pm
    Lawrence Krubner says:

    backend end user class:

    class myUser extends sfGuardSecurityUser
    {
    }

  • avatar
    Last edited:
    11/29/10
    1:36pm
    Nate Flink says:

    Is it possible that you have some .htaccess rules or redirects in the apache config on one server but not the other? Check your apache config. Are you sure your looking at what you think you are?

  • avatar
    Last edited:
    11/30/10
    10:04pm
    Lawrence Krubner says:

    I think you are right about sharing the session data. And, the cache data. One of the problems of this kind of setup, trying to centralize the code and then share it among dozens of sites.

This question has expired.





Current status of this question: Completed



Warning: Please do not give out any FTP or ssh credentials to anyone, unless you trust them completely. Giving out login details is dangerous.

If the asker does not get an answer then they have 10 days to request a refund.