I'd like to know if there's a way by which a PHP object could be sent to another PHP page on a different machine?
For instance - I've implemented a class that constructs a Trie. Now after the Trie has been constructed , I'd like to send across the object to another PHP page so that it can access the object too.
Would probably packaging it into some sort of encoded JSON request and then sending it to a page which could relay it to the required page using jQuery , be a feasible option ?
I'm sorry I'm absolutely new to this !
Will Appreciate any help provided.
Cheers!
An object is an instance of a Class. Objects can't be sent around as they are. A "transmissible" object must be Serializable: make sure that your class implements Serializable
Once you've implemented the interface, just call the serialize and deserialize methods to get the object-string and to rebuild the object
Use php functions serialize() and unserialize(). When you unserialize the object, be sure to have its class defined.
personally I'd store the object in an object store rather than serialise memcache, APC even a session can be used, you can also use nosql style databases and key stores all of which are pretty much perfectly suited to object persistance as they're mostly very fast access data stores without the sql overhead. nosql-database.org
Just assign each object a key based off the key of the user browsing generate a new key for each new browser and store it in session/cookie to retrieve their personal "objects"
As already mentioned by STT you can serialise and store in the session thats perfectly fine although serialise is retarded to implement in php they should never have put that in.
Instead look at APC and SPL both are built in to php (APC is more suited for an object store especially since from 5.6 (I believe so onwards) its no longer an extension but built into the PHP core its self making it fully native so you get not only a simple object store but also op code cache which will seriously increase the speed of your php pages.
Note: APC is only really usable for object store when you run a single web / php server if you need multiple processing servers then you'll need a distributed object store in which case the best you can probably get is memcache
Lots of links mostly all on SO.
When should I use Memcache instead of Memcached?
Memcached vs APC which one should I choose?
http://php.net/manual/en/book.memcached.php
http://php.net/manual/en/book.apc.php
Is there a way in PHP to use persistent data as in Java EE? (sharing objects between PHP threads) without session nor cache/DB
The right way is to implement Serializable interface in the class of your object (if it doesn't yet) that pass it through some sort of transport between two servers.
Try to not send data trough client-side code unless you trust client or you don't care about data.
Related
I have a pretty big PHP class instance with quite a lot of methods and potentially including semi-sensitive data that I would need to be able to access through AJAX. I've read about and successfully tested $_SESSION to transfer the class and object, but there seem to be some security concerns. Eg. see How safe are PHP session variables?, and PHP Session Hijacking.
Previously I 'solved' this by simply require'ing the class and re-instantiating the object on every AJAX call/ or making those methods I needed static (after checking for a token and a constant), but I feel like this should be quite performance-heavy (how long does it take for PHP to initialize an object which reads in 200+ JSON/XML files?).
Another option I see is serializing the data in a temp file, but really I have no idea nor experience of what is the best way to go from a performance vs security point of view... Any help will be appreciated, thanks.
I have an script which I call through a browser, in which I create a SoapClient object.
I want to store the SoapClient object such a way that I can use it again when I hit the script through browser.
All I want to achieve is avoiding connecting again and using the previous connection.
I tried storing it in session but the SoapClient object loosing values of attributes sdl.
explained here https://bugs.php.net/bug.php?id=36395
Is there any other way of implementing.
As the PHP manual page says:
Note that many built-in PHP objects cannot be serialized.
There are some exceptions but I don't think SoapClient is. Anyway I honestly can't think of a reason why you'd want to do it as performance-wise it will probably be less efficient doing the serialize/deserialize than instantiating the SoapClient class with every request.
Instantiating a SoapClient from a WSDL is pretty straightforward and you'd be better off just doing that. You can write some helper function to do that for you.
I'm trying to instantiate a CGI::Session object from a session created in a separate PHP script; however, when I Dumper() the object, I see that the _CLAIMED_ID session id (which matches the PHP's session_id()) is different from the _SESS_ID (or whatever) stored in the _DATA member; more to the point, the _DATA member doesn't have any of the session variables that I registered in PHP.
HOWEVER! When I use PHP::Session (and passing the same sess id to its constructor), THIS object does indeed find the session variables in question.
Ideally, I want to use CGI::Session since it seems to be more robust and PHP::Session seems to be a lot more task-specific, so can someone suggest where I'm going wrong with CGI::Session? (Should I create a PHP::Session and then try to pass it to CGI::Session?)
PHP::Session was designed to interoperate with sessions created in PHP. CGI::Session was designed as a Perl-only solution.
CGI::Session does offer multiple back-end implementations, so in theory somebody could write driver, serializer, and id modules for CGI::Session that would be compatible with PHP sessions. Nobody seems to have done that yet, though.
As you know, when you store a class defination in SESSION serialized automatically, and are unserialized on each following pages.
I just started to write classes and I wonder that:
to store a class in session or a file with serializing is a good idea?
If yes, how can I STORE and then GET to use a class in PHP5?
You don't store a class in a session variable, but you can store an object. Take note that if your object has properties referring to resources like file handles and database connections, no amount of unserializing will bring them back.
Unless it's a tiny class, probably not (see this question for possible pitfalls with large sessions). In short, sessions are not designed to be a caching mechanism, and they don't perform too well when you make them into one.
Note that if you are using the default session handler, your sessions are stored on the hard drive - not very fast when you get many concurrent requests. Also (test and measure), serialization/deserialization may be slower than the normal methods of object creation - note that you'd probably be deserializing twice: from session to string, then string into object of that class.
If you want to go the serialization/deserialization route, try e.g. Memcached instead.
Storing object instances in the session has the following disadvantages:
Performance overhead: Even if you don't need some objects, the will be unserialized and instatiated on every request.
Strange bugs in development: Whenever you add or remove a property from an object, the instance from the session will not match the object definition.
Security: Typically the session data is stored separately from your application. Sometimes this location is not as access-protected and secure as the rest of your files.
Data duplication and wrong state: With sessions you may store the same objects over and over again for different users. Compared to a dedicated object cache, where each object is only stored once, this leads to increased storage needs and the possibility that an object has the wrong state because the state was changed in another session.
I'd rather store the objects in a dedicated cache. Have a look at the Zend Cache class as an example of a good cache library.
If your object uses resources (database connections, files, gd images) your class should implement the Serializable interface. You then have to add two methods that do cleanup and initialization stuff.
What options are there to implement an own session management in PHP?
Is there a nice way to implement a component which performs all session tasks?
How can i construct a class which receives the HTTP Request and Response during one request process?
I only found the option "session_save_handler" which seems to define the storage handler. What I need is to replace the whole session management.
Is there another way using the PHP configuration or do I have to implement my own controller which receives all requests and calls my session management?
Thanks for your help
Regards Michael
No, I'm sorry to say, there is no interface to switch the built in 'modules' to your own. There are some hooks ( e.g: session_save_handler(), set_error_handler() ), and that's unfortunately it.
The $_SESSION is a 'super global' and should IMO not be set directly either way if you're working on a bigger projects. Then it would be better to use a custom class responsible for handling sessions. Will make the code easier to debug and such on.
I am not sure, what you want to achieve. It seems more like you want to abstract away from the $_SESSION variable than that you want to change the storage.
Take a look at the way the Zend or the Solar framework handle the Session access.
http://www.phpeveryday.com/articles/Zend-Framework-Session-Introduction-P571.html
http://solarphp.org/manual:sessions
How can i construct a class which receives the HTTP Request and Response during one request process?
I don't know, what you mean by receiving the response, but the frameworks have front-/page-controllers which route to the chosen action, then call a method that can access the Session (read/write) and Request (read) objects and generates a Response object which is then rendered through a template.
For automatic testing you can construct your own Request and Session objects and pass them to the page controller.
You said it yourself in one of the comments. Just wrap the $_SESSION in a class. I don't think you can replace it, but you can certainly build your own interface to it.
You could, for example. Build a class that is constructed first thing and call session_start() inside the constructor
Using the session_save_handler() function allows to handle how the session information is stored and retrieved.
By default PHP stores the session information in temporary files located somewhere on your web server. You can define callback functions using the session_save_handler() function where you can have this information stored in a database table instead.
Even if you handle sessions with your own defined functions with the session_save_handler() function you would still access the information with the superglobal variable $_SESSIONS.
Check out this page from the php online manual. Has lots of useful information with regards to your question. Hope it helps.
You could create a session implementation with cookies and a database. You set a cookie on the client's machine. Then, you run a lookup on a database, something like this:
+--------+------+
| sessid | data |
+--------+------+
Where sessid contains a reference to the cookie (probably some king of md5 or SHA hash), and data is something like a JSON or Serialized array.
The functions:
You can use the function runkit_function_redefine(), which is part of the Runkit API, to redefine the session_xxxx functions.
Note: Runkit is part of PECL. That is, NOT BUNDLED WITH PHP. You will have to install it yourself.
The session variable:
$_SESSION = &SessionClass->data;
Simplicity itself: just make $_SESSION as a reference to YOUR data.