NYCPHP Meetup

NYPHP.org

[nycphp-talk] Re: Cakephp

Nate Abele nate at cakephp.org
Thu Dec 14 12:31:58 EST 2006


Hey Paul, don't get me wrong, because I completely agree about the  
statelessness of the web being critical for RESTfulness and whatnot,  
but seriously, any app that uses $_SESSION is broken?  I'm sure I'm  
not the only one who would beg to differ on that one, especially  
since there are many good JavaScript-based methods for overcoming  
session issues where users are browsing using multiple tabs or Ajax  
apps.

But regardless of all that, please refer to the following: app/config/ 
core.php:
define("CAKE_SESSION_SAVE", "database");

> Date: Wed, 13 Dec 2006 18:10:48 -0500
> From: Paul Houle <paul at devonianfarm.com>
> Subject: Re: [nycphp-talk] Cakephp
>
> dkov at optonline.net wrote:
>> Does anyone use the Cakephp framework? If you do, I have tried using
>> thier session component to create and manage sessions.  I have read
>> every bit of information I can find on the internet.  I still can't
>> get my sessions working correctly.  Please teach me.
>     I avoid session variables -- most applications that use session
> variables are "broken by design".  If you do manage to get sessions to
> work,  the next thing you'll be asking us is how to disable the  
> back button.
>
>     The "stateless" paradigm of web programming is responsible for  
> many
> of it's advantages:  the reasons why we're writing web-based business
> apps instead of other applications.
>
>     It turns out that the behavior of cookies in mainstream web  
> browsers
> are largely undocumented;  it's bad enough if you've got control of  
> the
> cookies that you're sticking on people,  but things get really
> mysterious when some library you don't control is doing it.
>
>     PHP locks the $_SESSION variable when it's in use -- this causes
> lots of problems for apps that have multiple frames,  use AJAX,  etc.
>
>     If you want to write reliable web apps,  keep your "session" state
> in well-engineered database tables,  and use signed cookies to  
> attach a
> session id to users.  You'll spend a less time dealing with mysterious
> behavior on the part of the $_SESSION object.




More information about the talk mailing list