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.

$5
Why would a user be locked out of a module, same perms as others?

I have an URL that sort of looks like this:

http://www.domain.com/front_dev.php/polls/index


There is a "polls" module, with these 3 folders:

actions
config
templates


Inside the config folder, I have a security.yml file that looks like this:

all:
is_secure: on

results:
is_secure: off



As expected, I can visit polls/results without being logged in, and I can visit polls/index if I log in.

I have a user who can visit polls/results, but when she goes to polls/index she is asked to login, even if she is already logged in. If she goes to another module, such as blogs/article/id/456, then the code recognizes that she is logged in. For instance, on this site, a user has to be logged in to post comments on the blogs, and when she is in the blogs module and logged in, she is invited to post comments - so the software knows that she is logged in.

But when she goes to polls/index, she is asked to log in. Why?

All of this testing was done with the dev controller.







This question has been answered.

Lawrence Krubner | 07/27/10 at 6:05pm Edit


(5) 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:
    07/28/10
    12:02am
    reena says:

    Hello Lawrence,

    Have you put is_secure on in blog module where logged in working perfect? If yes then you have to check this problem by make one class in application lib which extend sfBasicSecurityFilter and set this class name in filter.yml like this


    security:
    class: here your class name which you have put in lib (forexample :sfCustomBasicSecurityFilter)

    and you have to overrite execute method and need to check where exact problem arise.

    If you have not put secure on in blog module then you have to first of trace getting credential and session proper or not.

    Thanks,
    Reena Yadav

  • avatar
    Last edited:
    07/28/10
    12:23am
    GlobalOrangeLab says:

    Hi Lawrence, you are also right. but can you try this way.


    results:
    is_secure: off
    default:
    is_secure: on


    Hope this works.

    Regards,
    GlobalOrangeLab

  • avatar
    Last edited:
    07/28/10
    4:58pm
    Loban Rahman says:

    If I'm understanding you right, you aren't complaining about the security.yml file, because it is correctly wanting the user to be logged in at polls/index. However, the problem is that symfony is not recognizing the fact that the user IS logged in. However, it's working in other modules, such as the blog comments.

    Couple of questions first:

    (1) Does this happen for all users, or some users? If it is only for some users, then this is not a security.yml problem, but a user session or browser caching/cookie problem.

    (2) Log the user out. Disable symfony caching, also delete browser cache and cookies. Then log the user into the site without first going to polls/index. Once the user is logged in, then go to polls index. If it works this time, it means you have a caching problem. I've had this happen before, in that the browser mistakenly caches the login page as the output of polls/index, so even when u are logged in, the browser is showing the cached login page. Hitting Ctrl-F5 to do a forced refresh sometimes shows the correct results. Even then, IE6 sometimes barfs.

    First run this experiment and tell me the result. I can give a more definitive answer then.

  • avatar
    Last edited:
    07/28/10
    11:47am
    Tomasz I says:

    If you use Symfony 1.4 change on/off to true/false

  • avatar
    Last edited:
    07/28/10
    4:54pm
    Lawrence Krubner says:

    I think in the end this was some kind of cookie/session/cache problem. Oddly, it persisted after she had deleted the browser cookies. But we cleared the cache on the server, cleared all session files on the server, re-booted the router she was connected to and eventually the problem resolved. Thanks for this suggestion.

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.