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

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


I have an URL that sort of looks like this:

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


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

is_secure: on

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.

Answers (4)


Loban Rahman answers:

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.

Lawrence Krubner comments:

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.


reena answers:

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

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.

Reena Yadav


GlobalOrangeLab answers:

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

is_secure: off
is_secure: on

Hope this works.



Tomasz I answers:

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