It is present in only one of five apps (all in the same project).  It
is definitely not the server.  It happens to all the modules in one
app, except for it seems, when I return renderText directly in the
action.  This leads me to suspect (ridiculously enough) that it is
something in the layout, which I am trying to confirm now.

On Tue, Jul 6, 2010 at 2:59 AM, Tom Ptacnik <to...@tomor.cz> wrote:
> Did you tried to run this app on a different server? .. then you will
> know if the problem is in the app or in your server.
>
>
> On 5 čnc, 04:31, ashton honnecke <ahonne...@gmail.com> wrote:
>> This behavior (Inability to stay signed in) went away in four of five
>> apps when I altered the session_name.  However, it remains on one of
>> the apps.  That is to say that in my backend app (as well as others) I
>> can login correctly but in the frontend app though, I can only stay
>> logged in for one page load (so I have to login for every page).  I'm
>> sure that this is from something that I have done wrong.  Does anyone
>> have any suggestions about where to look or how to debug this?
>>
>>
>>
>> On Tue, Jun 22, 2010 at 8:55 AM, ashton honnecke <ahonne...@gmail.com> wrote:
>> > I hadn't altered factories.yml at all.
>> > Being in there I tried changing the session_name (it was just the
>> > default 'symfony') and the site stopped exhibiting the broken
>> > behavior.  This still doesn't make sense to me, but altering the
>> > session_name certainly fixed things for now.
>>
>> > I have a few apps with the default cookie name, could that be the issue?
>>
>> > On Tue, Jun 22, 2010 at 8:44 AM, pghoratiu <pghora...@gmail.com> wrote:
>> >> The defaults for session storage are defined in apps/frontend/config/
>> >> factories.yml.
>> >> If there is nothing changed vs. the defaults than the PHP session
>> >> storage is used, in this case you can check
>> >> the serialized sessions stored usually somewhere in /var/lib/php5 (or
>> >> something similar, depending on your Linux distribution).
>>
>> >>   gabriel
>>
>> >> On Jun 22, 5:33 pm, ashton honnecke <ahonne...@gmail.com> wrote:
>> >>> I'm not sure.  How do I check on this?
>>
>> >>> I tried reverting my dev instance to a known version (the same one
>> >>> that is in production and can be logged in to), it still exhibits this
>> >>> behavior, so I think that you are probably right that there is
>> >>> something going on outside of the code.  What might that be, and do
>> >>> you have any ideas of how I could check?
>>
>> >>> ashton
>>
>> >> --
>> >> If you want to report a vulnerability issue on symfony, please send it to 
>> >> security at symfony-project.com
>>
>> >> You received this message because you are subscribed to the Google
>> >> Groups "symfony users" group.
>> >> To post to this group, send email to symfony-users@googlegroups.com
>> >> To unsubscribe from this group, send email to
>> >> symfony-users+unsubscr...@googlegroups.com
>> >> For more options, visit this group at
>> >>http://groups.google.com/group/symfony-users?hl=en
>
> --
> If you want to report a vulnerability issue on symfony, please send it to 
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony users" group.
> To post to this group, send email to symfony-users@googlegroups.com
> To unsubscribe from this group, send email to
> symfony-users+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/symfony-users?hl=en
>

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en

Reply via email to