I need to share sessions between subdomain but my sessions are stored in weird format. For example if ill compare same session data (from session file) from different servers i see that in first case data are stored correctly but not in second one.
First server session string:
TEST_VAR|s:10:"TEST VALUE";
Second server session string:
NUnNmu-NLaO2lP-1J_LVRdJm5cPH54dlnDN1W1GaHXrebf3hl_clOl3xeoZlvHsj
I'm using same code to generate sessions, where is the problem? Anyone know whats wrong? How can i decode this weird string? session_decode() can't handle it.
This might help: PHP / Drupal, Session Storage and encryption
If not, check the php.ini/phpinfo() on both servers and see if there are any differences in the session-related configuration.
Related
I have a nasty problem with Symfony2 session. I have a cart in which I can insert things. I add several items and it works, but on some items the app crashes telling me
ContextErrorException: Warning: session_start(): Failed to decode session object. Session has been destroyed in ...
The session is destroyed and I'm logged out of the site.
I have the session stored in the DB and the line about the session is deleted too, like a clean logoff.
I triple checked all the code and I have no code of mine that invalidates the session. I also commented out each line containing session->invalidate to no avail.
I noted that the session cleanup comes between the "return" of one function and the following line in my code after the code returns, but there is no code between them. It seems something related to events/listeners but none are configured by me.
I don't know where to check, any ideas?
Based on this report and other searches, my guess is you're storing multi-byte strings in your session data and it's getting corrupted. It's also possible the database column storing the data is too short and the string is getting truncated, corrupting it. Here's what I would look at:
If you're using a database for storage be sure it's prepared for multi-byte strings.
Make sure your session database column is large enough, e.g. MEDIUMTEXT instead of VARCHAR.
Maybe there's a bug in Symfony's session handler (unlikely since that probably would have been caught quickly).
Maybe you've somehow corrupted your own multi-byte strings. Check you're not using any PHP functions that aren't binary-safe.
If you can't find the root cause I would try overriding the session storage handler and running base64_encode over the data before storage and decode after retrieval. But that's a last resort to work around the real problem.
I changed the write e read method of PDOSessionHandler instead of base64encode/decode i put utf8_encode for write and in the read method i put utf8_decode. This workaround works for me but is not a clean solution. The question now is: why base64encode/decode fails?
I'm using CodeIgniter 3.x with database session driver and i want to access data cloumn that BLOB type. Here my blob data:
__ci_last_regenerate|i:1435420891;identity|s:13:"john#doe.com ";username|s:13:"johndoe";email|s:13:"john#doe.com ";user_id|s:1:"5";old_last_login|s:10:"1435412865";
I tried with unserialize($string) but didnt work!
unserialize(): Error at offset 0
How can i access blob data element? For ex: $user['email']
There's no straight-forward way to do that ... You could use session_decode(), but it requires that you already have an active session, so that it can put the decoded data into $_SESSION.
I must tell you however, if you want to do that - you're doing it wrong. You should never access another user's session. If there's some data that's tied to a session that's not explicit to the user who owns the session, you should just add another field to the sessions table and save it in there.
I got the solution here
So I have used session decode http://php.net/session_decode
session_decode('__ci_last_regenerate|i:1446535049;ci_UserID|s:1:"2";ci_UserName|s:24:"example#xyz.com";logged_in|b:1;');
So session decode stored all the encrypted data in normal php session.
Which I can access using:
echo $_SESSION['ci_UserID'];
As Narf says there is no easy way to do this.
ykay;s solution presupposes that you are using the current built in session handler. That can be changed at any time by the application, and there are no guarantees that PHP will keep this format.
Your solution trashes the current session and replaces it with the stored data (but at least it will use the "current" serialization method).
The serialization function and the read/write operations for session_ functions can be overridden at runtime. As long as you read back data encoded using the same mechanism as you use for decoding your mechanism will work - but it is a bad approach for long term storage of data or for use in a context where you cannot guarantee consistency of the PHP installations reading the data.
The right way to fix the problem of reading session data outside of a user's session is to use the serialize/unserialize format:
ini_set("session.serialize_handler", 'php_serialize');
Then use unserialize() to read the data.
In my application I need to use ssl. While redirecting from http//mydomain.com to https//mydomain.com session data is lost in case data is huge.
I have tried removing https to http, but still no use. My server is on a linux machine.
Please help me out.
Don't keep large amounts of data in the session itself. Instead, keep it in your friendly local database table (or tables) and only put the key into the table in the session. You could even make it so that the user can log out and log in from another machine and get back at that same data by making the data keyed "off their account" somehow.
In short, think carefully about what the lifetime of the data really should be. For large data, tying it to an HTTP session is probably the wrong approach as users tend to get upset when they have to reupload/recreate it because of a browser glitch.
How much data are we talking about? You shouldn't hold a lot of data in your sessions.
Also check if your session ID is the same when you redirect to HTTPS. I think you get a new cookie from HTTPS with new session ID, so the data is naturaly lost.
Hey guys, I found out the problem. I am using cake php application.
Session was getting stored in database and the input type for storing session was "text" , now changed it to "longtext".
So the problem was solved.
I have two pages and I want to pass data to each other.
How can I do this without accessing a DB?
Sessions? Cookies? someother magical way?
If you know how, can you please post sample code?
Thanks
Session variables is one way:
$_SESSION["variable"] = "value";
This variable can then be read/modified by another page.
Also note, that you need to start the session by calling start_session(); at the beginning of your script.
And Cookies are another way... You can also try writing in and out of a file instead of a DB
How does a user get between these two pages? I assume a Form based solution is out of the question...
Amongst the possibilities, here are some that I think about :
You could $_SESSION (see Session Handling) -- if both pages are accessed by the same user, without too much time between the two accesses, so the session doesn't expire.
You could store your data to a file ; that'll work fine if :
The amount of data is big
You want it to persist for a long time
But you'll have to do some cleaning-up by yourself
Another idea would be some external daemon, like memcached
But, as it's a caching engine, it's not necessarily good for storing data : the data that is cache can be removed from the cache even if it has not expired yet (i.e. if there is no place left in cache, memcached will remove some least used data)
Of course, if the data is small and you don't mind it going back and forth through the network, and both pages are accessed by the same user using the same browser, you could use cookies
Only a couple of possibilities, though ; my preferences would probably be :
$_SESSION
or files
Depending on your situation.
does any body have any info/links as to how to integrate a cookie based session system? i've used file/mysql, and am currently using memcached. i wanted to play with apc sessions, but thought i'd give a go at cookies, only i don't know much about it.
i imagine i'd have to write my own session handler class?
In PHP session data is usually stored in a file. The only thing stored in the cookie is a session identifier. When sessions are enabled and a valid session cookie is found, PHP loads the users session data from the file into a super global called funnily enough SESSION.
Basic sessions are started using session_start(); called before any text is sent to the browser. then items are added to or removed from the session object using simple array indexing eg.
$_SESSION['favcolour'] = 'blue';
later...
$favcolour = $_SESSION['favcolour'];
basic cookie only sessions (no local storage) can be created with a call to
set_cookie('favcolour','blue'[,other params]);
before any text is sent to the browser, then retrieved from the cookie superglobal
$favcolour = $_COOKIE['favcolour'];
you don't need to call session_start() if doing cookie only sessions.
the optional [,other params] are more advanced and can be read about here http://www.php.net/manual/en/function.setcookie.php
Sessions can become a very complex discussion, I'd suggest doing some light work in them and then expand your knowledge.
DC
all you ever wanted to know about PHP sessions
http://www.php.net/manual/en/book.session.php
DC
To reuse PHP's session handling code you will need to add a write handler using session_set_save_handler and then do exactly nothing in that handler. That's because its called after the output to the browser is closed therefore you cannot send anything to the browser.
Before writing non header data to the browser use the set_cookie functions and store the contents of the $_SESSION array (after serialising and encrypting) into a cookie. when the applications start you can read the cookie unserialise it and put it into the $_SESSION array.
That's a quick hint at what to do as I have never done it, I prefer to write all my own cookie code. There may be some gotcha's but its not hard a few tests should find any gotcha's.
DC