[nycphp-talk] A tale of 4 scopes
ken at secdat.com
Wed Jan 17 10:53:01 EST 2007
Cliff Hirsch wrote:
> I have seen some applications that only use url-based session IDs. I
> think the PHP INI has a setting for this. If not, why not just attach
> your own "tab-id" tag to every url.
Well, you know I thought that the URL rewriting was limited to the
session ID, but I checked the docs and found this little beauty:
...so that a tab ID can be generated when blank and we can keep tabs
> -----Original Message-----
> From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org]
> On Behalf Of Kenneth Downs
> Sent: Wednesday, January 17, 2007 9:39 AM
> To: NYPHP Talk
> Subject: [nycphp-talk] A tale of 4 scopes
> There is a particular feature that I've tried to implement with varying
> success. I'm wondering if anybody else has tried.
> The idea centers around scope. In a web app, it seems to me there are
> three recognized scopes, plus a fourth one nobody talks about much:
> 1) Application/Database scope - data available to all users
> 2) Session Scope - data available to one browser instance (with all of
> its tabs and windows)
> 3) Window/Tab Scope ( The one I'm trying to implement )
> 4) Request Scope, the GET/POST parameters of a single request.
> We're interested in a solution for #3, the ability to distinguish
> between the various windows or tabs that a user has open.
> I have a partial solution but I don't like it because it is fragile
> (besides being partial). In this solution, you send a hidden variable
> to the browser that contains the "state" for that window. Among the
> many problems of this approach is that every link must be a FORM
> submission so that the variable goes back to the server. It does work
> very well for us in one very particular situation, but it is hardly a
> general solution.
> The difficulty stems from the fact that there is no "window cookie" or
> "tab cookie", at least not as far as I know. If there were, that would
> solve the whole problem. I've thought of trying to trick PHP's system
> of writing a cookie into the URL, but since it is not meant to do that
> it would probably keeping wanting to do the wrong thing.
> Anybody else tried this?
> New York PHP Community Talk Mailing List
> NYPHPCon 2006 Presentations Online
> Show Your Participation in New York PHP
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: not available
More information about the talk