Apparently, this issue is related to calling the jQuery helper.
I built out an empty action and an empty template, and they work
perfectly, until I added a call to the jQuery helper, so I removed
everything else, nothing in the action and one line in the template:
That allows me to reproduce the
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, wh
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 wrote:
> This behavior (Inability to stay signed in) went away in four of five
> apps when I altered the session_name. However, it remains
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 pag
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 wit
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 yo
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 b
How does symfony store the session in your case, are you using the php
session or something else?
gabriel
On Jun 22, 9:19 am, ashton honnecke wrote:
> I am able to save information to the session manually:
> print_r($_SESSION['something']);
> $_SESSION['something'] = array('7');
I am able to save information to the session manually:
print_r($_SESSION['something']);
$_SESSION['something'] = array('7');
That will save and then print Array ( [0] => 7 ) in a unprotected action.
On Mon, Jun 21, 2010 at 12:14 PM, pghoratiu wrote:
> I would say it's something wrong
Nope, it came back after I cced and rebuilt the models.
On Mon, Jun 21, 2010 at 2:05 PM, ashton honnecke wrote:
> In order to test if the issue lay in the environment or in the code, I
> set up a new vhost and checked everything out again at various
> revisions. I can't seem to reproduce the iss
In order to test if the issue lay in the environment or in the code, I
set up a new vhost and checked everything out again at various
revisions. I can't seem to reproduce the issue at all on the newly
checked out vhost. So this issue has been resolved I think.
Thanks!
On Mon, Jun 21, 2010 at 12
It was working at one point. The issue seems to span all the apps that I have.
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
PHP 5.2.10 (cli) (built: Aug 6 2009 06:05:50)
symfony version 1.4.6-DEV
ashton
On Mon, Jun 21, 2010 at 12:14 PM, pghoratiu wrote:
> I would say it's something w
I would say it's something wrong at the PHP configuration level, what
is your environment (OS, PHP, symfony version, ...?).
gabriel
On Jun 21, 8:51 pm, ashton honnecke wrote:
> This is what I have in configuration>user on the page load after sign
> in (from the webDebugToolbar):
>
> attribut
This is what I have in configuration>user on the page load after sign
in (from the webDebugToolbar):
attributeHolder:
sfGuardSecurityUser: { user_id: '173' }
On the next pageload, it goes away (no sfGuardSecurityUser at all)
I printed the session at the beginning of an action (right after
logi
Check the session - the user id should be stored after sign-in.
This can be checked in the web debug toolbar or directly the
serialized session data.
gabriel
On Jun 18, 9:50 am, ashton wrote:
> I'm not sure how I broke things, but I can no longer remain logged in
> beyond one page load (trie
15 matches
Mail list logo
