[thelist] 'Hijacking' sessions

[Nick Daverin]

Hi Phil, thanks for your response, I do realize sessions are temp files and
I know we are 'saving' info... My boss is fine with this as long as we don't
have a record we can continually access (as the session files get wiped out
periodically). I should have put legal in quotes as I meant more in-house
policies the law. Thanks for taking the time to help though.

Lauri, yes you have the gist of my problem. Your suggestions are
appreciated, I've tried your first, but I can't seem to re-establish the
session even on the same server. Though right now it would be cross server,
so the session data would be lost anyway. The third won't work as the
database that receives info gets stuff manually dumped to it / updated. So I
literally can not access it. These web servers are hosted by different
companies (I'm trying to get my boss to buy us our own to host in a
co-location and that will solve most of our problems) so I'm not sure how to
accomplish suggestion five if it would even be allowed (which I doubt).

-Nick

On 5/25/06 1:37 PM, "Phil Turmel" <philip at turmel.org> wrote:

> Nick,

Sorry to break it to you, but PHP sessions are really temp files on
> the
server, and are likely to be even less secure than a real database.
> If
you have legal restrictions on storing data temporarily, then
> sessions
don't actually help you.  If the website is hosted on a shared
> server,
the directory of session files might even be exposed to
> totally
unrelated hosts.

You can mitigate this security hole by setting up
> your own session save
handler[1].  But, the bottom line is that you *are*
> saving customer
information on your server, somewhere.  I'd put it in a proper
> database.
 At least then it can be reached by other servers that legitimately
> need
access.

Phil

[1]
> http://us3.php.net/manual/en/function.session-set-save-handler.php

Nick
> Daverin wrote:
> Hi Rob and Anthony,
> 
> Yeah, storing the info in a database
> would solve this, but unfortunately
> that is not an option I can pursue at
> this time. I was hoping for a magic
> smoke answer, where info is not stored
> in a database as I'd have to start
> putting calls to save and retrieve data
> on any page you could cross over on
> the sites, then deleting the record from
> our db after the users were done.
> In time we'll be creating a customer login
> that will save this trouble but
> until we do that and hash out our legal
> policies I'm not allowed to store
> their info in a database on our site.
> 
>
> -Nick
> 
> On 5/24/06 1:21 AM, "Rob Agar" <robagar at westnet.com.au> wrote:
> 
>
> 
>>hi Nick,
>>
>>One way I've employed successfully is by using the
> PEAR::HTTP_Session
>>class (http://pear.php.net/package/HTTP_Session) and
> configuring it to
>>store session data in a database, then just passing the
> session id in
>>the GET request to the other site.  Of course, the second site
> has to be
>>able to access this db.
>>
>>hth
>>Rob
>>
>>Nick Daverin
> wrote:
>>
>>>I was wondering if there is a way to pass session data between
> sites...
>>>Sort-of Œhijacking¹ my own session. As an example: On the one
> site, we
>>>collect donations. All data is stored as session variables until
> the
>>>purchase is completed. Then info we save is sent to a completely
> unrelated
>>>(non accessible) database. We would also like to give people the
> option of
>>>visiting our gift shop before they checkout. Now this site is on
> a different
>>>domain, so even if I pass the session id [using
> session_id($_GET[Œsid¹])
>>>for
>>>example] the session variables I¹ve
> stored while on the first domain are
>>>inaccessible so a user would have to
> check out twice. We use php on these
>>>pages though some type of javascript
> solution could be implemented (as long
>>>as I can explain how it works to my
> boss).
>>>
>>>Thanks for any info!
>>>-Nick
> 
> 
> 

-- 

* * Please support
> the community that supports you.  *
> *
http://evolt.org/help_support_evolt/

For unsubscribe and other options,
> including the Tip Harvester 
and archives of thelist go to:
> http://lists.evolt.org 
Workers of the Web, evolt !