Re: [amfphp] PHP Questions - quiz, test your knowledge

[Evert | R. <ev...@ro...>]

Chuck Hoffman wrote:
> - When a Flex application in a browser communicates with a php page for the first time a session is created. This is the same behavior as user receiving a PHP page in their browser. 
>
> A session is started in PHP with session_start(), or implicitly the first time a PHP script calls session_register or assigns a value into $_SESSION.  (if a session has already been started when any of these happens, the existing session is resumed.)
>
> AMFPHP starts up a session for you.  This can give you trouble if you are putting _objects_ into a session, because them AMFPHP will resume that session next time - and trying to reference objects that are in a session before those object's classes are loaded up confuses PHP.  The way around this is to call session_write_close(), then session_start() once the needed classes are loaded up, before trying to reference any of those objects.
>
> The thing to think about with this is, that a session really just consists of a file on the server associated with an ID number.  Whatever you place in the session gets written to that file each time PHP finishes a script, in a serialized format (not entirely unlike say, AMF.)  Next time PHP runs -- next HTTP request -- it looks for a session ID being mentioned, and if it finds one, it pulls up the session file for it, reads it, and deserializes it as data back into memory.  If anything in the session file is an object, some part of its serialization format will mention its class, and PHP will need to have that class definition loaded up so it can rebuild the object correctly.
>
> I have a singleton class called SessionRegistry that abstracts/wraps around access to the session -- I got the initial idea from the book "PHP 5 Objects, Patterns, and Practice," and modified it to call session_write_close() followed by session_start() in its constructor.  Since it doesn't get put in the session itself, and it's set up as a singleton, the constructor gets called once per remoting request, the first time the class is used.  That helps considerably.
>
> For more details on PHP session handling, have a look at http://us2.php.net/manual/en/ref.session.php
>
>
> - This session that is created last indefinitely with Flex applications because Flex keeps the connection open / session alive on the server.
>   
This is not the case.. the tcp connection is often maintained (http 
keepalive) but this is outside of the php layer.. no http requests are 
being made there.. keepalive is often 300 seconds if I'm correct.
> - Flex keeps the connection alive by periodically pinging the server. 
>   
When its polling yes, otherwise no..
> - Sessions will never timeout due to this behavior.
>   
They will, unless there's polling going (amfphp doesnt support this yet)
> - When the user navigates away from the Flex application the session will timeout on the server. 
>   
Yes..


And actually.. im some browsers (don't remember which one) flash doesn't 
make use of the browsers' http abilities and makes the request itself. 
In these requests cookies are not sent along, and amfphp uses a trick to 
append the session id to the url.. This is secure, as long as session 
id's are not passed in the html wrapper .. (this is only AMF0, not 3)
> - To manually timeout a session on the server call a page or function that executes this code " session.destroy();" <-- not sure what the recommended method to clear the session on the server.
>   
Thats the recommended way (session_destroy)
> That's a PHP function, so it will run on the server - so I think that is the recommended method to clear the session on the server ;-)  Check the php.net page linked to above, but I imagine that function also attempts to notify the browser present at the IP address associated with that session that the session ID is no longer active - or perhaps not, since I suppose it isn't necessary to do so right away, it could be done next time a request mentions the now-dead session's ID.
>   
session_destroy does not unset cookies, and flash using amfphp's method 
for AMF0 the session id actually never goes away.. only the data 
associated to it is gone.. after that you'll start with a new session 
with the same id. Its highly recommended from a security perspective 
that every time you go to a different auth status (e.g.: login, logout, 
become admin) to always make a new session id.

Evert