We are using Spring session and we observed that the screen was appearing blank sometimes. We noticed that when the screen worked as expected, there was only one session id created. However, when the screen was blank, we noticed two session id being created because of which the data stored in the session was getting lost.
Please let me know if anyone has encountered such issue before and found a solution to it.
Thank You!
Related
each time I try to configure a session in HermesJMS it does not appear in the session window. I can still see it in the session drop down if I select to create a new session however it gets dropped from the main view where I want to view it in order to be able to create topics, etc. any ideas. I've attached a screen shot so that you can see what I mean
the below is what I have created:
the below is what I can see - which is only file
Its unclear where the other ones are?!!
Found the issue it is related to part of the config not being required - it doesn't error it just doesn't show the session as being viewable. which isn't great
I have a strange issue with a Laravel 5.1 application.
Intermittently, it’s dropping session data. I’m detected this by writing some middleware that writes the contents of the session for that request to the log file. Although the session ID (Session::getId()) doesn’t change, the value of _token in the session data retrieved with Session::all() does.
As I say, this happens intermittently. I can refresh the same URL multiple times, and then randomly on one refresh the session data’s gone, and the _token value’s different from the previous requests.
What would cause this? I’ve also noticed the flash object isn’t in the “dropped” session data.
Below is a snippet of the log. You can see the content of the session_data key randomly changes “shape” in the last two lines, but the session ID remains constant.
Also, not sure if it’s pertinent, but I have DebugBar enabled.
UPDATE: Through debugging, I’ve found that on some page loads the session is completely empty, as in, no _token (hence a new one getting generated). Nothing.
If you're using the file driver, you could run into race conditions on concurrent requests. The file then gets truncated, Laravel can't read it, so it refreshes the session. Race conditions can also lead to a symptom where something you're putting to the session just doesn't get put. This tends to be random, so it's very hard to debug. According to the Laravel team, this is a known limitation of the file driver and it does not appear to be getting fixed, so I would suggest using a different driver. This would fix your issue of random session refreshes, but it still introduces a possibility of making a change to the session that doesn't get added. As far as I know, at this point with Laravel 5.1, you'll have to manage that yourself.
Somehow your session data is too long and being truncated. If you're using the database driver (haven't tested other drivers), and you try to save session data that's longer than the field length, then subsequent requests won't be able to pull from this session, and you'll wind up with a new session. If this issue is happening randomly with very short session data, then it's probably the cause listed above.
If you use Linux, Try using Redis (http://redis.io) as session / cache manager in laravel. I had some issues in the past with text / cookies and laravel in some servers. When I instaled Redis I had no problems anymore.
More info: https://laravel.com/docs/5.1/redis
Using a different driver like memcached did not solve the problem for me.
Here is a package that implements session locking which works and very simple to incorporate in your projects.
https://github.com/rairlie/laravel-locking-session
Long story short: I have hacked jasny/sso to work with Laravel. It works extremely well except when the primary/root session has expired.
I have the primary/root authentication set to "remember", so it can reauthenticate from the cookie when the session has expired.
When the 'attach' action happens on the SSO server and the primary/root session has already expired, I am running Auth::check() to bring the session back to life so that it can be attached properly.
All of my debugging indicates that everything is working exactly as I need it to except for this one little detail:
The new session generated by the 'attach' action is never written to the database because the DatabaseSessionHandler thinks it already exists. It is running an UPDATE instead of an INSERT.
As a result, my SSO client session attaches to a non-existent SSO server session.
For the life of me, I can not figure out why it thinks this new session already exists nor how to get it to correctly insert into the database.
Can anyone tell me why a new Laravel 4.2 session would be detected as "exists" and run UPDATE instead of INSERT on save()?
EXTRA DEBUGGING ATTEMPTS --
Attempt #1: I have tracked this to a false attachment to an expired session that hasn't been garbage collected yet. What I don't understand is how this session is being loaded while a different session ID is being presented. If this were the result of the migrate() or regenerate() methods, "exists" would be set to false, and it would save correctly. Somehow, it seems that the session ID is being updated without resetting "exists".
Attempt #2: The answer was staring me in the face the whole time. I kind of understand the downvote now. (see my answer below)
I was dramatically over-thinking this as I tried to uncover the mechanism behind the behavior instead of testing what looked like an easy solution:
If I call Session::setExists(false) prior to Session::save(), it will insert the new session correctly.
EDIT: If wrapped in an if-statement for Auth::viaRemember(), I can check if the auth happened via session or cookie/remember. If true, then I want to set "exists" to false.
i already posted this question but still wasnt able to resolve this issue.
seems that everyone has this problem with codeigniter .
When i set my session in a controller it works perfectly and i can display it.
WHen i move to another controller, the (CUSTOM) session data is completely lost.
i tried changing my cookie_domain in config.php. Since i am on localhost i tried localhost with without / and localhost/codeigniter and sodeigniter all did not work. i am lost
btw, i read somewhere that this happens when 2 ajax requests happen at the same time. could that be the problem?
Or maybe tell me how you resolved the problem if you had same issues
screw this, i am swithing to php native sessions. if anyone wants to do that,
http://codeigniter.com/wiki/PHPSession
Check and double-check your code or any external libraries you are using for a stray sess_destroy(). I ran into a similar problem where I was storing an id in the session for reference but if the user then logs in the SimpleLogin library I was using for logins just destroys the entire session including data I did not want to lose.
This is what I get for not writing my own code.
My FBML based app suddenly stopped working since Nov.18.2011. It was working fine before that. And nothing has changed from our side. Could that be some of the new changes Facebookk put in on Nov.18 ( http://developers.facebook.com/blog/post/600/ ). Does anyone else has the similar problem? Any ideas on how to fix it?
Thanks a lot!
My FBML app stopped working around this day too. The problem is that they switched to the new auth system, where instead of sending the fb_sig HTTP parameters to identify the user and verify that the request came from Facebook, they now send one single parameter called signed_request. Which language/library are you using to interface with Facebook? See https://developers.facebook.com/docs/authentication/signed_request/ for more details on this new signed_request parameter.